815 lines
23 KiB
Plaintext
815 lines
23 KiB
Plaintext
PATH HOWTO
|
||
Esa Turtiainen etu@dna.fi
|
||
v0.4, 15 November 1997
|
||
____________________________________________________________
|
||
|
||
Table of Contents
|
||
|
||
|
||
1. Introduction
|
||
|
||
2. Copyright
|
||
|
||
3. General
|
||
|
||
4. Init
|
||
|
||
5. Login
|
||
|
||
6. Shells
|
||
|
||
6.1 bash
|
||
6.2 tcsh
|
||
|
||
7. Changing user ID
|
||
|
||
7.1 su
|
||
7.2 sudo
|
||
|
||
8. Network servers
|
||
|
||
8.1 inetd
|
||
8.2 rsh
|
||
8.3 rlogin
|
||
8.4 telnet
|
||
8.5 ssh
|
||
|
||
9. XFree86
|
||
|
||
9.1 XDM
|
||
9.2 xterm -ls
|
||
9.3 Window manager menus and buttons
|
||
|
||
10. Delayed commands cron and at
|
||
|
||
10.1 cron
|
||
10.2 at
|
||
|
||
11. Some examples
|
||
|
||
11.1 magicfilter
|
||
11.2 Printing from X applications
|
||
|
||
12. Security concerns
|
||
|
||
13. How to debug problems?
|
||
|
||
14. Some strategies to get the same path for all the users
|
||
|
||
15. Acknowledgements
|
||
|
||
|
||
|
||
______________________________________________________________________
|
||
|
||
|
||
|
||
1. Introduction
|
||
|
||
|
||
This document describes common tricks and problems with Unix / Linux
|
||
environment variables, especially with PATH variable. PATH is a list
|
||
of directories where commands are looked for. The details apply for
|
||
Debian Linux 1.3 distribution.
|
||
|
||
Note! This document is in beta release status. Please send comments
|
||
and corrections.
|
||
|
||
|
||
|
||
2. Copyright
|
||
|
||
|
||
|
||
This documentation is free documentation; you can redistribute it
|
||
and/or modify it under the terms of the GNU General Public License as
|
||
published by the Free Software Foundation; either version 2 of the
|
||
License, or (at your option) any later version.
|
||
|
||
This documentation is distributed in the hope that it will be useful,
|
||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||
General Public License for more details.
|
||
|
||
You should have received a copy of the GNU General Public License
|
||
along with this documentation; if not, write to the Free Software
|
||
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||
|
||
|
||
|
||
3. General
|
||
|
||
|
||
All the Unix processes contain an "environment". This is a list of
|
||
variables that contain name and value, both just strings that can
|
||
contain most characters. All Unix processes have a parent process -
|
||
the process that created this process as child. Child processes
|
||
inherit environment from parent process. They can make some
|
||
modifications to the environment before passing it in turn to their
|
||
child processes.
|
||
|
||
One important environment variable is PATH, a list of directories
|
||
separated by colons (':'). These directories are searched through to
|
||
find commands. If you try to invoke command 'foo', all the
|
||
directories in PATH (in that order) are searched for an executable
|
||
file 'foo' (one with x-bit on). If a file is found, it is executed.
|
||
|
||
In this howto, I use term 'command' to refer executable program that
|
||
is meant to be called with short names, using the path mechanism.
|
||
|
||
In Linux, even the low level operating system calls to start processes
|
||
(the exec family of calls) searches through directories in the PATH
|
||
variable: you can use the path mechanism anywhere where you try to
|
||
execute a command. If exec operating system call gets a file name
|
||
that does not contain '/', it evaluates the PATH environment variable.
|
||
Even if there is no variable PATH in the environment, at least
|
||
directories /bin and /usr/bin are looked for suitable commands.
|
||
|
||
In sh you use export command to set environment, in csh you use setenv
|
||
command. For example:
|
||
|
||
sh:
|
||
|
||
PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:.
|
||
|
||
|
||
|
||
csh:
|
||
|
||
|
||
setenv PATH /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:.
|
||
|
||
|
||
|
||
C-programs can use setenv() library call to change environment. Perl
|
||
has environment in an associative array %ENV, you can set PATH as
|
||
$ENV{PATH}="/bin".
|
||
|
||
env command is the basic way of asking the current environment
|
||
variables. It can be used to modify it as well.
|
||
|
||
More information of the basic environment mechanism can be found from
|
||
manual pages 'environ', 'execl', 'setenv', info file 'env' and
|
||
documentation of shells.
|
||
|
||
When Linux boots up, the first normal process that starts is the init
|
||
process. It is a special process because it does not have parent.
|
||
However, it is the ancestor of all the other processes. Init
|
||
environment will remain as environment of all the processes if they do
|
||
not touch it explicitly. Most processes do touch.
|
||
|
||
Init starts a group of processes. File /etc/inittab tells what
|
||
processes the system starts. These processes work in the environment
|
||
that is directly inherited from init - typically they are processes
|
||
like 'getty', the program that writes 'login:' to console. If you
|
||
start PPP connections here, you must remember that you are working in
|
||
the init environment. The system initialization is often a script
|
||
that is started here. In Debian 1.3 initialization script
|
||
/etc/init.d/rc and it calls other initialization scripts in turn.
|
||
|
||
The system contains many running servers (daemons) that may or may not
|
||
use the default environment. Most servers are started from the
|
||
initialization scripts and thus they have the init environment.
|
||
|
||
When user logs in to the system, the environment is affected by the
|
||
settings that are compiled into the programs, system wide
|
||
initialization scripts and user initialization scripts. This is
|
||
pretty complicated and the current situation is not completely
|
||
satisfactory. It is totally different if user logs in from text
|
||
console, XDM or from network.
|
||
|
||
|
||
|
||
4. Init
|
||
|
||
|
||
Init is a parent process for all the other processes of the system.
|
||
Other processes inherit environment of the init process and the path
|
||
is the init path in the rare case that no other path is set.
|
||
|
||
The 'init path' is fixed in the source of the init program and it is:
|
||
|
||
|
||
|
||
/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
|
||
|
||
|
||
Note that init path does not contain /usr/local/bin.
|
||
|
||
All the programs that are started from /etc/inittab work in init
|
||
environment, especially system initialization scripts in /etc/init.d
|
||
(Debian 1.3).
|
||
|
||
Everything that is started from system initialization scripts has init
|
||
environment as default environment. For example, syslogd, kerneld,
|
||
pppd (when started from startup), gpm and most importantly lpd and
|
||
inetd have init environment and they do not change it.
|
||
|
||
A group of programs are started from startup scripts but the PATH
|
||
environment variable is explicitly set in the startup script.
|
||
Examples are: atd, sendmail, apache and squid.
|
||
|
||
There are other programs that are started from boot scripts but they
|
||
change the path completely. One such example is cron.
|
||
|
||
|
||
|
||
5. Login
|
||
|
||
|
||
In text console there is a getty program waiting for user login. It
|
||
writes 'login:' and other messages. It is working in init
|
||
environment. When getty gets user to log in to the system, it invokes
|
||
the 'login' program. This program sets the user environment and
|
||
invokes the shell.
|
||
|
||
Login program sets path as defined in /usr/include/paths.h. This
|
||
|
||
for common users (_PATH_DEFPATH):
|
||
|
||
|
||
/usr/local/bin:/usr/bin:/bin:.
|
||
|
||
|
||
|
||
for root (_PATH_DEFPATH_ROOT):
|
||
|
||
|
||
/sbin:/bin:/usr/sbin:/usr/bin
|
||
|
||
|
||
|
||
Common user's path does not contain any sbin directories. However, it
|
||
contains the current directory, '.', which is considered dangerous for
|
||
the root user. Not even /usr/local/bin is available for the root user.
|
||
|
||
Login path is often overwritten by shell initialization. However, it
|
||
is possible to use other programs in /etc/passwd as user shells. For
|
||
example, I have used the following line to start PPP when I log in
|
||
using special user name. In this case, the pppd has exactly login
|
||
path.
|
||
|
||
|
||
|
||
etu-ppp:viYabVlxPwzDl:1000:1000:Esa Turtiainen, PPP:/:/usr/sbin/pppd
|
||
|
||
|
||
|
||
6. Shells
|
||
|
||
|
||
Often user processes are children processes of the shell mentioned in
|
||
/etc/passwd for this user. Initialization files of shells often modify
|
||
path.
|
||
|
||
In login, the name of the shell is preceded with '-', for example bash
|
||
is called as '-bash'. This signals to the shell that it is a 'login'
|
||
shell. In this case, the shell executes the 'login' initialization
|
||
files. Otherwise some lighter initialization is performed.
|
||
Additionally, the shell checks if it is interactive - are the commands
|
||
coming from file or interactive tty. This modifies the shell
|
||
initialization so that a non-interactive non-login shell is
|
||
initialized very lightly - bash do not execute any initialization file
|
||
in this case!
|
||
|
||
|
||
|
||
6.1. bash
|
||
|
||
|
||
As a normal login shell, bash 'sources' system-wide file /etc/profile,
|
||
where the system environment and path can be set for bash users.
|
||
However, it is not run when the system interprets the shell as non-
|
||
interactive. The most important case is in rsh, where remote command
|
||
is executed in the neighboring machine. The /etc/profile is not run
|
||
and the path is inherited from rsh daemon.
|
||
|
||
bash receives command line arguments -login and -i that can be used to
|
||
set the shell as a login shell or interactive shell respectively.
|
||
|
||
The user can overwrite values set in /etc/profile by creating a file
|
||
~/.bash_profile, ~/.bash_login or ~/.profile. Note that just the first
|
||
one of these is executed thus differing of the logic of csh
|
||
initialization. ~/.bash_login is not executed specially for login
|
||
shells and if .bash_profile exists, it is not executed at all!
|
||
|
||
If bash is used with name sh instead of the name bash, it emulates
|
||
original Bourne shell initialization: it sources just files
|
||
/etc/profile and ~/.profile and just for login shells.
|
||
|
||
|
||
|
||
6.2. tcsh
|
||
|
||
|
||
As a login shell tcsh executes the following files in this order:
|
||
|
||
|
||
<20> /etc/csh.cshrc
|
||
|
||
<20> /etc/csh.login
|
||
|
||
<20> ~/.tcshrc
|
||
|
||
<20> ~/.cshrc (if .tcshrc is not found)
|
||
|
||
<20> ~/.history
|
||
|
||
<20> ~/.login
|
||
|
||
<20> ~/.cshdirs
|
||
|
||
tcsh can be compiled to execute login scripts before cshrc scripts.
|
||
Beware!
|
||
Non-interactive shells execute just the *cshrc scripts. *login scripts
|
||
can be used to set the path just once in the login.
|
||
|
||
|
||
|
||
7. Changing user ID
|
||
|
||
|
||
|
||
7.1. su
|
||
|
||
|
||
Command su sets a new user id to use. If no user id is given, root is
|
||
used.
|
||
|
||
Normally su invokes a subshell with a different user id. With
|
||
argument '-' (more recent synonyms -l or --login) su invokes shell
|
||
like login shell. However, it does not use login program to do this
|
||
but uses a yet another built-in path for login 'simulation' (term used
|
||
in the source code). It is:
|
||
|
||
for normal users
|
||
|
||
|
||
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:.
|
||
|
||
|
||
|
||
for root user
|
||
|
||
|
||
/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin
|
||
|
||
|
||
|
||
su makes many quite subtle environment changes as well.
|
||
|
||
|
||
|
||
7.2. sudo
|
||
|
||
|
||
There is a group of commands that make use of super user commands
|
||
safer. They allow better logging, user-based restrictions and usage
|
||
of individual passwords. Most widely used is sudo.
|
||
|
||
|
||
|
||
$ sudo env
|
||
|
||
|
||
|
||
executes command env as super user (if it is configured to allow it).
|
||
|
||
sudo command has again a different approach to path handling. It
|
||
modifies the search path so that the current directory is always the
|
||
last one. However, it does not modify PATH environment variable.
|
||
just couple of environment variables like SUDO_USER.
|
||
|
||
|
||
|
||
8. Network servers
|
||
|
||
|
||
|
||
Most network servers should not invoke subprocesses of any kind. For
|
||
security reasons, their path should be minimal.
|
||
|
||
An important exception is all the services that allow logging in to
|
||
the system from network. This section describes what is the
|
||
environment in these cases. If the command is executed in the remote
|
||
machine with rsh it gets different path than if it is executed with
|
||
ssh. Similarly, logging in with rlogin, Telnet or ssh is different.
|
||
|
||
|
||
|
||
8.1. inetd
|
||
|
||
|
||
Most network servers do not have process of their own waiting for
|
||
requests all the time. This work is delegated to an Internet super
|
||
server called inetd. Inetd listens for all the defined network ports
|
||
and starts the appropriate server when there is an incoming request.
|
||
This behaviour is defined in /etc/inetd.conf.
|
||
|
||
inetd is started from system startup scripts. It inherits just path
|
||
of init process. It does not modify it and all the servers started
|
||
from inetd has init path. An example of such a server is imapd, the
|
||
server of IMAP post office protocol.
|
||
|
||
Other examples of inetd processes are telnetd, rlogind, talkd, ftp,
|
||
popd, many http servers and so on.
|
||
|
||
Often usage of inetd is still complicated by using a separate tcpd
|
||
program to start the real server. It is a program that makes
|
||
additional security checks before starting the real application. It
|
||
does not affect the path (not verified).
|
||
|
||
|
||
|
||
8.2. rsh
|
||
|
||
|
||
rsh daemon sets the path from _PATH_DEFPATH (/usr/include/paths.h)
|
||
that is the same path that login program uses for normal users. Root
|
||
will get the same path than the normal user.
|
||
|
||
Actually, rshd executes the command it gets with the command line:
|
||
|
||
|
||
|
||
shell -c command-line
|
||
|
||
|
||
|
||
and shell is not a login shell. It is desirable that all the shells
|
||
mentioned in /etc/passwd support -c option to give on the command
|
||
line.
|
||
|
||
|
||
|
||
8.3. rlogin
|
||
|
||
|
||
Rlogin is invokes login to make the real login procedure. If you login
|
||
with rlogin, you get the same path than in login. Most other ways to
|
||
log in to a Linux computer do not use login. Note the difference with
|
||
rsh.
|
||
|
||
The login command actually used is
|
||
|
||
|
||
|
||
login -p -h host-name user-name
|
||
|
||
|
||
|
||
-p preserves the environment except the variables HOME, PATH, SHELL,
|
||
TERM, MAIL and LOGNAME. -h tells the remote host name for logging.
|
||
|
||
|
||
|
||
8.4. telnet
|
||
|
||
|
||
Telnet is similar than rlogin. It uses the login program and the
|
||
command line to invoke it in a similar way.
|
||
|
||
|
||
|
||
8.5. ssh
|
||
|
||
|
||
ssh has a path setting of it's own. It has a fixed path where it adds
|
||
the directory where ssh is. Often this means that /usr/bin is in the
|
||
path twice:
|
||
|
||
|
||
|
||
/usr/local/bin:/usr/bin:/bin:.:/usr/bin
|
||
|
||
|
||
|
||
The path does not contain /usr/X11/bin and shell invoked by ssh
|
||
command is not a login shell. Thus
|
||
|
||
|
||
|
||
ssh remotehost xterm
|
||
|
||
|
||
|
||
never works and anything in /etc/profile or /etc/csh.cshrc can change
|
||
this. You must always use explicit path /usr/bin/X11/xterm.
|
||
|
||
ssh searches environment variables of form VAR=VALUE from file
|
||
/etc/environment. Unfortunately this causes some problems with
|
||
XFree86.
|
||
|
||
|
||
|
||
9. XFree86
|
||
|
||
|
||
|
||
9.1. XDM
|
||
|
||
|
||
|
||
XDM is the most common way to log in to a graphical terminal. It a bit
|
||
looks like login but it is internally totally different.
|
||
|
||
In directory /etc/X11/xdm there are configuration files that are
|
||
executed on different login phases. Xstartup (and Xstartup_0 specially
|
||
for screen 0) contains commands to be run after the user has logged in
|
||
(commands are run as user root).
|
||
|
||
The path that is set for users is in /etc/X11/xdm/xdm-config. There
|
||
are lines:
|
||
|
||
|
||
|
||
DisplayManager*userPath: /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
|
||
DisplayManager*systemPath: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
|
||
|
||
|
||
|
||
That will be a default path for normal and root users respectively. It
|
||
is very important that /usr/bin/X11 is available for X users. If X
|
||
user logs in to another machine to start and X client application, he
|
||
should get /usr/bin/X11 to his path even he don't seem to come
|
||
directly from X terminal.
|
||
|
||
After running Xstartup the XDM runs /etc/X11/Xsession that is run as
|
||
the final user. Local configuration is meant to be done in
|
||
/etc/environment that is sourced (included) from Xsession if available
|
||
(Xsession is run with /bin/sh and thus /etc/environment must be a sh
|
||
file). This clashes with ssh that supposes that /etc/environment is a
|
||
file that contains just lines of form VAR=VALUE.
|
||
|
||
|
||
|
||
9.2. xterm -ls
|
||
|
||
|
||
By default the path for all the commands invoked from X window manager
|
||
menus is the path inherited from XDM. To use something different it
|
||
must be set explicitly. To start a terminal emulator with a path that
|
||
is "normal" some special option must be used. In xterm the option -ls
|
||
(login shell) must be used to get a login shell with path specified in
|
||
shell login initialization files.
|
||
|
||
|
||
|
||
9.3. Window manager menus and buttons
|
||
|
||
|
||
Window manager inherits environment of XDM. All the programs started
|
||
by the window manager inherit the environment of the window manager.
|
||
|
||
User shell environment does not affect the programs that are started
|
||
from window manager buttons and menus. For example, if program is
|
||
started from 'xterm -ls', it has the default environment of login
|
||
shell but if it is started from menu, it has just environment of the
|
||
window manager.
|
||
|
||
|
||
|
||
10. Delayed commands cron and at
|
||
|
||
|
||
|
||
10.1. cron
|
||
|
||
|
||
Cron is a command that executes commands periodically as specified in
|
||
/etc/crontab and user-defined crontabs. In Debian 1.3 there is a
|
||
standard mechanism to execute commands in /etc/cron.daily,
|
||
/etc/cron.weekly and /etc/cron.monthly.
|
||
|
||
Cron is started from boot scripts but it seems to change it's PATH to
|
||
a pretty strange one:
|
||
|
||
|
||
|
||
/usr/bin:/binn:/sbin:/bin:/usr/sbin:/usr/bin
|
||
|
||
|
||
|
||
THIS IS LIKELY A BUG IN CRON. This is the init path where there is
|
||
/usr/bin:/bin written over the beginning without terminating 0! This
|
||
bug does not exist in all the systems.
|
||
|
||
In crontab there can be PATH definition. In Debian 1.3 there is the
|
||
following default line in the beginning of /etc/crontab:
|
||
|
||
|
||
|
||
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
|
||
|
||
|
||
|
||
Because of this, the PATH of crond program is never used in user
|
||
programs. All the scripts in /etc/cron.* directories get this path by
|
||
default. This path is used even if a program is executed as non-root.
|
||
|
||
|
||
|
||
10.2. at
|
||
|
||
|
||
at is a command that can be used to run a one-time program at specific
|
||
time.
|
||
|
||
atd is run using init path. However, the user programs are always run
|
||
in the user environment using sh command. Therefore the usual shell
|
||
overwrites apply. Look the chapter on bash.
|
||
|
||
|
||
|
||
11. Some examples
|
||
|
||
|
||
|
||
11.1. magicfilter
|
||
|
||
|
||
magicfilter is a common tool to manipulate files for printer. It
|
||
analyzes the type of the file to be printed and invokes a filter
|
||
script to make appropriate pretty-printing. These scripts are invoked
|
||
from lpd that is started from /etc/init.d/lpd that is started from
|
||
init. Thus, the path is that of init. That does not contain
|
||
/usr/bin/X11!
|
||
|
||
|
||
You might want to insert printing of PDF files to magicfilter. It is
|
||
possible to do this by using /usr/bin/X11/xpdf. Now you must remember
|
||
to insert full directory path to the file name because magicfilter
|
||
would not find it otherwise. Most programs used in magicfilter do not
|
||
need full path, because they are on /bin or /usr/bin.
|
||
|
||
|
||
|
||
11.2. Printing from X applications
|
||
|
||
|
||
|
||
You may use PRINTER environment variable to show what is the printer
|
||
that you are using. However, you may notice that in some cases in X
|
||
applications it is sometimes lost.
|
||
|
||
You must remember that if the X session is started from XDM, the
|
||
window manager has never evaluated your shell login scripts. All the
|
||
X applications that you have started from xterm have your PRINTER
|
||
variable. However, if the same application is started from menu or
|
||
window manager button, it does not contain your PRINTER variable.
|
||
|
||
In some cases this can be inherited to an even lower layer: for
|
||
example a Netscape helper application can have or have not your
|
||
PRINTER definition.
|
||
|
||
|
||
|
||
12. Security concerns
|
||
|
||
|
||
The path is sometimes a big security problem. It is a very common way
|
||
to hack into a system using some mistakes in path settings. It is
|
||
easy to make Trojan horse attacks if hacker gets root or other users
|
||
to execute his versions of commands.
|
||
|
||
A common mistake in the past (?) was to keep '.' in the root's path.
|
||
Malicious hacker makes program 'ls' in his home directory. If root
|
||
makes
|
||
|
||
|
||
|
||
# cd ~hacker
|
||
# ls
|
||
|
||
|
||
|
||
he executes ls command of hacker's.
|
||
|
||
Indirectly, this same applies to all the programs that are executed as
|
||
root. Any of the important daemon processes should never execute
|
||
anything that some other user can write into. In some systems,
|
||
/usr/local/bin is allowed to contain programs with less strict
|
||
security screening - it is just removed from the path of the root
|
||
user. However, if it is known that some daemon executes 'foo' using
|
||
path '/usr/local/bin/:...', it may be possible to cheat daemon to
|
||
execute '/usr/local/bin/foo' instead of '/bin/foo'. Likely anybody
|
||
who can write to '/usr/local/bin' is able to break into the system.
|
||
|
||
It is very important to consider in what order the directories are in
|
||
the path. If /usr/local/bin is before /bin, it is a security risk -
|
||
if it is after, it is not possible to overwrite command /bin/foo with
|
||
some localized modification in /usr/local/bin/foo.
|
||
|
||
|
||
In Linux it should be remembered that the path evaluation is done in
|
||
the operating system call level. Everywhere where an executable file
|
||
path is given you can give a short name that is searched at least from
|
||
/bin and /usr/bin - likely from many other places as well.
|
||
|
||
|
||
|
||
13. How to debug problems?
|
||
|
||
|
||
The basic command to read environment is /usr/bin/env.
|
||
|
||
It is possible to use /proc directory to find out path of any program.
|
||
First you must know the process number - use ps command to get that.
|
||
For example, if xterm is process number 1088, you can find it's
|
||
environment with command
|
||
|
||
|
||
|
||
# more /proc/1088/environ
|
||
|
||
|
||
|
||
This does not work with daemon processes like xdm. To access
|
||
environment of system processes or other user processes, root access
|
||
is required.
|
||
|
||
To debug Netscape, you can create a script /tmp/test:
|
||
|
||
|
||
|
||
$ cat > /tmp/test
|
||
#!/bin/sh
|
||
/usr/bin/env > /tmp/env
|
||
^d
|
||
$ chmod +x /tmp/test
|
||
|
||
|
||
|
||
Then set some helper application, for example RealAudio, audio/x-pn-
|
||
realaudio to call program "/tmp/test". When you try to browse some
|
||
RealAudio link (something from http://www.realaudio.com/showcase),
|
||
Netscape calls the dummy program that stores environment to /tmp/env.
|
||
|
||
|
||
|
||
14. Some strategies to get the same path for all the users
|
||
|
||
|
||
The most important settings is possible to set in the global shell
|
||
initialization files for login shells: /etc/csh.login for tcsh and
|
||
/etc/profile for bash.
|
||
|
||
Exceptions that do not get the right path from these files are rsh
|
||
commands, ssh commands, menu items from X window manager that do not
|
||
explicitly start login shell, commands invoked from inittab, cron
|
||
jobs, daemons jobs like magic filters started from lprd, WWW CGI
|
||
scripts, and so on.
|
||
|
||
If the path is set in /etc/csh.cshrc, the path is right even when rsh
|
||
or ssh execute command in remote machine with account using tcsh/csh.
|
||
However, it is not possible to set path if account uses bash/sh.
|
||
|
||
|
||
It is possible to combine path setting to one file, for example to a
|
||
file /etc/environment-common. There we write:
|
||
|
||
|
||
|
||
${EXPORT}PATH${EQ}/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/X11:/usr/local/bin:/usr/games:.
|
||
|
||
|
||
|
||
This can be used from /etc/csh.login (for tcsh and csh)
|
||
|
||
|
||
|
||
set EQ=" " set EXPORT="setenv " source /etc/environment-common
|
||
|
||
|
||
|
||
And from /etc/profile (for bash, doesn't work for ordinary sh)
|
||
|
||
|
||
|
||
EQ='=' EXPORT="export " . /etc/environment-common
|
||
|
||
|
||
|
||
And from /etc/environment (for XDM)
|
||
|
||
|
||
|
||
EQ="=" EXPORT="export " . /etc/environment-common
|
||
|
||
|
||
|
||
This strategy works mostly but ssh will complain of the lines in
|
||
/etc/environment (and defined environment variables EQ and EXPORT).
|
||
And still, rsh commands executed with bash won't get this path.
|
||
|
||
|
||
|
||
15. Acknowledgements
|
||
|
||
|
||
One reason to start writing this document was the big frustration of
|
||
Ari Mujunen. Juha Takala gave some valuable comments.
|
||
|
||
|
||
|