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

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.