RE: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd

[Bojan Land]

On Fri, 2007-01-05 at 11:05 -0800, Matthew Woehlke wrote:
> (Next time, reply to the list, please! Which means send any replies to
> this message to bug-bash...) 

I clicked on reply to all, seems you didn't include the list in your
response previously nor this time!  I've included the list now but not
the newsgroup since Evolution doesn't post properly to usenet. :(

> > > IFS=: ; for p in $PATH ; do if [ -x ] <command> ... ; fi ; done
> > 
> > Why IFS=: ;?
> 
> That is 'IFS=:' followed by ';' which separates commands. I.e. we want
> to split on ':' which is the separator used in $PATH. The need for the
> ';' was previously discussed on this list; basically it has to do with
> the order in which bash does word splitting.

Ah, IFS is like -d in cut; indicates separator for entries in $PATH.

> 
> > If bash is what executes commands then why would a non-builtin have
> > greater authority?
> 
> If you are using bash, and you know you are using bash, then use 'type'.
> If, however, you need to figure out what program will be used in an
> arbitrary 'sh', the only way I know of to do that is as above. It
> *would* be even better to try to figure out what shell is in use and
> use a native method, if available, but 99% of the time you will get the
> same result anyway.

So you're recommending a builtin over an external?  This seems to
conflict with the statement that which is the best.  A bit confusing but
okay.

> > > If you need to find where a program is in $PATH, GNU 'which' will 
> > > always work. If you need to know what the shell will *actually 
> > > execute*, then (because of possible hashing, e.g. like bash's) you 
> > > need to use a shell built-in, because an external program will not 
> > > have knowledge of the shell's internal state.
> > 
> > This seems to contradict with not relying on type -p.  If a non-
> > builtin doesn't know of shell's internal state than relying on such
> > would not be a good idea since the shell executes non-builtins.
> 
> See above. If you KNOW you are in bash, then yes, use 'type'. If you
> need to write a portable shell script, then 'type' is not portable and
> you have to do a $PATH search yourself. But 99% of the time 'type' and
> 'which' (GNU) will give the same answer. If you do 'hash -r', then
> 'type -p <foo>' and (GNU) 'which <foo>' will be the same in all cases
> except race conditions (but note that this "assumes" that 'type -t
> <foo>'
> is "file").

Understandable.  I've only encountered race conditions within threading
or concurrent data accesses, not within an array traversal, but okay.

> > > it *is* a file. You're thinking of the 'file' program.
> > > Try 'file `which which`' or 'file <path-to-which>'.
> > 
> > Awesome!  This is the command I was trying to find!  Do you know if
> > magic is referenced by GUI frameworks such as GTK?
> 
> If you mean 'does GTK use "file"', I am reasonably confident that the
> answer is "no". But other things might use similar techniques to
> determine what sort of content is in a file.

I'll reference GNOME manuals regarding this as it's quite offtopic.

> > Seems like a single store of help would be a bit better off than
> having
> > duplicated partial help files all over the place accessible by various
> > utilities.  Are you aware of any such projects for a unified help
> > system, something like POSIX/XPG or whatever exists these days?
> 
> No. But personally, I disagree. If I want a quick refresher on what
> gcc option treats warnings as errors, I want a man page. If I want to
> know, in detail, how -fwrapv will affect my code, a man page is not
> going
> to have that information, but the texinfo (hopefully) will.

Yes, agreed!  However the file storage for each could be unified while
the tools transparently continue to provide the same user interaction.
I'll figure this out elsewhere as I think it's also offtopic.

> > I tried to reproduce the bug and I still cannot figure out how!  Can
> you
> > try to reproduce the results I got initially?
> 
> I took another look, but I'm not sure I understand what the problem was.
> My guess would be that you had '/home/user/bin' in your path and ran
> 'mycmd' so that it was hashed to /home/usr/bin, and that later you made
> /bin/mycmd. Thus when you later run 'mycmd', bash remembers that it is
> in
> /home/user/bin and does not do another $PATH lookup to find the one now
> in
> /bin. 'which' shows /bin/mycmd because it does not know about bash's
> hash.
> 
> You could test by temporarily removing /bin/mycmd (or
> 'chmod -x /bin/mycmd'), running 'mycmd' (to pick up the one in
> /home/user/bin), and replacing (or 'chmod +x'ing) /bin/mycmd.

1. Just to clarify, /bin/sh is a symlink to /bin/bash, just checked.
2. I didn't know about hashes until Bob's first reply.
3. There have been no system-wide shell changes in over a week.

Here is the new attempt to recreate the bug (or my lack of bash
knowledge as I'm starting to think from these replies).  I've done what
you've suggested, still the only time bash hashes is when I specifically
call hash.

# vi mycmd
# vi /bin/mycmd
# chmod u+x mycmd
# chmod u+x /bin/mycmd
# type -a mycmd
mycmd is /bin/mycmd
mycmd is /home/user/bin/mycmd
# pwd
/home/user/bin
# /bin/mycmd
hello you
# ./mycmd
hello me
# mycmd
hello you
# which mycmd
/bin/mycmd
# chmod -x /bin/mycmd
# mycmd
bash: /bin/mycmd: Permission denied
# ./mycmd
hello me
# type -a mycmd
mycmd is /home/user/bin/mycmd
# chmod u+x /bin/mycmd
# type -a mycmd
mycmd is /bin/mycmd
mycmd is /home/user/bin/mycmd
# /bin/mycmd
hello you
# ./mycmd
hello me
# hash mycmd
# type -a mycmd
mycmd is /bin/mycmd
mycmd is /home/user/bin/mycmd
# type mycmd
mycmd is hashed (/bin/mycmd)
# mycmd
hello you

Still unable to replicate those results!!!  LOL!  Also type -a does not
report which of the entries is hashed.

> > Also thank you for the usenet link - I would have asked there if I had
> > found it first.
> 
> Which was that, again? AFAIK, bug-bash is the correct place to ask about
> bash behavior, i.e. you are in the right place.

The first response I received from you did not have a To: line nor did
it have any reference to bug-bash@gnu.org in the headers, though it had
a newsgroup link to gmane.comp.shells.bash.bugs so I thought maybe I
should be posting there instead of on some isolated email list.