Re: bash should not alter PATH with 'command -p'

[Stephen Dowdy]

Chet,

Ha, yeah, i just repeated the bug you mention where PATH=... command -p ... leaves the PATH set that way in the caller context. (oops!).  Actually, in case it's relevant, i found a strange side-effect of that bug when a pipeline is involved (forgive my normal chaotic PATH)

    $ env | grep ^PATH
    PATH=/usr/sbin:/sbin:/opt/bin:/opt/sbin:/usr/local/jdk:/home/sdowdy/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/bin:/usr/bin
What's our caller's PATH env var?

    $ command -p env | grep ^PATH
    PATH=/bin:/usr/bin
(BUG) What happens (incorrectly) inside 'bash' ('bash' sets a temporary PATH, then invokes the command.)

    $ env | grep ^PATH
    PATH=/usr/sbin:/sbin:/opt/bin:/opt/sbin:/usr/local/jdk:/home/sdowdy/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/bin:/usr/bin
But, our PATH in the caller is still correct

    $ PATH=/usr/sbin:/sbin:/usr/bin:/bin command -p env >/dev/null
    $ env | grep ^PATH
    PATH=/usr/sbin:/sbin:/usr/bin:/bin
(BUG) PATH is now permanently set in caller environment when using a temporary invocation PATH value, whoops

    $ PATH=/usr/sbin:/sbin:/usr/bin:/bin command -p env | grep ^PATH
    PATH=/bin:/usr/bin
    $ env | grep ^PATH
    PATH=/usr/sbin:/sbin:/opt/bin:/opt/sbin:/usr/local/jdk:/home/sdowdy/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/bin:/usr/bin
PATH in caller is still the same (correct), due to some side-effect of doing this in a pipeline.

Again, thanks for the fix.  but, since i'm on Debian Stable, i'll see it in 3 years ;)

--stephen

On Thu, Jun 4, 2015 at 8:57 AM, Chet Ramey <chet.ramey@case.edu> wrote:

> Thanks for the response!  It's always fun trying to figure out what POSIX
> means.  I'm sure there's people who probably rely on the consequences of an
> altered PATH, too, so i don't expect you can make anyone happy whatever
> happens here.  (I would guess that a "reasonable" compromise might be to at
> least change the behaviour under 'bash --posix' or bash as /bin/sh, though
> that wouldn't help in the particular case affecting my script.

This turned out to be a little more involved than I thought, but I changed
things so that command -p won't change the $PATH.  If you want to have a
command-specific version of $PATH, you can use the temporary environment
for that, but there's no way to use command -p without modifying $PATH in
bash-4.3 and previous versions.

This uncovered a bug, too: if you use command -p with a temporary environment
assignment to PATH, that tempenv assignment is what persists after the
command completes.  My changes fix that also.

This will be in the next release of bash.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

--

Stephen Dowdy  -  Systems Administrator  -  NCAR/RAL
303.497.2869   -  sdowdy@ucar.edu        -  http://www.ral.ucar.edu/~sdowdy/