Description of Problem:
If you give dos2unix a mac file (one where lines are separate by \r alone)
and accidentally ask it to convert in DOS mode, you get a file with no
To me this seems like confusing behavior. I'd prefer it if DOS conversion
mode changed `\r\n' to `\n' -- and left lone `\r's unmodified. That
would reduce the potential for error.
Version-Release number of selected component (if applicable):
dos2unix 3.1 (Thu Nov 19 1998)
Steps to Reproduce:
Created attachment 104332 [details]
Created attachment 104333 [details]
patch (with uneeded lines dropped)
My post to fedora-patch-list bounced, and when I looked at the message, I've
noticed lines in the patch which I should have deleted earlier.
The patch makes sense. I haven't been able to test it because I have
no mac files here, but the code looks sane.
Mike, want to rebuild the package or should I rebuild it ?
cat unixfile | tr \\n \\r > macfile
Created attachment 104335 [details]
While the unneeded lines in the first patch did no harm (a cut'n'rename
mistake), the second patch lost the line delimiter of the last line when
running mac2unix on a Mac file. A minor detail, easily overlooked when running
$ cd /tmp
$ cat /etc/services | tr \\n \\r > macfile
$ ls -la macfile
-rw------- 1 misc2 misc2 19936 Sep 26 21:05 macfile
$ dos2unix -c Mac macfile
dos2unix: converting file macfile to UNIX format ...
$ ls -la macfile
-rw------- 1 misc2 misc2 19936 Sep 26 21:06 macfile
$ cat macfile | tr \\r \\n > unixfile
$ md5sum unixfile /etc/services
[size and checksum stay the same]
Patch applied in dos2unix-3.1-19
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.