On Saturday 19 May 2007 10:15, Carlos F Lange wrote: > ... > > Now, here is a puzzle: > > [EMAIL PROTECTED]:~> which time > /usr/bin/time > [EMAIL PROTECTED]:~> type time > time is a shell keyword > [EMAIL PROTECTED]:~> time --help > bash: --help: command not found > > real 0m0.011s > user 0m0.000s > sys 0m0.004s > > That is, in my case the built-in "time" has precedence, but "which" > is giving the impression that I would be running /usr/bin/time. If I > use the option -a: > [EMAIL PROTECTED]:~> which -a time > /usr/bin/time > [EMAIL PROTECTED]:~> type -a time > time is a shell keyword > time is /usr/bin/time
If the which command is the stock executable binary (often it's an alias to the BASH "type" built-in), then it does not know about built-ins in the shell that invoked and can tell you only about other stand-alone executables (binaries or scripts). > Since "which" gives out nothing in the case of a shell built-in > command, perhaps what it is doing everytime is 1) giving out nothing, > 2) giving out /usr/bin/time in second place. > So, "type" seems to be more useful here. Type is more useful since it has a greater scope. If you're inured to typing "which," then create an alias for it: alias which='type -p' (The "-p" option causes type to emit full path names, which makes its output compatible with that of "which".) You might want to know that there's a "-a" option to both "which" and "type" that cause them to print all instances of the named command in the PATH, instead of just the first one--the one you'll get if you just invoke the command without any path name qualification. > Carlos FL Randall Schulz -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
