Re: ed and ^M: damages files unbeknownst to the user

[Dan Jacobson]

>>>>> "A" == Andrew L Moore <address@hidden> writes:

A> Does warning that a file contains non-printing
A> characters really buy anything?  

Yes, it is the warning that what I see might not be what I get.  Being
fairly warned, the [moral] responsibility for damaged files now shifts
to me instead of GNU.

A> Knowing this, you were still surprised by the result.

But am innocent as I did not know the file contained ^M's.  It happens
sometimes when you least expect it.

A>  If you are not sure of a file's format or type, then the `file'
A> command is appropriate.

For the rest of my life I should use the file command first before I
edit files?   Looked fine in more, less, cat, etc.  Edited fine in
emacs... then one day I use ed, and wreck the file.

A> A more charitable warning, perhaps, is `careful with those regular
A> expressions'.

I don't agree.  I think even Stallman would get tripped by this bug
one day.

Your solution requires us to know the format of each file before we
'ed' it.  OK, but be consistent and take the 'binary file' warnings
out of grep, diff, etc.

A> In message <address@hidden>, Dan Jacobson writes:
>>>>>>> "A" == Andrew L Moore <address@hidden> writes:
>> 
A> GNU ed is anti-Microsoft.
A> Try `l'isting the result.  It contains an embedded carriage return (\r).
>> 
>> I'd just like to point out that the user is totally innocent in this
>> case.  He did not leave his unix system to edit a Microsoft file, he
>> would have no warning that an occasional unix utility would produce
>> CR-LF files... so, we have a utility [gnu ed] that will scramble files
>> unbeknownst to the user: either giving him "what you see is not what
>> you get" or some other problem.
>> 
>> Even if he did edit a microsoft file, don't you agree that it might be
>> charitable to clue him in that something might be not as he expects?
>> 
>> That he should use the l command instead of the p command is not
>> something you should blame him with after he has already ruined his
>> file unbeknownst to him.
>> 
>> Solution: at least a warning could be output, or at least an "?":
>> ?
>> h
>> Binary file
>> 
>> which could include all cases where what you see is not what you
>> probably get.  I'd say that is the minumum needed... otherwise you've
>> got a utility that damages files unbeknownst to the user, which is a
>> serious bug.
>> 
A> # ed /var/spool/news/out.going/884-1005862565-1  
A> 658
A> 1
A> Newsgroups: tw.bbs.soc.media,tw.bbs.rec.tv
A> s/$/,soc.culture.taiwan/l
A> Newsgroups: tw.bbs.soc.media,tw.bbs.rec.tv\r,soc.culture.taiwan$
>> 
A> The result is correct with respect to the POSIX standard, I believe.
A> -AM
>> 
A> In message <address@hidden>, Dan Jacobson writes:
>>>> While using ed on a file formatted with ^M's at the end of each
>>>> line, the output could be quite disturbing:
>>>> 
>>>> # ed /var/spool/news/out.going/884-1005862565-1  
>>>> 658
>>>> 1
>>>> Newsgroups: tw.bbs.soc.media,tw.bbs.rec.tv
>>>> s/$/,soc.culture.taiwan 
>>>> ,soc.culture.taiwansoc.media,tw.bbs.rec.tv
>>>> u
>>>> p
>>>> Newsgroups: tw.bbs.soc.media,tw.bbs.rec.tv
>>>> s/$/xxx
>>>> xxxsgroups: tw.bbs.soc.media,tw.bbs.rec.tv
>>>> u
>>>> s/tv/tv,soc.culture.taiwan 
>>>> Newsgroups: tw.bbs.soc.media,tw.bbs.rec.tv,soc.culture.taiwan 
>>>> w
>>>> 678
>>>> q
>>>> 
>>>> One seems not to be able to keep track of what ed is thinking from
>>>> merely looking at the screen.
>>>> 
>>>> $ ed --version
>>>> GNU ed version 0.2
>> -- 
>> http://www.geocities.com/jidanni/ Tel+886-4-25854780
>> 

-- 
http://www.geocities.com/jidanni/ Tel+886-4-25854780