This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.


Charles Wilson wrote:
[...]
(2) it's an attempt to prevent users from permanently scrogging binary files. See: d2u, on a binary file, is an irreversible operation. So, if you do "d2u *" you'll probably kill something deep inside some binary file, and you can't fix it -- unless some minimal safeguards are in place.

u2d MAY be reversible -- IF there were no pre-exising \r\n combinations in the file to begin with -- so when (OMG-fixit-)d2u is run, obviously the first '\n' is preceeded by a (newly-added) '\r\n', so the prog merrily replaces ALL '\r\n' with '\n'...which MAY fix your oops, but maybe not.


So, with the current code, if you snarf the first "line" -- all chars until the first '\n' -- if it's a binary file the odds are pretty low that the immediately-preceeding character is a '\r' -- so d2u as currently coded will bail out, and no harm is done.


It doesn't work so well in the other direction -- by the same logic above, you'll almost never bail out early if you run 'u2d' on a binary file -- but if you immediately do a 'd2u' you MIGHT be able to recover.)

[...]

If detection of binary files is desirable, why not use an explicit test with a more robust methodology? GNU grep detects binary files by looking for a '\0' byte. Such a test could be used by both d2u and u2d; they could bail out with a message like "skipping binary file".

Cheers


-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]