On Wed, 2007-01-03 at 22:55 -0700, Bob Proulx wrote:
> > 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.)
Since I cannot be certain what I did to undo the problem, the only thing
I know for a fact that I did do that made a difference was to have
rebooted! Whether using a new shell or calling some command fixed the
problem, that I do not know - hence why I said I rebooted and the
problem was gone, because that's the only thing I know for certain.
> > 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.
I did not move the executable.
> > 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.
Is there a useful purpose, from a system administration point of view,
to having the hash path and $PATH contents differ? To me, this
difference could cause problems for us non-administrative types, who are
merely trying to cope with all the command lines and compatibility
glitches!
>
> > > 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.
If I just use 'type mycmd' the result is similar in that it simply
prepends the query before the result with " is " inbetween; -p prevents
this additional processing and output?
> > 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.
Yes, this is true.
> 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'
>
I get almost identical output except for ll due to local config
differences.
One clarification I need is for these results:
> $ type help
> help is a shell builtin
> $ type -p help
> $ type -t help
> builtin
> $
Why is there no output for -p? I had never thus far ran the help builtin, ever!
I think I just found a new favorite command! Many thanks!
> $ type which
> which is aliased to `alias | /usr/bin/which --tty-only --read-alias
> --show-dot --show-tilde'
> $ type -p which
> $ type -t which
> alias
> $
I was expecting the result of -p to be:
which is an alias
or even:
which is /usr/bin/which (aliased)
> > 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.
Before I compare every shell I can find possibly duplicating the work
that someone else must have already done in all the years unii have been
around, can you suggest a good place to start for this information
beyond the typical websearch of "unix shell comparison"? Are sh and
POSIX shell two different shells?
> 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'.
Is whence just an alias for which or a different approach?
> 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.
Seems there are three commands returning same results differently
encapsulated. Is there a purpose to having command, which and type on a
system or can one of them do the job of the other two? On my system
command and type are builtin while which is a binary (although type -t
only reports "file" and not what kind of file, whether binary or shell
script!).
$ command -v ls
alias ls='ls --color=tty'
$ which ls
alias ls='ls --color=tty'
/bin/ls
$ type ls
ls is aliased to `ls --color=tty'
> > 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)
The results did not say hashed and I've tried it several times. The
only way I can get type to report hashed is by using hash manually:
$ type emacs
emacs is /usr/bin/emacs
$ type help
help is a shell builtin
$ type ll
ll is aliased to `ls -l --color=tty'
$ type emacs
emacs is /usr/bin/emacs
$ hash emacs
$ type emacs
emacs is hashed (/usr/bin/emacs)
$ hash -r emacs
$ type emacs
emacs is hashed (/usr/bin/emacs)
$ hash -d emacs
$ type emacs
emacs is hashed (/usr/bin/emacs)
$ hash -r
$ type emacs
emacs is /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.
Is tracking the logical path only useful for simplicity and user
interface reasons?
> > 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?
Wow! That was awesome...
$ set +P
$ cd public_html/
$ pwd
/home/user/public_html
$ ls ..
ls: ..: Permission denied
$ cd ..
$ set -P
$ cd public_html/
$ ls ..
ls: ..: Permission denied
$ pwd
/var/www/html_users/user
$ cd ..
$ ls
ls: .: Permission denied
$ cd ..
$ ls
cgi-bin error html html_users html_users.bak icons manual usage
$
Being able to cd but not ls is like walking through a dark room without
any senses. I thought by setting +P prior to re-entering
html_users/user I would return to /home/user/public_html however that's
not the case.
> > > 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
>
No bashref from info, however there are html and ps versions.
I'm always amazed when I find many ways to see the same result, such as
man and info, however info and man return drastically different
documentation for info itself! It's as if my system has duplication of
documentation - is this useful somehow?
> Also bash comes with a lot of examples. Browsing them is always
> educational.
Thanks for reminding me that /usr/share/doc exists!
> 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.
You seem like someone who's administered many lists for a long time!
I've learned a lot just from these few emails, many thanks once again!
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
