bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alterna


From: Matthew Woehlke
Subject: Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd
Date: Thu, 04 Jan 2007 12:52:57 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20061206 Thunderbird/1.5.0.9 Mnenhy/0.7.4.0

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 ] <command> ... ; 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 <path-to-which>'.

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]