Re: PATH and $0

[Stephane Chazelas]

On Sat, Aug 12, 2006 at 01:51:12AM -0600, Bob Proulx wrote:
> Stephane Chazelas wrote:
> >   [ -e "$cmd" ] || cmd=$(command -v -- "$cmd") || exit
> > Bob Proulx wrote:
> > > Of course using command as you have done will work for bash.
> > 
> > "command" is a POSIX command. So will work with every POSIX and
> > therefore every Unix conformant sh.
> 
> That is not strictly true.  While 'command' is POSIX 'command -v'
> is actually an optional extension.  A system only claiming POSIX
> conformance need not implement 'command -v'.  See the online standards
> documents for more information.
> 
>   http://www.opengroup.org/onlinepubs/009695399/utilities/command.html

You're right. command -v is not required by POSIX, but required
by Unix (XSI). A lot of shells (like bash) are only POSIX
conformant.

> And in fact the FreeBSD /bin/sh (among others) implements 'command'
> but not 'command -v'.  So in practice it is not as portable as I would
> like it to be.

According to the man page, it does at least in 6.1-RELEASE.

See:

http://www.freebsd.org/cgi/man.cgi?query=sh&sektion=1&apropos=0&manpath=FreeBSD+6.1-RELEASE

[...]
> > 1- If IFS was unset before, it becomes set to the empty string
> > after which has a different meaning.
> 
> Your posted script did not unset IFS.  Therefore that is not a concern
> there.  I would not prefer 'command -v' over this because someone
> might unset IFS.  There are lots of worse things that are possible.

I was speaking of the general case:

oIFS=$IFS
...
IFS=$oIFS

doesn't restore IFS in every case.

> > 2- word splitting when IFS contains non-blank characters varies
> > from one shell to the next, and in most implementations
> > (including bash and AT&T ksh, it differs from the way the shell
> > splits $PATH internally to look up a command ("/bin:" is "/bin"
> > and "" as far as PATH look up is concerned
> 
> Negative.  In AT&T ksh (and others) "/bin:" is "/bin" and "." for PATH
> lookup.


No, it's "/bin" and "". the shell tries to exec "/bin/foo" then
"foo", not "/bin/foo" and "./foo". But any what I meant was
"/bin:" means /bin and the current directory for PATH lookup,
but not for bash word splitting.

> > while bash world splitting splits "/bin:" into only "/bin").
> 
> Negative.  In bash "/bin:" is "/bin" and "." for PATH lookup.

I was speaking of "bash word splitting" not PATH lookup, that
was my whole point: you can't use word splitting that way
because it doesn't match the way the shell does the PATH lookup.

> 
> > 3- you forgot to disable filename generation, which means
> > wildcards will be expanded in "for p in $PATH"
> 
> Negative.  Wildcards will not be expanded there.

Yes, they will:

Try:

foo='a:*:b'
IFS=:
for i in $foo; do echo "$i"; done


regards,
Stephane