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

[Bojan Land]

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.

On Tue, 2007-01-02 at 10:50 -0700, Bob Proulx wrote:
> Did you previously reference the file and have that path cached?  

mycmd was created using vi and copied using cp prior to that which I
inquired about.

> This would mean that you would need to tell bash to discard the hash and to
> rehash everything.
> 
>   hash -r
> 

Under what circumstances does the gnu-bash path hash differ from that of
the $PATH variable?  Why is it even possible for this difference to
occur?

> > [user@host bin]$ which mycmd
> > /bin/mycmd
> 
> The which command is a standalone program (sometimes csh, sometimes
> bash, sometimes other things).  It will never have a hashed path.
> Better to use 'type' in this case.
> 
>   type mycmd
> 

$ type -t -p mycmd
/bin/mycmd

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?  Do you know which shells do not have type and thus rely on which?

> What does bash say the type of mycmd is?  

$ type -t mycmd
file

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

> I think it is previously
> hashed to /bin/mycmd and that after that point in your shell that you
> added the local ./mycmd.  If you started up a fresh shell it would not
> have been cached there.

I thought bash always referred to $PATH!  history shows several "exit"
commands followed by which, however there are no timestamps nor tty
references.  Is there another command that provides this info?

> 
> > BASHBUG2: description or implementation of option P
> 
> Need more information.
> 

I think now that it was just my lack of understanding of gnu-bash and
it's hash as I'll explain.

> > BUGDESC: When P is unset the symlink is still followed, though PS not
> > updated.
> > Reference from man:
> >     -P      If  set,  the shell does not follow symbolic links when
> >             executing commands such as cd that change  the current
> >             working  directory.   It  uses  the  physical directory
> >             structure instead.  By default, bash follows the logi-
> >             cal chain of directories when performing commands which
> >             change the current directory.
> 
> What is not clear about the description?  Can you suggest an
> improvement?

"If set, the shell does not follow symbolic links when executing
commands such as cd that change the current working directory." reminds
me of rbash; now that I know about there being a physical and logical
shell path the sentence afterwards makes sense; no longer does it seem
like a far too advanced concept relating to inodes.

> 
> > 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.

> > [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 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?

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?