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

On 24.01.2025 22:34, Dan Cross wrote:

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

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.

 
Bash demonstrably does not assign the same thing to $PATH when
the `~` is quoted or escaped versus unquoted/unescaped: [...]

What I tried to express was that Bash does the same assignment
as the other shells; in both cases. In the quoted case it takes
it literally, and in the unquoted case it expands it. There's no
difference here. The assignments are all handled _consistently_
across all the shells including Bash.

 

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 it's not built into those shells, then those shells don't
"handle" `which` in any meaningful way, other than exec'ing it
as they would any other program.

The point is; 'which' should consider PATH, and Bash should
consider PATH. All shells (but Bash) do that in a consistent
way.

Depending on how the assignment had been made, literal tilde
or expanded tilde expression, the PATH value should be taken
as it is, IMO, and not tilde-expanded a second time.

This is nothing but a "creative" implementation in Bash; one
that is unnecessary, one that differs from the other shells,
and one that creates (IMO) inconsistent behavior, behavior
that lead to fancy suggestions to _not use_ tilde in PATH.

 
But `which` was just an example of a program that's not built
into the shell that inspects $PATH, which it inherited from the
shell that invoked it.
 
The interesting point of the example was to show that, [...]

I acknowledge and had acknowledged your test sample before.
(I just rewrite it for me to streamline the calls, isolate
and better see the source of the issue)

 

if 'which' ("/usr/bin/which") detects no program [in PATH] it
should not execute some program. Other shells do that correctly.

 
Why do you say this?  As I wrote earlier, nothing prevents
`bash` from treating $PATH however it likes outside of its POSIX
mode, and its behavior is entirely correct according to the
rules by which it does things.  If other shells do things
differently, then that's their behavior; bash need not be bound
by it.

Of course one can implement ones shell as he likes. As said
above, I like shells with a consistent implementation; where
a negative match of 'which' (or 'type' or 'whence') [for any
given program] should also result in the shells to not find
and execute it.

If the goal of your statement is just to say that implementers
can do what they like, I can agree. (But that's a rather weak
statement, IMO, and not very useful when valuating shells and
any [IMO] inconsistencies.) And if you think that my used term
"bug" for that is inappropriate, I can live with that as well.

[...]

>
The actual strings and their handling WRT PATH is actually the
same in all these shells!

 
No it's not; that was the point.

Above we agreed that the _variable_ assignment and expansion
of PATH is the same (in all shells). The difference [in Bash]
appears only when Bash does a PATH search to find appropriate
commands. My point was that this _path search_ does a second
expansion.

 

Those test-cases have hidden the real problem,

 
That's the thing; there is no "problem."  There are some
differences between how shells behave, but they're different
programs, so why is that bad?

Because it's inconsistent, it behavior is unexpected, it does
in a very subtle way surprise the users, and folks that know
this inconsistency advise to thus better not use '~' in the
first place; to me that's all clear factors why that is "bad".

 

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

 
I don't see any reason why that _must_ be true.

Well, we see that shells handle escaping/quoting of variables
in a _consistent_ way. Why should I believe that a shell value
with a tilde should be handled inconsistently?

If you set PATH=$HOME or PATH=~ all works smoothly. If you use
PATH='$HOME' or PATH='~' then these path components are taken
literally. But [in Bash] only in case of '$HOME'.

Any given shell is free to interpret $PATH any way it choses, [...]

(We had covered that already.)

 

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.

 
Yes.  That's precisely what I was showing.
 

Both of our test-cases
indicated that Bash seems to tilde-expand a PATH variable value
a second time;

 
I fail to see where this is being done a "second time": it seems
more likly that `bash` doesn't make any special note of the `~`
in `PATH="~/bin:whatever"` until it actuall goes to run a
program.

$ PATH='~/bin:/usr/bin:/bin' bash -c 'echo $PATH'
~/bin:/usr/bin:/bin

$ PATH='~/bin:/usr/bin:/bin' bash -c 'echo $PATH; quux'
~/bin:/usr/bin:/bin
xyzzy - ~/bin:/usr/bin:/bin

$ cat /home/jap/bin/quux
echo xyzzy - "$PATH"

 

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.

 
You seem to have invented a definition of "correct" here and are
pursuing it aggressively, but that is just one definition from
a large set of such definitions; there's no reason to assume the
behavior you expect here is any more correct than what `bash`
does.

The call it "consistent" vs. "inconsistent". (Modulo what we
have already said above.)

 

That inconsistency - and deviating from all the other shells -,

 
Careful: "all other shells" is a pretty big net, and it wouldn't
surprise me at all if this broke down if you expanded the set of
things you were looking at.  If you really want to twist your
nogging, have a look at what `csh` does, for example.

No, I will not compare the shells sensibly used for programming
with Csh.

I was aware that if I write "all other shells" that someone will
be pricking. I tried with the common shells (Ksh, Bash, Zsh, Sh,
Dash); I think this is a sensible set of shells to discuss things.

 

if not a bug, looks like a Bad Design Idea if it's been done
deliberately. - YMMV.

 
It's obviously being done deliberately, and is easy to find in
the source code:
https://git.savannah.gnu.org/cgit/bash.git/tree/findcmd.c#n533
 
You may consider it bad design, and you're well within your
rights to do so, but opinions on that vary, and it doesn't mean
yours is correct.

So you think that behavior of Bash is good design here? - Okay,
noted.

Janis

 
- Dan C.