> 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 > > > > > [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. 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. > > > [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 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 _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
