Re: Handling text files

Cosmin wrote:

> 1). The way that zip converts the text file endings (parameter "-l") is
> not so useful. The transformation is not idempotent, and it should be.
> I propose not to modify zip so that "zip -l" leaves CR LF intact,
> instead of transforming it to CR CR LF.

"not"?

> 2). If a text file contains the sequence CR CR LF, this is interpreted
> by "unzip -a" as two line endings. I think it's better to consider this
> as a single line ending.
> On the other hand, CR LF LF should still be interpreted as two line
> endings.

You're overlooking Mac OS.  It would be possible to add OS-of-origin
tests to the conversion (assuming the OS-made-by byte could be trusted,
which is highly questionable), but I'm not sure that's a good idea.

Ultimately it's up to the UnZip maintainer, however, and that position
appears to be up for grabs once again.  Interested? :-)

> 3). The way that zip distinguishes between binary vs. text files can
> never be 100% precise, and yet the current method (which AFAIK is
> inherited from PKZIP) guesses wrong many times. I propose to consider
> any file that contains any single non-printable control character, a
> binary file.

That's not a bad idea, although the current approach was chosen for
performance reasons.  However, insofar as most Zip-running machines are
ridiculously overpowered these days, and given that countless MSWord
docs and MSDLLs have been trashed via autoconversion, it's probably a
worthwhile tradeoff.  I certainly would appreciate better detection on
Zip's part.

Greg