Re: Default PATH setting - reduce to something more sensible?

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 23.01.2025 22:50, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

[...]

To me it appears that not finding (by 'which') an executable but
executing it nonetheless qualifies as a bug [in Bash].

 
I wouldn't call it a bug in bash.  Rather, it's a mismatch between bash
and which.

>
I'm not sure I can follow you what you mean by "a mismatch". Kornshell,
for example, also accesses /usr/bin/which (but it behaves correctly).

/usr/bin/which is not tied to any shell.  Kornshell accesses
"/usr/bin/which" if you type "which" or "/usr/bin/which" at the
prompt -- like any other external command.

From the which(1) man page (emphasis added):

    which returns the pathnames of the files (or links) which would be
    executed in the current environment, had its arguments been given as
    commands **in a strictly POSIX-conformant shell**.  It does this by
    searching the PATH for executable files matching the names of the
    arguments.  It does not canonicalize path names.

bash, unless it's in POSIX mode, is not a strictly POSIX-conformant
shell.  The feature is disabled when bash is in POSIX mode.  It's to be
expected that "which" doesn't know about this.

One could argue that bash's behavior is a legitimate and useful
extension.  If so, this is a mismatch between bash and which.  There's
nothing inherently wrong with bash having non-POSIX extensions,
particularly since bash has a "--posix" option to disable them.

But since the feature is undocumented and can quietly lead to
inconsistent behavior, I would actually argue that it's a bug in bash,
or at least a misfeature.  (It turns out that bash has had this feature
from its earliest days.)

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */