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

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

On 24.01.2025 14:46, Dan Cross wrote:

[...]

As was pointed out, `which` is not built into the shell, and
therefore, not obligated to follow `bash`'s expansion rules.

>
And this (at least) seems to be the source of an inconsistency;
'which' is also in other shells not a built-in. But all other
shells I tested (ksh, zsh, dash, sh) handle it consistently;
if 'which' ("/usr/bin/which") detects no program [in PATH] it
should not execute some program. Other shells do that correctly.

If by "correctly" you mean "POSIXly", you're right, but that's not the
only possible meaning of the word.

/usr/bin/which is limited in what it can do.  It follows POSIX-specified
behavior for $PATH; it doesn't recognize any shell-specific rules.

In particular, "which" does not handle:

- aliases
- shell functions
- shell builtin commands
- shell keywords (try "which if")
- Bash-specific behavior for literal '~' in $PATH

The behavior of "which" when searching in $PATH does match the behavior
of bash *in POSIX mode*.

I do agree that bash's non-POSIX behavior is a misfeature, possibly a
bug, but because it can be invoked accidentally and cause inconsistent
behavior when invoking commands directly vs. indirectly, not because it
doesn't match the behavior of /usr/bin/which.  (And because it's
undocumented.)

[...]

The settings  PATH=~/bin  and  PATH="~/bin"  respectively shall
result in the same behavior across shells when searching for
programs; in the first case looking into "/home/someuser/bin/"
and in the second case looking into "./~/bin/" (i.e. a path
component with a local directory named "~").

What do you mean by "shall result?

All shells that conform to POSIX behave as you describe.  bash doesn't
conform to POSIX unless you ask it to.  Neither do csh, tcsh, and fish.

It appears as if Bash invokes a tilde-expansion twice(!); once
[if unquoted] when the assignment happens, and another time
when the path-search is actually done. Both of our test-cases
indicated that Bash seems to tilde-expand a PATH variable value
a second time; so while 'which' (as other shells and programs)
will not find any executable in "./~/bin/" (which would be the
correct interpretation of a quoted "~/bin") Bash does.

Bash does something similar to tilde-expansion when searching $PATH for
a command, but tilde-expansion involves replacement of words on the
command line, whereas its treatment of literal ~ in $PATH happens
internally.  This is admittedly a minor quibble.

BTW, it hadn't occurred to me that you can have a relative path in a
component of $PATH, but it does seem to work.  I won't be taking
advantage of this information.

[...]

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