On Fri, Nov 10, 2023 at 12:08:12AM +0100, Antonio Diaz Diaz wrote: > Eric Blake wrote: > > During today's Austin Group meeting (the folks working on POSIX), we > > noticed an inconsistency in GNU ed when compared to other > > implementations. It seems that ALL implementations we tested allow > > 'q' to quit immediately after an 'e' that failed because the buffer > > still has unwritten modifications: > > [...] > > We then tried to figure out what other commands, if any, can be used > > in between notification that a buffer was modified and a followup > > attempt to quit. On MacOS, 'h' does not count as an intervening > > command: > > Thank you very much for reporting this. I'll implement both behaviors in GNU > ed as soon as possible (in a few days).
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. 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'). You can see where we left off today; https://posix.rhansen.org/p/2023-11-09 (start around line 275 in that document). The notes in that etherpad are still in rough shape because we are still considering if other wording tweaks are needed (we already know we need to fix the sentence in draft 3 line 92845 about "If the e or q command is repeated with no intervening command, it shall take effect." to cover the fact that 'q' immediately after a failed 'e' did quit in all tested implementations). 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. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org