Path: ...!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.shell
Subject: Re: Default PATH setting - reduce to something more sensible?
Date: Thu, 23 Jan 2025 16:47:16 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vmtrqk$92b$1@reader2.panix.com>
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>
Injection-Date: Thu, 23 Jan 2025 16:47:16 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="9291"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 4197
Lines: 90

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;

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.

	- Dan C.