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: Thu, 23 Jan 2025 21:34:27 +0100
Organization: A noiseless patient Spider
Lines: 148
Message-ID: <vmu94j$1q2lp$1@dont-email.me>
References: <vm5dei$2c7to$1@dont-email.me> <20250122120930.74@kylheku.com>
 <ccr96l-eot.ln1@ID-313840.user.individual.net>
 <vmthmu$3bb88$1@news.xmission.com> <vmtrqk$92b$1@reader2.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 23 Jan 2025 21:34:28 +0100 (CET)
Injection-Info: dont-email.me; posting-host="efa7a3f102c88f09b6d8a3882681d5f0";
	logging-data="1903289"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX181ETWPF+nVZ3UW4y7Ru2FT"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:bF0Kagj6WtaC3neAADRa6RVvwW8=
In-Reply-To: <vmtrqk$92b$1@reader2.panix.com>
X-Enigmail-Draft-Status: N1110
Bytes: 6309

On 23.01.2025 17:47, Dan Cross wrote:
> In article <vmthmu$3bb88$1@news.xmission.com>,
> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <ccr96l-eot.ln1@ID-313840.user.individual.net>,
>> Geoff Clare  <netnews@gclare.org.uk> wrote:
>> ...
>>> Yes.  Perhaps I trimmed too much.  The post I was replying to said
>>> "$HOME/bin [..] is better than ~/bin, because tilde expansion is not,
>>> AFAIK, included in POSIX" and $HOME is also, of course, expanded before
>>> PATH is assigned.  So there is no reason to prefer $HOME/bin over ~/bin
>>> since (when used in an assignment) they are equivalent in POSIX.
>>
>> 1) I have no idea what your beef with Kaz is.  It seems silly at best.
> 
> The response you're replying to seemed pretty collegial to me;
> am I missing something?
> 
>> 2) I know this isn't going to sit well with you, but there absolutely are
>> situations (in bash) where ~ doesn't work as a substitute for $HOME, when
>> setting the various "path" variables.  I know that I had lines in .profile
>> and/or .bashrc like: PATH=~/bin:$PATH (and similar) that did not work (that
>> is, the value stored in the variable contained an explicit tilde rather
>> than the expanded value - and this, of course, doesn't work at runtime).
>> Replacing the tilde with $HOME fixes this.
>>
>> Sorry I don't have details, but it is true nonetheless.
> 
> I think the issue is that one wants to prevent a literal string
> like `~/bin` from showing up in $PATH.  While a given shell
> _may_ interpret such $PATH components as being relative to the
> user's home directory (`bash` does) others may not (`ksh` does
> not, at least not by default).
> 
> Further, C library functions like `execlp`, `execvp` and
> `execvpe` that refer to $PATH may not handle `~` expansion, and
> are not mandated to where defined by e.g. POSIX.  Similarly for
> analogous functions in other programming languages.  Given that
> programs that make use of those functions inherit $PATH when
> invoked from a shell, this can lead to unexpected behavior in a
> way that's hard to diagnose ("it works fine when I run this
> program from the shell, but my editor can't find it!").
> 
> Also, it's not the case that shells always expand `~` when
> setting $PATH, even when $HOME would be expanded, as Kenny
> points out.  Here's an example:
> 
> : term; echo $HOME
> /home/cross
> : term; pwd
> /home/cross
> : term; echo echo xyzzy >bin/quux
> : term; chmod +x bin/quux
> : term; which quux
> /home/cross/bin/quux
> : term; quux
> xyzzy
> : term; exec ksh
> : term; export PATH=~/bin:/bin:/usr/bin
> : term; echo $PATH
> /home/cross/bin:/bin:/usr/bin
> : term; which quux
> /home/cross/bin/quux
> : term; quux
> xyzzy
> : term; export PATH="$HOME/bin:/bin:/usr/bin"
> : term; echo $PATH
> /home/cross/bin:/bin:/usr/bin
> : term; which quux
> /home/cross/bin/quux
> : term; quux
> xyzzy
> : term; export PATH="~/bin:/bin:/usr/bin"
> : term; echo $PATH
> ~/bin:/bin:/usr/bin
> : term; which quux
> : term; quux
> ksh: quux: not found
> : term; exec /usr/pkg/bin/bash
> : term; echo $PATH
> ~/bin:/bin:/usr/bin
> : term; which quux
> : term; quux
> xyzzy
> : term;

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

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

Bash:
/home/jap/bin/quux
xyzzy
/home/jap/bin/quux
xyzzy
xyzzy
# nothing returned from 'which' (silent), *no error* on call [***]

Ksh:
/home/jap/bin/quux
xyzzy
/home/jap/bin/quux
xyzzy
ksh: quux: not found
# nothing returned from 'which' (silent), error on call

Zsh:
/home/jap/bin/quux
xyzzy
/home/jap/bin/quux
xyzzy
quux not found
zsh:1: command not found: quux
# diagnostic returned from 'which', error on call

I'm not sure whether that effect is (as was suspected) an effect of
a quoted '~'; it seems to be some different problem, in Bash.[***]

For all these shells a quoted '~' as in the PATH assignation will be
stored as a literal and will not get expanded; so far, so expected.

A quoted '~' will not get expanded, so the result is not surprising.
Tilde expansion comes before quote removal. (In Ksh, to be sure, and
obviously also in the other shells, and I'd suppose also according
to POSIX.)

> 
> I suppose the moral is, for maximal portability, prefer using
> $HOME (or another similar variable) to `~` when setting $PATH
> unless you're doing so in a context where you are sure that `~`
> will be expanded during assignment.

IMO, the consequence is to not quote a tilde expression in the first
place if you want it expanded in a shell variable. *Violating* that
rule will _in Bash_ produce this strange effect (in the given setup).

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

My 2 cents.

Janis

> 
> 	- Dan C.
>