bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: posix command search and execution


From: Mike Jonkmans
Subject: Re: posix command search and execution
Date: Thu, 9 Nov 2023 14:21:35 +0100

On Wed, Nov 08, 2023 at 10:42:20AM -0500, Chet Ramey wrote:
> On 11/7/23 5:37 PM, Mike Jonkmans wrote:
> > On Tue, Nov 07, 2023 at 11:49:25AM -0500, Chet Ramey wrote:
> > > On 11/7/23 8:54 AM, Mike Jonkmans wrote:
> > So the discussion is hidden. Hmm.
> Not hidden; if you look at the open group's mailing list archives, you
> can find the messages. I just don't consider the interface usable. It's
> barely searchable.

Ah, thanks. I'll have a look later.

> > > > Then again, is there a requirement for the standard utilities to be
> > > > found in the current PATH? Or do they just need to be present somewhere.
> > > They have to be findable using the value returned by `getconf PATH'. If
> > > the user modifies PATH to, say, prepend directories before that standard
> > > PATH, then all bets are off.
> > I see. Weirdly on Ubuntu 22.04, with /bin symlinked to /usr/bin,
> > `getconf PATH' produces `/bin:/usr/bin'.
> > That looks like a recipe for redundant `stats'.
> Does that matter? The value getconf returns is static, and is guaranteed
> to find all the standard utilities regardless of what the file system
> looks like.

Maybe it matters.
If I am not mistaken, for POSIX compliance, both /bin and /usr/bin have
to be in PATH (see quote from Robert). 
A naïve implementation, doing a PATH search, might be calling `stat'
for both directories, whilst they are symlinked.
This might cost some performance.
[ Just checked: bash stats both. ]
Symlinking also meddles with the description below.

Relevant quote from Robert's mail:
It is actually messier that it first seems, if you have a builtin command,
it isn't simply finding that command's name in a PATH search that is
required, but that the directory (from PATH) in which it was found be the
one "associated" with the builtin command (how exactly that is determined,
or what it really even means is not specified anywhere).   The effect is
that if a shell with a builtin "test" believes that the associated
directory is /bin and someone's path is /usr/bin:/bin - and there is a
test command in /usr/bin (even if /usr/bin and /bin are the same directory,
or /bin/name and /usr/bin/name are linked and so invoke the same thing)
then the filesystem command is supposed to be invoked rather than the
builtin.    There are reasons for that, but they're really fairly stupid.

This is more complex than it needs to be (and should be).
For a user it is very hard to have any confidence in the posix-ness
of their scripts.


PS.
Remember this `nn'/`Pnews' message?
"Your message will cost the net hundreds if not thousands of dollars
to send everywhere."
What would the cost of all these extra `stat' calls be? ;)

-- 
Regards, Mike Jonkmans



reply via email to

[Prev in Thread] Current Thread [Next in Thread]