Re: [Bug-ed] Reading something into an empty file should set "changed" flag

[Moore Andrew L.]

Martin Guy writes:
...
>> $ ed foo
>> 0
>> r bar
>> 5
>> q
>> $
>> 
>> since the default file is still "foo", and the buffer now has
>> different contents from the disk file, this should probably refuse to
>> quit.
...

That's reasonable but not historical behavior.  `Read'  differs from
from, say, `append' in this respect.  The intent is to equate opening
a file via `edit' or from the command line and opening it by reading
into an empty buffer, i.e.:

    $ ed bar
    5
    q
    $

and

    $ ed
    r bar
    5
    q
    $

should both work the same.  If you agree, then consider the case:

    $ ed
    f foo
    foo
    r bar
    5
    q
    $

This is like the second example, but also the equivalent of your own.
Your patch would break with historical practice.  I chose to resolve
the issue in a different way.

John Cowan writes:
...
> Reading in a file certainly counts as a change in the buffer, so a
> q command in that circumstance should be rejected.  I suppose a
> case could be made that if the read-in file is empty, the modified
> flag should not be set, but I think that would be more confusing.
...

Reading a file counts as a change in the buffer if it changes the buffer.
That is the historical precedent, and that is the intent.

Having said that, here is how I addressed the issue per the unreleased ed's
ChangeLog:

2006-11-17  Andrew L. Moore  <address@hidden>

        ...

        Reading a sequence of files is similar to concatenation, except
        that missing newlines are appended. Reading an empty file, on the
        other hand, should not append a newline unless the buffer is
        empty. In this event, the buffer is still (logically) empty since
        concatenating an empty file and any other file yields the other
        file. For instance, if file `o1.tmp' is empty (i.e., size of
        0 (zero) bytes) and file `o2.tmp' has size 6, then the Unix command:

            $ cat o1.tmp o2.tmp >o3.tmp

        produces a file `o3.tmp' of size 6 also. Likewise, the sequence of
        commands on the same files within ed:

            $ ed -p '*'
            *r o1.tmp
            Newline appended
            1
            *r o2.tmp
            6
            *w o3.tmp
            6

        again produces a file `o3.tmp' which has size 6, even though ed
        reported appending a newline upon reading the file `o1.tmp'.


But it's not enough to just append a phantom newline to an empty file.
It still has to be treated specially.  Writing it, for instance, should
not write the newline.  But neither should printing it generate an error.
The result is that empty files "behave" as one would expect.  This is
consistent with the thrust of SUSv3, and yet still preserves the historical
behavior.
-AM