On Wed, Jan 05, 2022 at 05:13:48AM +0700, Robert Elz wrote:
> Date:Tue, 4 Jan 2022 16:15:22 +0100
> From:=?utf-8?B?0L3QsNCx?=
> Message-ID: <20220104151522.xxuplfq76gj6e...@tarta.nabijaczleweli.xyz>
>
> | Because system(3) forks and waits, again.
> Is that really a s
Date:Tue, 4 Jan 2022 16:15:22 +0100
From:=?utf-8?B?0L3QsNCx?=
Message-ID: <20220104151522.xxuplfq76gj6e...@tarta.nabijaczleweli.xyz>
| Would "space out usage string for consistency" work as a message for
| you?
The commit message isn't the issue, and adding the
>> 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.
In general, I have on occasion run into cases where it is important to
know that sh -c is (or isn't) used. Consider
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 fo
Date:Mon, 3 Jan 2022 20:12:09 +0100
From:=?utf-8?B?0L3QsNCx?=
Message-ID:
| I tried to make these as small and atomic as possible;
The format is ok.
| script.c: fix usage string
That one isn't a fix, just a change. In man pages and other
similar places mean
Hi!
script(1) always exits 0 if it's successful. This can be worked around,
of course, but at least a flag enabling this is semi-ubiquitous among
other implementations (util-linux has -e, FreeBSD always passes the exit
status through and accepts a no-op -e, OpenBSD tried and failed to
implement th
