Deutsch   English   Français   Italiano  
<vmvo8t$261nd$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.unix.shell
Subject: Re: Default PATH setting - reduce to something more sensible?
Date: Fri, 24 Jan 2025 10:58:52 +0100
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <vmvo8t$261nd$1@dont-email.me>
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> <vmtrqk$92b$1@reader2.panix.com>
 <vmu94j$1q2lp$1@dont-email.me> <878qr1nqs0.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 24 Jan 2025 10:58:54 +0100 (CET)
Injection-Info: dont-email.me; posting-host="36489c0f4554701c0d6fd4073065c2d1";
	logging-data="2295533"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18x6fkkmh+pED2hJS6YmgXg"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:2qN75pThHEZ5GpOY1kLnJzGaNp4=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <878qr1nqs0.fsf@nosuchdomain.example.com>
Bytes: 4648

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.
>