Re: potential inconsistency with buffer modified flag

[Eric Blake]

On Sat, Nov 11, 2023 at 05:38:59PM +0100, Antonio Diaz Diaz wrote:
> Eric Blake wrote:
> > Some other things we noted today: GNU ed treats 'r /dev/null' (or any
> > other 0-byte file) as a command that does not modify the buffer
> > changed status.  Conversely, ed on MacOS treats the buffer as modified
> > even when zero bytes are read.  On that front, the POSIX folks were
> > okay with both behaviors, and wanted to change the wording to permit
> > both.  But it got more questionable with other commands: POSIX is
> > already clear that 's/a/a/' can update the current line (even though
> > it doesn't update contents), so it seems reasonable to have it always
> > mark the buffer as modified.  And even if you use 'c' to replace a
> > line with the same contents, the act of deletion and re-addition seems
> > like a reason to set the flag.
> 
> IIRC, GNU ed sets the modified flag when it changes the buffer, even if the
> buffer contents are identical before and ater the change. For example,
> 's/a/a/' sets the modified flag.
> 
> In this sense, appending an empty or non-existent file does not change the
> buffer, and therefore does not set the modified flag. This is much like any
> other "empty" command that does not change the buffer, in which case the
> modified flag is not set:
> 
> $ ed -v ; echo $?
> a
> .
> q
> 0

The example of the empty 'a' (and corollary empty 'i') were new to
today's Austin Group discussion, but it looks like BSD implementations
are consistent with GNU ed on that front (change flag is not set if
there is no text before the closing '.').

> 
> > It's harder to argue whether '=' modifies the buffer, and even harder for
> > things like 'H' or 'P'; but we were leaning towards any command that
> > prevents the sequence 'e',$cmd,'q' from exiting as being required to set
> > the buffer modified flag even if it did not change the buffer contents
> > (which was how we noticed the inconsistency between GNU and MacOS when
> > $cmd is 'h').
> 
> Maybe all the commands that can't change the buffer contents, namely f, h,
> H, k, l, n, p, P, #, =, and the null command, could be allowed in between a
> notification that a buffer was modified and a followup attempt to quit. I'm
> willing to implement such a change.

Existing practice seems to be that 'e\nh\nq\n' seemed to be the only
sequence where FreeBSD ed allowed the quit but GNU ed did not; but
today's wording tried to allow any such command (your list was helpful
during that discussion).

> 
> > You can see where we left off today;
> > https://posix.rhansen.org/p/2023-11-09 (start around line 275 in that
> > document).
> 
> I get:
> "You do not have permission to access this pad"
> "Sorry, you have to enable Javascript in order to use this."
> 
> Is there a text/plain or text/html version of that etherpad that can be read
> without creating yet another account and without executing javascript?

Not directly; although I did bring that up in today's meeting.
Etherpad (https://etherpad.org/) claims it uses open source - but as
you mention, the clincher is whether the javascript properly
advertises its provenance in a way that works with freedom-enforcing
browsers; it may also be a question of whether the particular instance
of Etherpad hosting the Austin Group meeting notes lags behind
upstream.  At any rate, if needed, I think I can use Etherpad's
ability to create a pdf rendering of the final page.

But for today's meeting, even that may not be necessary; the Austin
Group finished up the loose ends from last week, so now we DO have
proposed text in https://austingroupbugs.net/view.php?id=1786#c6567
which should be usable without Javascript, and less messy than trying
to decipher live meeting notes from Etherpad.

Let us know if you have any feedback or suggestions as to what got
placed in that bug; the Austin Group agreed that we still have a bit
of time to revise the wording if we have short-term input from any of
the 'ed' developers (GNU ed or otherwise).

> 
> > When our text tweaks are finally ready (possibly next Monday), we'll add
> > it to https://austingroupbugs.net/view.php?id=1786 and start a 30-day
> > review, but since you'll possibly be impacted by the change (whether to
> > change GNU ed to match, or to offer a counterpoint why the Austin Group
> > proposed changes are too onerous and failed to take into consideration
> > existing practice), feel free to chime in now rather than waiting.
> 
> I don't think that any of the changes being proposed is too onerous. In fact
> I plan to implement even the resolution of bug 251 (and more) and make GNU
> ed reject characters 0 to 31 in file names unless they are allowed with a
> command-line option. (Perhaps '--unsafe-names').

The current resolution of bug 251 only recommends (not requires) that
'ed' warn about attempts to create a filename containing newline; it
did not place any restrictions on other control characters in file
names.  Still, I agree that warning about other control characters may
be worthwhile, even if you now start having to worry about whether
POSIXLY_CORRECT affects things in addition to any command line
argument changes.

> 
> BTW, re bug 1786, I don't follow the logic of implementations like FreeBSD
> 13 to not allow the creation of a file in the obvious way of supplying the
> file name in the command line. I find it convenient that GNU ed allows it:
> 
> $ ed -v zutils.conf
> zutils.conf: No such file or directory
> a
> gz = pigz -p2
> lz = plzip -n2
> .
> wq
> 29
> $ cat zutils.conf
> gz = pigz -p2
> lz = plzip -n2
> $
> 
> Maybe POSIX should recommend for the 'e' command with a non-existing file
> that "a warning is emitted in place of a byte count and the resulting buffer
> is left empty".

The best we could do for bug 1786 was leave it unspecified (so as not
to break FreeBSD's behavior) - we are too late into the Issue 8 draft
process to be adding new requirements.  But I agree that for Issue 9,
it would be nice to encourage the saner behavior - possible if FreeBSD
ed authors agree to the change (I'm less certain any BSD developers
read this list for inspiration, and GNU ed already does what we want -
so there's not much more we can do about it in this venue)

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org