Re: posix command search and execution

[Chet Ramey]

On 11/9/23 11:17 AM, Mike Jonkmans wrote:

On Thu, Nov 09, 2023 at 10:12:06PM +0700, Robert Elz wrote:

 Date:Thu, 9 Nov 2023 14:21:35 +0100
 From:Mike Jonkmans 
 Message-ID:  <20231109132135.ga208...@jonkmans.nl>

   | If I am not mistaken, for POSIX compliance, both /bin and /usr/bin have
   | to be in PATH (see quote from Robert).

No, I didn't say that, there are no particular required directory
names, just that PATH needs to include whatever directories contain
all the standard utilities ... getconf() returns that path.

I used those names just as an example.


Ah, that is clear then.
On Ubuntu 22.04 `getconf path' returns /bin:/usr/bin
and these are symlinked.


Then that's an issue to take up with Debian/Ubuntu, right? If they're
symlinked by the distro, then getconf PATH should only return one of them.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: posix command search and execution

[Chet Ramey]

On 11/9/23 8:21 AM, Mike Jonkmans wrote:



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


No, POSIX doesn't have anything to do with actual paths. Those are
completely implementation-dependent. That's how non-Unix systems can be
POSIX-conformat.



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.


That's one reason this aspect of POSIX is widely ignored. It will be
easier to ignore it in the next version of the standard (not that it
wasn't before) because of the `intrinsics' concept.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: posix command search and execution

[Chet Ramey]

On 11/8/23 6:40 PM, Mike Jonkmans wrote:

On Wed, Nov 08, 2023 at 11:52:19PM +0700, Robert Elz wrote:

 Date:Tue, 7 Nov 2023 23:04:10 +0100
 From:Mike Jonkmans 
 Message-ID:  <20231107220410.gc27...@jonkmans.nl>

   | It makes sense to partition the builtins in three categories with
   | a separate name for each.

That's more or less what has been done now, with the specials, intrinsics,
and regular builtins.


A step in the right direction.
In 30 years or so we may lose the special builtins ;)


Special builtins are here to stay in POSIX.


   | Are scripts in /etc/profile considered part of the implementation?
So, no, I don't think so.


I don't want to start a flame war, but Chet thought it was. :)


It depends on who supplies /etc/profile, doesn't it? If it comes as part
of the distro, whoever it is, it's part of the "implementation."

If the system with the /etc/profile as distributed is what undergoes
POSIX certification (hypothetically), then it's certainly part of the
implementation.

I don't think something admin-installed is part of the "implementation."



Yes, but the point is that this isn't what the standard says, more like
what it really should say.   This PATH search for builtins stuff is an
invention by people trying to force something upon shells that none of
them implemented, because they thought it would be better.


Ouch.


The standard developers at the time made a decision to prioritize third-
party developers (script writers) over shell implementors, invented
something they thought would do that, didn't specify anything concrete,
and expected the shell implementors to do something "because it's in the
standard." Implementors basically told them to pound sand.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: posix command search and execution

[Chet Ramey]

On 11/8/23 5:10 PM, Mike Jonkmans wrote:


Can this intrinsic list be amended with any user loaded builtins?

You mean enable -f? It's up to the shell implementation. Bash treats
dynamically-loaded builtins the same as any other builtin.


That was indeed what I meant.
Does the new POSIX version with intrinsics also allow for this?


POSIX has nothing to say about it, so yes.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: the portability of seq(1) (was: Idea: jobs(1) -i to print only :%ID:s)

[Greg Wooledge]

On Fri, Nov 10, 2023 at 01:09:29PM -0600, G. Branden Robinson wrote:
> At 2023-11-10T10:54:52-0800, Eric Pruitt wrote:
> > From _seq(1)_ on FreeBSD:
> > 
> > > The seq command first appeared in Version 8 AT UNIX. A seq command
> > > appeared in NetBSD 3.0, and was ported to FreeBSD 9.0. This command
  ^^
> > > was based on the command of the same name in Plan 9 from Bell Labs
> > > and the GNU core utilities. The GNU seq command first appeared in
> > > the 1.13 shell utilities release.

> That leaves NetBSD (data point requested), and I stumbled into seq's
> absence when building groff 1.23.0 release candidates for Solaris 10
> (maybe 11 too).

Apparently present in NetBSD 3.0.  Easily confirmed by going to
 as well.

the portability of seq(1) (was: Idea: jobs(1) -i to print only :%ID:s)

[G. Branden Robinson]

At 2023-11-10T10:54:52-0800, Eric Pruitt wrote:
> On Fri, Nov 10, 2023 at 01:22:54PM -0500, Greg Wooledge wrote:
> > It most definitely is *not* everywhere.  It's part of GNU coreutils,
> > and is generally not present on any system that does't use those
> > (BSDs and commercial Unixes for example).
> 
> From _seq(1)_ on FreeBSD:
> 
> > The seq command first appeared in Version 8 AT UNIX. A seq command
> > appeared in NetBSD 3.0, and was ported to FreeBSD 9.0. This command
> > was based on the command of the same name in Plan 9 from Bell Labs
> > and the GNU core utilities. The GNU seq command first appeared in
> > the 1.13 shell utilities release.
> 
> From _seq(1)_ on OpenBsd:
> 
> > A seq command appeared in Version 8 AT UNIX. This version of seq
> > appeared in NetBSD 3.0 and was ported to OpenBSD 7.1.

That leaves NetBSD (data point requested), and I stumbled into seq's
absence when building groff 1.23.0 release candidates for Solaris 10
(maybe 11 too).

https://git.savannah.gnu.org/cgit/groff.git/tree/HACKING?h=1.23.0#n98

Regards,
Branden


signature.asc
Description: PGP signature

Re: Idea: jobs(1) -i to print only :%ID:s

[Greg Wooledge]

On Fri, Nov 10, 2023 at 10:54:52AM -0800, Eric Pruitt wrote:
> > A seq command appeared in Version 8 AT UNIX. This version of seq
> > appeared in NetBSD 3.0 and was ported to OpenBSD 7.1.

Ah, I'm a year and a half behind.  OpenBSD 7.1 was released April 2022.

Re: Idea: jobs(1) -i to print only :%ID:s

[Eric Pruitt]

On Fri, Nov 10, 2023 at 01:22:54PM -0500, Greg Wooledge wrote:
> It most definitely is *not* everywhere.  It's part of GNU coreutils,
> and is generally not present on any system that does't use those (BSDs
> and commercial Unixes for example).

>From _seq(1)_ on FreeBSD:

> The seq command first appeared in Version 8 AT UNIX. A seq command
> appeared in NetBSD 3.0, and was ported to FreeBSD 9.0. This command
> was based on the command of the same name in Plan 9 from Bell Labs and
> the GNU core utilities. The GNU seq command first appeared in the 1.13
> shell utilities release.

>From _seq(1)_ on OpenBsd:

> A seq command appeared in Version 8 AT UNIX. This version of seq
> appeared in NetBSD 3.0 and was ported to OpenBSD 7.1.

Re: Idea: jobs(1) -i to print only :%ID:s

[Steffen Nurpmeso]

Greg Wooledge wrote in
 :
 |On Fri, Nov 10, 2023 at 06:59:10PM +0100, Steffen Nurpmeso wrote:
 |> Sequences are also bash-only (though seq(1) is
 |> everywhere).
 |
 |It most definitely is *not* everywhere.  It's part of GNU coreutils,
 |and is generally not present on any system that does't use those (BSDs
 |and commercial Unixes for example).

It is everywhere.  Including my static busybox.
Which BSD do you use?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Idea: jobs(1) -i to print only :%ID:s

[Greg Wooledge]

On Fri, Nov 10, 2023 at 06:59:10PM +0100, Steffen Nurpmeso wrote:
> Sequences are also bash-only (though seq(1) is
> everywhere).

It most definitely is *not* everywhere.  It's part of GNU coreutils,
and is generally not present on any system that does't use those (BSDs
and commercial Unixes for example).

Re: Idea: jobs(1) -i to print only :%ID:s

[Steffen Nurpmeso]

Chet Ramey wrote in
 <7402031f-424c-4766-ba70-71771c9dc...@case.edu>:
 |On 11/8/23 8:12 PM, Steffen Nurpmeso wrote:
 |> The "problem" with the current way bash is doing it is that bash's
 |> job handling does not recognize jobs die under the hood:
 |> 
 |>$ jobs
 |>[1]-  Stopped LESS= less -RIFe README
 |>[2]+  Stopped LESS= less -RIFe TODO
 |>$ kill $(jobs -p)
 |>$
 |> 
 |> ^ nothing
 |> 
 |>$ jobs
 |>[1]-  Stopped LESS= less -RIFe README
 |>[2]+  Stopped LESS= less -RIFe TODO
 |
 |Yes, the jobs are still stopped, and will remain stopped until they get
 |a SIGCONT. Do you think that kill, when given a pid argument, should look
 |up any job associated with that pid and send it a SIGCONT? Or should it
 |send a SIGCONT to the pid unconditionally? If so, what about other
 |processes in that job?

Hm coming from this other side is also an interesting thing, but
which i did not think about.  I mean .. "if the lookup is fast"
kill(1) could of course throw all of its arguments against the
list of tracked processes, not only %job specifications.

(Having said that i am personally still hoping for a shell syntax
extension that closes the race condition of PID reuse against
kill(1), in that if i "kill -TERM ID" where ID is known to be
a monitored process, but which has terminated, the shell will
reject doing the kill as such.  Also the "kill -0 && kill -X" gap
is a race in itself.  But that is of course a different topic.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Idea: jobs(1) -i to print only :%ID:s

[Steffen Nurpmeso]

Hello.

Oğuz wrote in
 :
 |On Thursday, November 9, 2023, Steffen Nurpmeso  wrote:
 |> I mean some scripting on "jobs | wc -l" would do that, though. :(
 |> Maybe i should just write a function that builds the string
 |> necessary to do what i wanted with %* or "%1-2 %4" etc.
 |> Eh.  Forget about it.
 |
 |Can't you abuse jobs -x somehow? Like this perhaps
 |
 |jobs -x printf '%s\n' %{1..100} | awk '!/%/{print "%"NR}'

Well i first thought "this is darn smart", but then realized this
is at the level of that wc -l thing which is definetely the wrong
thing to do.  Sequences are also bash-only (though seq(1) is
everywhere).  But thanks.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Defaults when cross-compiling

[Chet Ramey]

On 11/8/23 9:59 PM, Michael T. Kloos wrote:
It seems to me that Autoconf (configure) is making some bad choices if it 
is just guessing that support exists like that, especially when it has a 
guaranteed fallback.  It's job is to setup the build for the target host 
system.


I think you don't need to work in absolutes like that. That's an awful
lot of systems you'd be orphaning if cross-compilation made that choice --
more than 90% of the targets, I'd bet. I'd rather configure for that
majority and provide a workaround for systems without sbrk.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: Idea: jobs(1) -i to print only :%ID:s

[Chet Ramey]

On 11/8/23 8:12 PM, Steffen Nurpmeso wrote:


The "problem" with the current way bash is doing it is that bash's
job handling does not recognize jobs die under the hood:

   $ jobs
   [1]-  Stopped LESS= less -RIFe README
   [2]+  Stopped LESS= less -RIFe TODO
   $ kill $(jobs -p)
   $

^ nothing

   $ jobs
   [1]-  Stopped LESS= less -RIFe README
   [2]+  Stopped LESS= less -RIFe TODO


Yes, the jobs are still stopped, and will remain stopped until they get
a SIGCONT. Do you think that kill, when given a pid argument, should look
up any job associated with that pid and send it a SIGCONT? Or should it
send a SIGCONT to the pid unconditionally? If so, what about other
processes in that job?

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/