last day (15 days later) » 

9:49 AM
0
Q: Setting the path to textlive installation, round 2

ptrcaoIt seems like everytime I install textlive distro on one of my computers I have the same problem: peter@msideb:~$ tlmgr --gui bash: tlmgr: command not found The below reflects the current state of my .profile: # ~/.profile: executed by the command interpreter for login shells. # This file...

 
@Peter Grill: How do you mean? What should I type into my terminal to do what you propose? Also I installed to /home/peter/texlive/2011, so isn't that going to be my path?
@Jan Hlavacek: $ echo $PATH gives: /usr/local/bin:/usr/bin:/bin:/usr/games. What does that tell you?
@Peter Grill: If I manually pased PATH=/home/peter/texlive/2011/bin/i386-linux:$PATH; export PATH into terminal and then run tlmgr --gui, it works! So you may be right, it isn't executing .profile for some reason. What do I need to do now?
 
Looking at line 2 in the file, do you have one of the files ~/.bash_profile or ~/.bash_login?
 
@Andrew Stacey: I have a number of similar sounding files such as .bashrc, .bash_history, .bash_logout in my /home/peter directory. What do I need to do about this?
 
From what you say, it looks as though bash isn't reading this file. I found freeunix.dyndns.org:8088/site2/howto/Bash.shtml which says that bash looks for .bash_profile, then .bash_login, and finally .profile and it loads only one of these. Also, it only loads this on login. It may be the case that logging in via X does not count as an actual login (see linuxgazette.net/161/okopnik.html) so this might never be read even if the other files aren't there. Try putting the code in .bashrc instead.
 
@Andrew Stacey: I've tried restarting my computer with the PATH details inserted at the end of .bashrc and zzz-texlive.sh, with the path amended to my home directory where I installed texlive. What should I do now...?
 
9:49 AM
Give me a login on your computer so I can take a look ??? Only joking!. Put in to each of the possible files the command export BASHRCWASREAD="bashrc was read" (with suitable changes). Then log out, log in, and try echo $BASHRCWASREAD (and for each). Also, take a look in .xsession_errors to see if there's anything obvious in there (maybe a syntax error in one of the files). Try also source .bashrc (and the others) from the command line to see if there are any errors.
 
Hi, before we do that is this of any significance: echo $PATH gives /home/peter/texlive/2011/bin/unknown-linux:/usr/local/bin:/usr/bin:/bin:/usr/games. Is "unknown" supposed to be there? Shouldn't it be i386?
 
Yes it should be i386. I also got unknown for uname -i but I got the right one by doing uname -m. However (as I commented on Herbert's answer) for a single machine then there's no danger in having it hard-coded to i386.
 
Should I do use uname -m as well in my path specification?
i'll try and report back
 
10:16 AM
see my comment in the thread for a report of the outcome
 
10:27 AM
peter@msideb:~$ echo $`uname -m`
$i686
peter@msideb:~$ echo $`uname -i`
$unknown
 
 
2 hours later…
12:16 PM
@ptrcao Best to hardcode it as i386.
 
 
1 hour later…
1:17 PM
bit of a shame though. i still would be very interested to know the generic solution for $uname
 
The problem is that uname is reporting finer information than TeXLive can cope with. Many programs don't care that you're using a 686, only whether it is 32bit or 64bit. So they have an i386 version and an x86_64 version. TeXLive just needs to know which and installs the right one (though you can override it - I do on my system). But some programs do take note of exactly which system and so uname -m has to report the most accurate information that it can.
So the real uname solution would have to be a conditional that mapped the multitude of possible outcomes to the smaller number of architectures that TeXLive differentiates between. Best to either hardcode it, or to put in a symlink to somewhere more "natural", say to $HOME/local/texlive/bin which is architecture-independent.
 

  last day (15 days later) »