tech-userlevel archive

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

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

On Tue, Jan 04, 2022 at 09:16:30PM +0700, Robert Elz wrote:
>     Date:        Mon, 3 Jan 2022 20:12:09 +0100
>     From:        =?utf-8?B?0L3QsNCx?= <>
>     Message-ID:  <>
>   |   script.c: fix usage string
> That one isn't a fix, just a change.  In man pages and other
> similar places meaning for words in exampkes (distinguishing
> literal data from pkaceholders for example) can be done by
> various markup/formatting techniques.  Usage messages do not
> have that possibility, just text.  Some applications use the
> <word> nitation to indicate that "word" is not literal text,
> but to be replaced by the user.  Others do not, keaving it to
> either the written explanation, or just the common knowledge
> of the reader to work out what should be entered as shown,
> and what shoukd be replaced by the user's data.  Neither is
> correct, it is just a matter if choice.
Yes, with this I don't disagree, but having no space between the []s
in "[-c <command>][-adfpqr]" is, I'd say, a bug.
At the very least, it's inconsistent with the rest
of the usage strings (implying "script -c ls-a" is in some way valid)
and adheres to XBD 12.1 syntax, which is slightly out-of-place here.

(Also, most others I've tried don't surround option-arguments with <>s,
 and neither does XBD.
 Yes, this is less of a problem, but still, consistency.)

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

>   |   script.c: use sh -c directly instead of system(3)
> I'm nkt sure why that would matter, but if it is going
> to change tgat way it shoukd use "sh -c -- command" so
> commands tgat haopen to start with - or + are nit treated
> as options by the shell (posix is going to require this
> of system() and popen() - generally it is better to just
> use those interfaces so enhancements to them simply
> flow through to the applications.
Because system(3) forks and waits, again. This both wastes a process
and falls down to fail() in all cases, SIGTERMing the whole pgroup
(as opposed to the no--c path which simply execs).

Also, system(3) is also susceptible to this, so I'm not sure what you
mean here (try it! run "script -c-l"!). system(3) just sucks.

I've added the "--"s, and will include them in v2.

>   |   script.1: clarify that -c runs the argument via sh -c
> Even if #2 was done, this is too much detail.  Users care what
> happens, not the nechanism by which it is made to work.
Disagree, sh -c arg is /what/ is being done. This is fundamentally
different from if script -c /actually/ took a command, like FreeBSD
script does. As it stands, and, for compatibility, presumably as it will
stand, script takes a shell program, not a command, and
  script -c 'for i in 0 1 2 3 4 5 6; do echo $i; done; exec ls'
is valid. Admittedly, saying "-c script" or "-c shell-program" /would/
be too much, but as it stands, it's still important to note this,
because the string is subject to shell expansion.


Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index