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