Re: [PATCH 0/6] script(1) cleanups, -e to pass through exit code

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 4 Jan 2022 16:15:22 +0100
    From:        =?utf-8?B?0L3QsNCx?= <nabijaczleweli%nabijaczleweli.xyz@localhost>
    Message-ID:  <20220104151522.xxuplfq76gj6ewco%tarta.nabijaczleweli.xyz@localhost>


  | Would "space out usage string for consistency" work as a message for
  | you?

The commit message isn't the issue, and adding the spaces isn't a problem,
I'm just not sure I'd delete the <> (nor would I necessarily add them
if I were writing that - I have been known to where it seems to help,
and not to, when it doesn't).

  | Because system(3) forks and waits, again.

Is that really a serious problem in script?

  | Also, system(3) is also susceptible to this,

It currently is, but that will be fixed, and when that happens,
all applications which use it will be fixed without touching them.
Those which open code sh -c instead of just using system() won't.
(The alternative considered by posix was to tell all applications
to insert a space at the head of the command string, if there was
any possibility of it beginning with a '-'; ie: generally, when it
comes from user input of one kind or another.  Having everyone modify
system() seemed like a better choice).

    | system(3) just sucks.

It does for this, but that will get fixed.

  | As it stands, and, for compatibility, presumably as it will
  | stand, script takes a shell program, not a command, and

In the shell, what you are calling a program is kind of a command
(not quite, it is more a list).  Certainly things like for ...
and { ... } are commands.

  | it's still important to note this,
  | because the string is subject to shell expansion.

Sure, it could say "is run by /bin/sh", but there's no need to
have people race off to the sh manual to find out what -c means,
if they don't already know.

kre

ps: I think the above addresses the comments Mouse made as well.