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

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.