[Top][All Lists]

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

Re: potential inconsistency with buffer modified flag

From: Antonio Diaz Diaz
Subject: Re: potential inconsistency with buffer modified flag
Date: Tue, 14 Nov 2023 18:13:22 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv: Gecko/20110420 SeaMonkey/2.0.14

Eric Blake wrote:
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).

Given that the buffer change flag is already set when an 'e' or 'q' command fails, it is not possible for an intervening command to set it, nor is it easy for ed to tell whether an intervening command would have set it. For example, 'a\n.\n' does not set the buffer change flag, but should make e or q repeat the warning.

Therefore I have proposed a change from:

"If another e or q command is then attempted with no intervening command that sets the buffer change flag, it shall take effect."

to something like:

"If another e or q command is then attempted with no intervening command that can set the buffer change flag, it shall take effect."

I have just added a note at https://austingroupbugs.net/view.php?id=1786#c6570 proposing the above change of wording to ease implementation of this feature. BTW, I have already implemented it in GNU ed and will make a test release in a few days.

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.

It would be useful if Etherpad were able to automaticaly create a text (plain, html, or pdf) rendering of the final page. But as you say, in this case it is no longer necessary.

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).

Thank you. I think all the changes in bug 1786 are good, except the change I proposed above about repeated e or q commands.

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.

I don't think we have to worry about POSIXLY_CORRECT if what dalias says at https://austingroupbugs.net/view.php?id=251#c1725 is correct:

"As it stands, implementations are free to reject any characters they like outside the portable character set. This allows a "hardened" implementation to reject newline and even to advertise this rejection as an additional hardening feature."

BTW, I have already implemented '--unsafe-names' in GNU ed.

BTW2, while implementing '--unsafe-names' I have discovered that GNU ed prints file names directly to stdout/stderr, potentially causing trouble if they contain control characters. I'm now investigating what is the best way for ed to print unsafe names in a safe way.

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)

Understood. Thank you very much for your work on POSIX. Please, let me know if I can help in any way.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]