Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.unix.shell
Subject: Re: Default PATH setting - reduce to something more sensible?
Date: Sat, 25 Jan 2025 12:28:17 +0100
Organization: A noiseless patient Spider
Lines: 215
Message-ID: <vn2hsj$2pe96$1@dont-email.me>
References: <vm5dei$2c7to$1@dont-email.me> <vmu94j$1q2lp$1@dont-email.me>
 <vn05ji$r20$1@reader2.panix.com> <vn0bpf$29qe6$1@dont-email.me>
 <vn110t$faa$1@reader2.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 25 Jan 2025 12:28:19 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d6ec0c6c1fe60ff983fa5a67ee291d8d";
	logging-data="2930982"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+mTpnc7+qD3Ml8KYEtrQwj"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:wp26UGx+2QETsIjiEEv8drWrvx0=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <vn110t$faa$1@reader2.panix.com>
Bytes: 9521

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.

========== REMAINDER OF ARTICLE TRUNCATED ==========