On Mon, 3 Feb 2025, Andrew L. Moore wrote:
On 1/30/25 12:34:21, Antonio Diaz wrote:
| Since 2006[1] GNU ed provides the option '-l, --loose-exit-status'[2] to
| prevent some errors from affecting the exit status of an interactive
| session. (It was suggested by Karl Berry IIRC):
Antonio,
When ed was handed to you, it already reset the exit status on
successful write, sigh. Replacing that behavior with a command-line
option is useless if ed is invoked by another process, as is the case
when EDITOR=ed. And setting EDITOR='ed -l' breaks when ed doesn't
recognize option `-l'. Leave Karl out of it. He's smarter than that.
I think this was a recurring theme on this mailing list over the years.
Let's simplify the code - there is no need to collect errors along the way,
just to set the exit code at the end.
What about ed 2.0 without "-l" option, returning exit code >0 only if
it really stops on error?
Regarding POSIX, I believe it is important that both EXIT STATUS and
CONSEQUENCES
OF ERRORS sections of standard should be read together (here 2017 wording):
EXIT STATUS
The following exit values shall be returned:
0
Successful completion without any file or command errors.
>0
An error occurred.
CONSEQUENCES OF ERRORS
When an error in the input script is encountered, or when an error
is detected that is a consequence of the data (not) present in the
file or due to an external condition such as a read or write error:
If the standard input is a terminal device file, all input shall
be flushed, and a new command read.
If the standard input is a regular file, ed shall terminate with
a non-zero exit status.
The newer versions replace the last sequence with a reference to
the generic error handling description.
Maybe "any" file or command errors is unlucky, but to me it is clear
that when reading from a terminal device file, there is no need
to exit and set the exit code, just flush and continue.
Marcin
