Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd
Bojan Land wrote: 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? Because bash uses a hash to speed look-up of frequently used commands. The only way to (almost) always get the right command every time is to do a $PATH lookup every time, which would of course defeat the purpose of having a hash. At least, that's my guess. Anyway you would still have a race condition e.g. if PATH is '/usr/local/bin:/usr/bin:/bin' and a program appears in e.g. /usr/local/bin right after bash checks there (and, say, ultimately finds the program in /bin). By the time bash fork()s and exec()s, it is using the "wrong" version. So there isn't really any way to "fix" the problem; the hash just puts the onus on the user to force a refresh when things change (and meanwhile reduces I/O). -- Matthew Caution: keep out of reach of adults. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd
Bob Proulx wrote: Bojan Land wrote: Do you know which shells do not have type and thus rely on which? I wouldn't guess that *any* shell "relies" on 'which'... probably all shells have built-in $PATH lookup, but may not expose it to the user in the way bash's 'type' does. 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. Right; if you need the output of 'type', the safest way I know of is to roll your own function in portable shell script. 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. And newer GNU systems have GNU which; a stand-alone program that does neat things like read aliases from stdin so that you can do: $ which ll alias ll='ls -l --color=tty' /usr/local/bin/ls $ alias which alias which='alias | which -i' $ which --version GNU which v2.16, Copyright (C) 1999 - 2003 Carlo Wood. [snip] -- Matthew Caution: keep out of reach of adults. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd
Matthew Woehlke wrote: > Bob Proulx wrote: > > 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. > > And newer GNU systems have GNU which; a stand-alone program that does > neat things like read aliases from stdin so that you can do: > $ which ll > alias ll='ls -l --color=tty' > /usr/local/bin/ls > $ alias which > alias which='alias | which -i' > $ which --version > GNU which v2.16, Copyright (C) 1999 - 2003 Carlo Wood. Wonderful. Yet another 'which' implementation! Bob ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd
Bob Proulx wrote: Matthew Woehlke wrote: $ which --version GNU which v2.16, Copyright (C) 1999 - 2003 Carlo Wood. Wonderful. Yet another 'which' implementation! But a consistent (when available) one. :-) I like GNU programs because they are usually portable; for example I have built GNU 'which' on some 11 platforms, so now they all have the *same* which. And this one has "only" been around for about 8 years (according to the copyright)... -- Matthew Caution: keep out of reach of adults. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd
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 resul
Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd
Bojan Land wrote: > Bob Proulx wrote: > > 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. Right. "or a new executable appears earlier in PATH." I believe that after invoking the /usr/bin/ version you created a new executable by the same name earlier in PATH. > 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? -p only prints a path if the result is a file and has a path to print. > 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? There is no path for type -p help because help is a shell builtin and does not have a path. It does not exist on the filesystem. It exists only inside the shell as a builtin command. > I had never thus far ran the help builtin, ever! > I think I just found a new favorite command! Many thanks! Something for the future then. > > $ 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) Asking for the path would only print a path if it has a path to print. Since aliases do not have paths nothing is printed. > 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"? Perhaps someone else on the list will have a good suggestion. > Are sh and POSIX shell two different shells? Today they are the same. In old legacy systems /bin/sh was the Bourne shell. The Bourne shell predates the POSIX shell and is different. The Bourne shell does not have aliases or functions for example. But all modern systems have /bin/sh as the POSIX shell. (And before someone pipes in that Solaris /bin/sh is still the Bourne shell and that you need /usr/xpg4/bin/sh to get the POSIX shell let me say again, all *modern* systems have /bin/sh as the POSIX shell.) > > 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? Almost. In ksh whence is a builtin command the same as that in bash type is a builtin 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? Ask five people the same question and you will get seven different answers! These are different implementations by different people. Not having a standard in this area meant that there are no standards. They chose differently from each other. > 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: Probably version of shell differences. I don't know. > Is tracking the logical path only useful for simplicity and user > interface reasons? Yes. Although I disagree with simplicity. But it is there because users wanted it. > 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. That would be the -P setting. > No bashref from info, however there are html and ps versions. Well, that is probably a systems bug then. You might wish to file a bug report to whoever installed your system. > 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? I am not going to open that Pandora's box. > 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! I learn something new every day from people who post on the mailing lists. The community of people working to improve free software is an unmatched strength. Bob ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd
Bojan Land wrote: 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? No. According to 'help type', "If the -p flag is used, `type' either returns the name of the disk file that would be executed, or nothing if `type -t NAME' would not return `file'." Read especially the last phrase. Do you know which shells do not have type and thus rely on which? [snip] 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"? The only things I would ever rely on to find a program in $PATH are GNU 'which' (if by some miracle you know you have it) or writing a function in portable shell script yourself. I.e. something like: IFS=: ; for p in $PATH ; do if [ -x ] ... ; fi ; done 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? If you need to find where a program is in $PATH, GNU 'which' will always work. If you need to know what the shell will *actually execute*, then (because of possible hashing, e.g. like bash's) you need to use a shell built-in, because an external program will not have knowledge of the shell's internal state. 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!). 'type' isn't supposed to tell you anything about the file, just that is *is* a file. You're thinking of the 'file' program. Try 'file `which which`' or 'file '. type emacs emacs is hashed (/usr/bin/emacs) The results did not say hashed and I've tried it several times. Without checking, I want to say a command does not get hashed until/unless you actually /run/ it (or hash it manually, as you discovered). 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? Some packages (coreutils, for instance) document things in texinfo, and generate man pages from --help, so the man page is basically a "neater" --help. Other packages may provide 'real' man pages but also texinfo. Usually the texinfo is much more detailed; in some cases (I want to say gdb and gcc are good examples), it is an online version of a full reference manual that is also available in print. It is "useful" in that the man page is usually succinct, which is good for quick reference, and the texinfo is usually much more detailed, which is good when you need to know something the man page doesn't cover. (And if you didn't already see them, I left a few other replies in this thread.) -- Matthew Caution: keep out of reach of adults. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
