Add to $PATH how?

[Chris Bradford]

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

[Jon Ingason]

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

[Timothy Murphy]

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 ... ?

[Cameron Simpson]

On 03Jun2006 16:30, Timothy Murphy  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,

[Cameron Simpson]

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,