Re: potential inconsistency with buffer modified flag

[Antonio Diaz Diaz]

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,
Antonio.