New bug found (I think)

[Bill Davidsen]

Patrick O'Callaghan wrote:
> On Sat, 2008-04-12 at 16:10 -0500, Aaron Konstam wrote:
>> On Sat, 2008-04-12 at 12:21 -0700, Les wrote:
>>> I use lots of things across systems, and have used the command:
>>>
>>> 	dos2unix <xxx.txt >temp.txt
>>>
>>> for years to accomplish this task.  Well, imagine my surprise when it
>>> failed to work today.  I don't know when dos2unix was last visited, but
>>> it no longer works.  Its simple effect on Microsoft files was to change
>>> the carriage return (^M) to linefeed (^j).  This time it passed the file
>>> through unchanged.  
>>>
>>> I can write my own version in about 2 seconds, but I am curious why such
>>> a simple and useful function acquired numerous flags and options, and
>>> then broke.  This is a great example of "if it ain't broke, don't fix
>>> it!"
>>>
>>> Just for your information:
>>>
>>> [lesh at localhost ~]$ ls -al /usr/bin/dos2unix
>>> -rwxr-xr-x 1 root root 15868 2007-02-06 08:45 /usr/bin/dos2unix
>>> [lesh at localhost ~]$ which dos2unix
>>> /usr/bin/dos2unix
>>> [lesh at localhost ~]$ 
>>>
>>> 	I have to admit I probably haven't used it locally since upgrading to
>>> FC7 from FC5.
>>>
>>> Regards,
>>> Les H
>>>
>> This can be done in vi very easily by the collowing command:
>> :1,$s/^V^M//
>> Where ^=ctrl
> 
> No need for vi:
> 
> tr -d "\015" < in > out
> 
> Of course both of these only work for ASCII. If it's Unicode, all bets
> are off.
> 
I wrote my own, just deleting CR isn't quite right, just want to delete 
CR only when followed by LF. Think ASCII graphic output, where CR is 
used to get overstrike on hardcopy, and LF in the middle of a line (see 
below).

output
       <-LF there to avoid spacing over.


-- 
Bill Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot