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

On 23.01.2025 22:50, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

[...]
>
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:
>
[snip]
>
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].

 
I wouldn't call it a bug in bash.  Rather, it's a mismatch between bash
and which.

I'm not sure I can follow you what you mean by "a mismatch". Kornshell,
for example, also accesses /usr/bin/which (but it behaves correctly).

 
"which" is an external command, not a shell builtin.  [...]

Same in Ksh. Not so in Zsh. - But both of these shells behave correctly.

 
"type" is a bash builtin that mostly does what "which" does, but it also
has access to all of bash's internal information (functions, aliases,
keywords, builtin functions).  "type" is specified by POSIX for sh, with
a description that implies it must be a shell builtin command.  The bash
"type" command has several options as well.

One reason to prefer 'type'.

 
I'm not sure why bash users use "which" rather than "type".  I find
"type" far more useful.

Indeed. - For an explanation of the preference of 'which'; years long
experienced users may be used to 'which' back from 'csh' times. - I'm,
for example, primarily a Ksh user; nonetheless, instead of using Ksh's
'whence' or the standard 'type', my quick finger memory (often) types
'which'.

 
The weirdness here is that, [...]
 
Another thing to remember is that variable references are expanded
within double quotes, but ~ is not:

Yes, that's what I had explicitly pointed out in my post. - But Bash
as well does this specific thing correctly.

Janis

 
    $ echo "$HOME ~"
    /home/kst ~
 
Going off on a tangent, there's a recent trend to make /bin a symlink to
/usr/bin -- but the default $PATH on most systems still includes both
/usr/bin and /bin.  I wonder why that wasn't cleaned up.