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? > > [EMAIL PROTECTED] 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 > > > [EMAIL PROTECTED] user]# set -P > > [EMAIL PROTECTED] user]# cd public_html > > [EMAIL PROTECTED] 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. > > [EMAIL PROTECTED] user]# cd /home/user > > [EMAIL PROTECTED] user]# set +P > > [EMAIL PROTECTED] user]# cd public_html > > [EMAIL PROTECTED] 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? _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
