PATH setup

PATH setup

Post by Stephen Bayn » Tue, 04 Mar 1997 04:00:00



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?

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

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

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

5: Is there a poular location for the $ENV file? [I have seen ~/.env and
    ~/.kshrc]

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.

--

Philips Semiconductors Ltd                  
Southampton SO15 0DJ                        +44 (01703) 316431
United Kingdom                              My views are my own.
Do you use ISO8859-1? Yes if you see ? as copyright, as division and ? as 1/2.

 
 
 

PATH setup

Post by Brian S Hil » Tue, 04 Mar 1997 04:00:00


: 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_
shell processes.

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
own environment.

: 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:

CAT=/usr/bin/cat
LS=/bin/ls
WC=/bin/wc
...
$CAT path/to/file
...

... 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
:     ~/.kshrc]

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.

-Brian
--
   ,---.     ,---.     ,---.     ,---.     ,---.     ,---.     ,---.  
  /  _  \   /  _  \   /  _  \   /  _  \   /  _  \   /  _  \   /  _  \  

__,'   `.___,'   `.___,'   `.___,'   `.___,'   `.___,'   `.___,'   `.__

 
 
 

PATH setup

Post by Stephen Bayn » Thu, 06 Mar 1997 04:00:00




<snip>

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

I do mean the -p option, not the -r option. The main feature of the -p
option is that it stops the users $ENV file being executed. -r does
not stop the ENV file being executed. If you know any other way, other
than -p, of stoping the ENV file being executed by a script then I would be
pleased to hear it.

: 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

Yes that is the question. I don't think that they should be felt necessary to
do so either as it is a user-level feature. I would be stronger than that:
I would regard it as hazardous to exectute it. But then if this is undesirable
then why do shells do it by default? But you say:

: POSIX compatible ksh93 the ENV script is _only_ sourced for _interactive_
: shell processes.

Are you sure? That would be sensible and nice. However all versions of ksh and
the HPUX POSIX shell that I have met all execute the ENV script regardless
of the interactive mode.

<snip>
: 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
: own environment.

I am not worried about unsophisticated users using the default system setup.
I am worried about the moderately sophisticated ones who try and do 'clever'
things in their ENV files.

<some good recomendations snipped>

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

Thanks for the recommendations. Though I know these questions are often asked,
I have never seen them answered. I am surprised that there is not more on this
in the comp.unix FAQs. Also it is not just sysadmins who should be asking
them, anyone who develops shell scripts for unix should be asking them too.

--

Philips Semiconductors Ltd                  
Southampton SO15 0DJ                        +44 (01703) 316431
United Kingdom                              My views are my own.
Do you use ISO8859-1? Yes if you see ? as copyright, as division and ? as 1/2.

 
 
 

PATH setup

Post by Conrad E. Kimba » Thu, 06 Mar 1997 04:00:00




|> : 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.
 [ snip ]
|> : 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_
|> shell processes.
|>
|> 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.

 [ snip ]

Ummm... doesn't the -r option make it a restricted shell?  Not
quite what we want to do...

Another way to interpret the original question is:

    Given that $ENV has been set up by .profile, pointing to a set of
    who-knows-what commands, should the scripts in _my_ package take
    evasive measures to avoid automatically executing the $ENV file
    before ksh begins processing the commands in my script?

I believe the answer is _yes_.  As you point out ksh93 has this behavior
by default, but ksh88 does not - therefore, I make it a practice to
begin all my ksh scripts with the line:

   #!/bin/ksh -p

Yes, the -p option is described in terms of privileged mode, but for
ordinary, non-suid scripts it has the desireable side effect of ignoring
the $ENV variable.

(The $ENV file can wreak all kinds of havoc on your script.  How about
the "set -s" option, so it sorts all the positional parameters before
your script can parse them?  Or 'set -o noclobber" which will crash
your script if you redirect output to an existing file and didn't
happen to use the ">|" form of redirection?  Or "set -n", which will
simply cause your script to be a no-op?)

--
Conrad Kimball           | Client Server Tech Svcs, Boeing Information & Supt.

(206) 865-6410           | Seattle, WA  98124-0346

 
 
 

PATH setup

Post by David Boyc » Sun, 16 Mar 1997 04:00:00



  (Brian S Hiles) writes:
  |Another way to interpret the original question is:

      Given that $ENV has been set up by .profile, pointing to a set
  of
      who-knows-what commands, should the scripts in _my_ package take

      evasive measures to avoid automatically executing the $ENV file
      before ksh begins processing the commands in my script?

This is probably well known to these correspondents, and of course it's
not as reliable as using -p, but for the record: it's a good idea to
ask/beg/force users to place a line such as the following at the top of
$ENV, which will mimic the modern, correct shell behavior:

    [[ "$-" = *i* ]] || return 0

David

 
 
 

1. info path setup

Hi,

I found that /usr/share/info is not in my info path. How can I add
it to my default info path? thanks

--
Tong (remove underscore(s) to reply)
  *niX Power Tools Project: http://xpt.sourceforge.net/
  - All free contribution & collection

2. Hardwares en Linux

3. Problems with my PATH setup

4. Object Code Modifier for Linux 486?

5. Need Help On Path Setup For X

6. After recompiling kernel with PPP support, pppd says the kernel has no PPP support!

7. Ref Linux Device Driver Book - Examples/v2.1

8. path setup in RH 5

9. Search Path Setup

10. INCLUDE path setup

11. info path setup

12. Need Help On Path Setup For X