For some reason /sbin/ is no longer in my $PATH or root's $PATH
How can I edit my path, and ensure that this is saved upon reboot?
This only seems to be the case in gdm, under tty1 both my account and root have /sbin/ in our $PATH
Thanks,
Chris Bradford Systems Administrator Cambridge Newspapers
This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
Chris Bradford wrote:
For some reason /sbin/ is no longer in my $PATH or root's $PATH
How can I edit my path, and ensure that this is saved upon reboot?
This only seems to be the case in gdm, under tty1 both my account and root have /sbin/ in our $PATH
For root the /sbin/ is added in /etc/profile. Take a look at it. An ordinary user you should not have it in his PATH. But you can add it i .bash_profile. Something like this:
... # User specific environment and startup programs
PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin
export PATH ...
Thanks,
Chris Bradford Systems Administrator Cambridge Newspapers
This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
Jon Ingason wrote:
For some reason /sbin/ is no longer in my $PATH or root's $PATH
How can I edit my path, and ensure that this is saved upon reboot?
This only seems to be the case in gdm, under tty1 both my account and root have /sbin/ in our $PATH
For root the /sbin/ is added in /etc/profile. Take a look at it. An ordinary user you should not have it in his PATH. But you can add it i .bash_profile. Something like this:
... # User specific environment and startup programs
PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin
export PATH ...
I've never really understood what should go in .bashrc and what in .bash_profile ... ?
On 03Jun2006 16:30, Timothy Murphy tim@birdsnest.maths.tcd.ie wrote: | I've never really understood what should go in .bashrc | and what in .bash_profile ... ?
The /etc/profile and ~/.profile (or, for bash, ~/.bash_profile if present) are sourced at the start of a "login" shell.
The /etc/bashrc and ~/.bashrc files are sources at the start of a non-login interactive shell.
Now, the idea is that the .profile holds things that need doing exactly once when you log in, and these may be expensive (eg print a summary of your pending mail etc). The .bashrc contains things that cannot be done only once (eg shell aliases, which are not exported) and that only matter for _interactive_ shells (eg command line editing modes, etc).
In a normal "text mode" system where you log in on a text console this works well; your first login shell sources the .profile and sets up your $PATH and so forth. Because these values are exported to subsequent processes this need only happen once, and fresh interactive shells do not need to slow themselves down with this stuff.
On GUI logins, this process has usually been damaged by the OS vendor (RedHat in this case).
The "correct" thing to do is to have the session startup, which is usually just another shell script that runs up windows managers and so forth, to source your ~/.profile. However, that is not an interactve shell, and non-interactive shells _abort_ if they encounter a syntax error. So if you, the user, put something syntacticly invalid in your .profile then suddenly you can't log in because the session script aborts.
For myself, I source my .profile in the session startup and am just careful.
Anyway, because of this, vendors tend not to source the .profile during the X11 session startup, and that means that you end up with the need to source it for every new terminal you open. Ghastly. And worse, it results in _every_ recent GUI app having huge config stuff to set preferences that should properly come from your UNIX environment (i.e. from your .profile) because _they_ are also started before your .profile is used. Ghastly. And you see people put full paths to executables in their settings, again because their $PATH is not under their control.
As a user you have three workarounds available:
- configure your "new terminal" button to open a "login" shell This slows down every new terminal and removes the distinction of "login" as the operation that happens just once.
- put all the stuff that should happen in your .profile in your .bashrc; this slows down _every_ interactive startup shell in addition to the new terminal opening
- take control of your GUI startup session
I recommend the last option, and do so myself. This is actually easier than you might think.
If you have a file ~/.xsession, that is a shell script to run as your GUI session. Here's mine:
#!/bin/sh . /etc/profile . $HOME/.profile exec $HOME/rc/x11/session
Now, you can see that sources the "login" stuff, then runs my personal "session" script, which basicly starts my window manager and sets the screen wallpaper etc.
Anyway, having run my .profile all "new terminals" can run plain interactive shells. And all my app configs don't need the full pathname to executables because I've set up my $PATH _before_ the apps start.
If I were wanting the "Gnome" desktop, I'd change the last line to:
exec gnome-session
which runs the installed Gnome environment.
Now, once you do this you have full control of what you run. But also, if you put a syntax error in your .profile or .xsession, you can't log in using the GUI. So BEFORE you make this change, become adept at escaping X11 and getting a text console. Type Ctrl-Alt-F1. That leaves X11 and puts you on a text console. You can log in here and fix things up. Return to X11 by typing Alt-F7.
With that mechanism available you are ok to hack on this stuff in safety.
Cheers,
On 05Jun2006 10:32, I wrote: | Now, once you do this you have full control of what you run. But also, | if you put a syntax error in your .profile or .xsession, you can't log in | using the GUI. So BEFORE you make this change, become adept at escaping | X11 and getting a text console. Type Ctrl-Alt-F1. That leaves X11 and | puts you on a text console. You can log in here and fix things up. | Return to X11 by typing Alt-F7. | | With that mechanism available you are ok to hack on this stuff in | safety.
One other thing: this command:
sh -n some-shell-script
will check the script for syntax correctness without actually running it. It is very useful as a final check before testing new stuff.
Cheers,