Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.unix.shell
Subject: Re: Default PATH setting - reduce to something more sensible?
Date: Fri, 24 Jan 2025 14:00:46 -0800
Organization: None to speak of
Lines: 69
Message-ID: <871pwr6fe9.fsf@nosuchdomain.example.com>
References: <vm5dei$2c7to$1@dont-email.me> <vmthmu$3bb88$1@news.xmission.com>
	<vmtrqk$92b$1@reader2.panix.com> <vmu94j$1q2lp$1@dont-email.me>
	<vn05ji$r20$1@reader2.panix.com> <vn0bpf$29qe6$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 24 Jan 2025 23:00:47 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ce3eaee7b38cea081e4acffc0808b70e";
	logging-data="2554599"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19shbH13mfBVaDV3Qw0Y8af"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:oZ0t6rwgTS90P2wTG2p9RXrxNWY=
	sha1:+PvkzdkJeHF4Q6q5A8fbjRRe+vs=
Bytes: 4051

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 24.01.2025 14:46, Dan Cross wrote:
[...]
>> As was pointed out, `which` is not built into the shell, and
>> therefore, not obligated to follow `bash`'s expansion rules.
>
> And this (at least) seems to be the source of an inconsistency;
> 'which' is also in other shells not a built-in. But all other
> shells I tested (ksh, zsh, dash, sh) handle it consistently;
> if 'which' ("/usr/bin/which") detects no program [in PATH] it
> should not execute some program. Other shells do that correctly.

If by "correctly" you mean "POSIXly", you're right, but that's not the
only possible meaning of the word.

/usr/bin/which is limited in what it can do.  It follows POSIX-specified
behavior for $PATH; it doesn't recognize any shell-specific rules.

In particular, "which" does not handle:

- aliases
- shell functions
- shell builtin commands
- shell keywords (try "which if")
- Bash-specific behavior for literal '~' in $PATH

The behavior of "which" when searching in $PATH does match the behavior
of bash *in POSIX mode*.

I do agree that bash's non-POSIX behavior is a misfeature, possibly a
bug, but because it can be invoked accidentally and cause inconsistent
behavior when invoking commands directly vs. indirectly, not because it
doesn't match the behavior of /usr/bin/which.  (And because it's
undocumented.)

[...]
> The settings  PATH=~/bin  and  PATH="~/bin"  respectively shall
> result in the same behavior across shells when searching for
> programs; in the first case looking into "/home/someuser/bin/"
> and in the second case looking into "./~/bin/" (i.e. a path
> component with a local directory named "~").

What do you mean by "shall result?

All shells that conform to POSIX behave as you describe.  bash doesn't
conform to POSIX unless you ask it to.  Neither do csh, tcsh, and fish.

> It appears as if Bash invokes a tilde-expansion twice(!); once
> [if unquoted] when the assignment happens, and another time
> when the path-search is actually done. Both of our test-cases
> indicated that Bash seems to tilde-expand a PATH variable value
> a second time; so while 'which' (as other shells and programs)
> will not find any executable in "./~/bin/" (which would be the
> correct interpretation of a quoted "~/bin") Bash does.

Bash does something similar to tilde-expansion when searching $PATH for
a command, but tilde-expansion involves replacement of words on the
command line, whereas its treatment of literal ~ in $PATH happens
internally.  This is admittedly a minor quibble.

BTW, it hadn't occurred to me that you can have a relative path in a
component of $PATH, but it does seem to work.  I won't be taking
advantage of this information.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */