: I am in the process of updating a package that uses lots of shell scripts and
: also tries to modifiy users .profile and $ENV files. This has raised a number
: of questions about what is _good_ practice, what is _conventional_ practice
: and what examples of _bad_ practice should one be aware off.
: I am assuming ksh (so setup files are .profile and $ENV) but most of this
: is also applicable to other shells.
: 1: Where is PATH set up? In the .profile or $ENV ? Should it matter?
ksh man page:
The shell gives default values to PATH, PS1, PS2, MAILCHECK, TMOUT and
IFS. HOME, MAIL and SHELL are set by login(1).
The default path is /usr/bin: (specifying /usr/bin and the
current directory in that order).
As the path should be setup once and presumably not be changed, it is
most commonly put in the user's .profile.
: 2: Should scripts normally execute the $ENV file or should they normally
: use -p to stop this. [My view is that they should normally use -p].
I sense confusion here; do you mean the -r option? The -p option
enables "privileged" suid-enabled scripts, even though ~/.profile is
then not sourced. Never use this feature for a user's shell unless you
understand completely the security implications.
If you are instead referring to whether scripts _themselves_ need to
source the ENV script; the question is complicated by wondering why it
is felt necessary to do so: this is a user-level feature. Indeed, in
POSIX compatible ksh93 the ENV script is _only_ sourced for _interactive_
A script will never be able to determine what the user's ENV file is
(indeed, even if this file is enabled) except by doing terrible kludges
like grep'ping for the ENV=... line in that user's .profile. Such
things should never be attempted in a system configuration script.
: 3: What can a script assume about any PATH it inherits?
: Will it include /bin ?
: Will standard commands such as ls be found correctly?
: Will it include other commands from the package that the script
: belongs to?
: [My view is it should assume nothing if it is to be directly invoked by
: a user.]
See (1). /bin is frequently linked from /usr/bin, and therefore by
default in the PATH -- note this is system dependent! My contention is
that a simple .profile containing a PATH sufficient to keep
unsophisticated users from complaining about unreachable executables
should be given each new user (for instance, are the users on graphic
terminals? Then you will of course need the path to include
/usr/bin/X11.) Of course, they should have permissions to modify their
: 4: If a script in a package cannot assume that other commands from the same
: package are in the PATH, what is the best way to locate them?
: By an environment variable (which means ensuring the user has set it up)?
: By a known (absolute) location (which means the script may have to be
: modified if the package is installed somewhere else or else a link
: set in a known place.)
: [We normally get the user to run a command once when he opts to use the
: package which sets a link in his home directory to the installation.
: Only that command has to know the location of the installation.]
By convention (and I agree with this) system configuration scripts
should not use commands that are resolved through path lookup. The frequent
idiom is to command:
... at the top of the script, for at least an attempt at easy porting.
: 5: Is there a poular location for the $ENV file? [I have seen ~/.env and
The "location" of an ENV file has never been to my knowledge _not_ in the
HOME directory (although this is not mandated.) It's _name_, OTOH, is
the user's prerogative, and it's up to them to create it.
: What set this off was a case of a script that added things to the PATH, ran
: another script which executed the users $ENV file which in this case reset the
: PATH--so the subscript failed because it needed the extra things in the PATH.
The "subscript", you say??
It occurs to me that you need to read a technical book that discusses
system administration in greater depth than here. I recommend first a
book tailored to your system, and second, to the excellent "Essential
System Administration" by O'Reilly and Associates. The questions you
give are ones that have been asked for generations :-) of UNIX sysadms.
,---. ,---. ,---. ,---. ,---. ,---. ,---.
/ _ \ / _ \ / _ \ / _ \ / _ \ / _ \ / _ \
__,' `.___,' `.___,' `.___,' `.___,' `.___,' `.___,' `.__