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

On 26.01.2025 02:36, Keith Thompson wrote:

[...]
As far as I can tell (I haven't investigated), all Bourne-based
shells other than Bash treat $PATH in the same way when executing
commands.  Bash is the only shell I'm aware of that expands literal
'~' in $PATH.
 
The fact that it's not POSIX compliant behavior is at worst mildly
annoying.  Bash correctly disables it in POSIX mode (enabled by the
--posix option, by running "set -o posix", by setting $POSIXLY_CORRECT
before starting bash, or by invoking it sas "sh").

The problem I see with that is that you also disable other features,
sensible features, that are common in the prominent shells and that
you don't want to miss. - So Bash users, if they don't want to get
bitten in a subtle way, are probably advised to be pointed out to
that behavior, or, as suggested by others already, not to use tilde
at all with PATH in Bash.

 
I dislike the behavior because (a) it can quietly cause unexpected
problems (it's easy to miss the fact that $HOME is expanded within
double quotes and ~ is not), and (b) it's not documented.  I certainly
consider it a misfeature.  [...]

The consequences are yet more fundamental; if you observe the behavior
of other quotings as well...

Whether PATH='~' or PATH="~", both are stored as literal value in all
shells (including Bash!). - That's fine.

Where PATH='$HOME' is (as expected) stored as a literal value in all
shells (also in Bash) and PATH="$HOME" is (as expected) expanded in
all shells (also in Bash) and store in expanded form. - That's also
fine.

All the variable storage and quoting is fine and consistent across
all shells (including Bash).

But in Bash a literal '$HOME' doesn't get expanded during path search.
And you see '~' in a PATH as being stored literally but nonetheless it
gets expanded in the path search. - In other words; the problem is not
the quoting.

That's IMO so stupid a design that I can only explain it with no one
having been courageous enough over the many decades to fix that old
implementation. - Of course, the later you consider to fix such a
[mis-]design the harder you have it; development people are concerned
about software that is relying on that and thus reluctant to fix it.)

Janis