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.ra...@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 c...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - sdo...@ucar.edu - http://www.ral.ucar.edu/~sdowdy/
