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

On 24.01.2025 14:46, Dan Cross wrote:

In article <vmu94j$1q2lp$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:

>
Bash behaves strange here; 'which' doesn't find the executable but
nonetheless bash executes it, shows its output?

 
Bash doesn't behave strangely here at all.  Outside of its POSIX
mode, it's free to implement whatever behavior it likes with
respect to `~` expansion, and this is the behavior the author
has chosen.
 
But, critically, that does not mean that the programs _that it
invokes_ have to do the same.  So while `bash` can perform `~`
expansion on the components of $PATH when it's searching for a
program to execute, one shouldn't be surprised if other programs
don't do the same thing.

As I see it, Bash does the same correct assignment to PATH in
case the tilde-expression is quoted or unquoted; here there's
no difference. Quoted or escaped it's a literal tilde in PATH,
unquoted it's an expanded tilde-expression. (As in all those
shells; bash, ksh, zsh, dash, sh.)

 
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.

 

I've changed the above test frame to remove some unnecessary parts
to eliminate distracting complexity. The output for three shells:

 
Sorry, I think this cuts too much: the point was to show how the
different shells handle `~` in different contexts; the actual
strings that are in `$PATH` are important to show.

The actual strings and their handling WRT PATH is actually the
same in all these shells! Those test-cases have hidden the real
problem, so I reduced it to show that it's not (not per se) the
"tilde in PATH" that is the problem; Bash (as the other shells)
correctly expands an unquoted tilde-expression, and correctly
leaves it in PATH literally if it's quoted or escaped.

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 "~").

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.

That inconsistency - and deviating from all the other shells -,
if not a bug, looks like a Bad Design Idea if it's been done
deliberately. - YMMV.

Janis

[...]