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

[Bob Proulx]

> I have learned a lot from your reply, and yes some of what you wrote
> explains this as not being a bug; after a reboot I cannot reproduce
> these results.

You should not need to reboot to clear a single shell process hash
cache.  Simply starting a fresh shell, such as opening a new window,
would have been sufficient.  (People often reboot because they have
learned this from MS but it is not needed most of the time when
running on a machine with a robust operating system.)

> Under what circumstances does the gnu-bash path hash differ from that of
> the $PATH variable?

This is possible when it has been cached by bash and then the
executable is either moved from its original location or a new
executable appears earlier in PATH.

> Why is it even possible for this difference to occur?

I do not know.  However it is traditional csh behavior and I assume
that bash implemented it for csh compatibility.

> >   type mycmd
> 
> $ type -t -p mycmd
> /bin/mycmd

Better to use 'type mycmd' as I said because then it would say what
type of a command that it was in the case of alias or other things.

> Seems type doesn't accept t and p at the same time, do you think it
> would be useful to have it say maybe "/bin/mycmd is a file" in this
> case?

It would have said that if you had not tried to use both options.  The
last one wins.

  type emacs
  emacs is /usr/bin/emacs

  type help
  help is a shell builtin

  type ll
  ll is aliased to `ls -l'

> Do you know which shells do not have type and thus rely on which?

As far as I know there is no portable way to get this information.  It
is impossible to determine this information portably without writing a
portable shell script and including it in the application needing this
information.

Traditional Unix machines used a csh script /usr/bin/which to search a
defined set of system paths.  Newer ksh used 'whence'.  Bash uses 'type'.
XSI extensions to POSIX require 'command -v'.  Debian implemented
'which' as a bash shell script and fixed problems with the csh
implementation making the Debian 'which' usable but different from
everyone else's 'which' command.

> Though these results of type are after a reboot; I cannot reproduce the
> results I emailed, would type have returned the same values?

No.  If cached then type would return the information from the hash.
Note my earlier example using emacs.  After running emacs the result
is now cached in the hash and produces this result.

  type emacs
  emacs is hashed (/usr/bin/emacs)

> > > lrwxrwxrwx  1 root root    24 Nov  4  2005 public_html -> 
> > > /var/www/html_users/user
> > 
> > > [root@host user]# set -P
> > > [root@host user]# cd public_html
> > > [root@host user]# pwd
> > > /var/www/html_users/user
> > 
> > Looks good.  Bash did not track the logical value of how you got there
> > but instead used the actual physical paths.
> 
> What do you consider the logical value and physical path?  The above
> commands make sense to me now; bash resolves the symlink target instead
> of relying on some other resolution, probably that of the filesystem.

Actually this is the simple case.  This is they way all shells
operated before code was added to them to track the logical path.  So
in this case bash is not doing anything interesting at all.  Using
physical paths is the "default" case.

> > > [root@host user]# cd /home/user
> > > [root@host user]# set +P
> > > [root@host user]# cd public_html
> > > [root@host public_html]# pwd
> > > /home/user/public_html
> > 
> > Looks good.  Bash remembered that it got there through the path
> > /home/user/public_html even though you are really someplace else
> > entirely.  If you 'cd ..' it will back up a directory and you will be
> > back in your /home/user directory.
> 
> Precisely!  With -P bash is literal by resolving symlinks, and "cd .."
> would not have resulted in staying within the same path.

I think that you are thinking about this backwards.  Bash is not
resolving the symlink.  The system is doing that when the chdir() call
is invoked.

Logical paths don't really exist.  They are only there because the
shell is keeping track of how you got there.  Wherever you happen to
be you can test this by using /bin/pwd and seeing what path it
produces.  It will always show you the real location.  The shell
constructs a logical environment and changes the behavior of 'cd ..'
so that the user can believe that this logical path is there when it
is not.

The ".." I am referring to is the "." and ".." entries in the
directory.  Here is an exercise for the reader.  When you are in a
"logical" directory try listing the directory above it with a 'ls ..'
command.  What directory does it list?  Does this match what the shell
would do with 'cd ..'?  Why not?

> > I can tell that there is still something that is not understood about
> > physical and logical paths but I don't know what the misunderstanding
> > is at this point.  Need more information.
> 
> That is precisely what I need an elaboration on.  Can you recommend a
> book, a site, or other resource that might cover these types of topics?

The bash documentation is quite good.  Look here:

  info bashref

Also bash comes with a lot of examples.  Browsing them is always
educational.

> p.s. I am not a bug-bash subscriber, are there other replies by any
> chance?  Should I subscribe as I am merely a user?

There have been no other replies.  You can browse the mailing list
archives here.  The archives are updated twice a day.  (Some people
prefer the gmane.com archive because of this.)

  http://lists.gnu.org/archive/html/bug-bash/2007-01/threads.html

Generally the GNU bug lists are open and you do not need to be
subscribed in order to post.  We welcome bug reports and do not
require people to subscribe to the mailing list in order to post bugs.
(However to avoid spam non-subscriber's postings will be held for a
human to review upon the initial contact.)  People who reply to bug
posters should always CC the original poster unless it is known that
they are also subscribed.

Bob