Re: Handling text files

I demand that Greg Roelofs may or may not have written...

> Cosmin wrote:
[snip]
>> 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.

And RISC OS. Depending on how a text file is generated and, to some extent,
the versions of things such as the shared C library modules, it may contain
LF, CRLF and/or LFCR line endings...

Also, is this only considering the 8-bit encodings?

> 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, [...]

*Definitely* not all (say I, using a 40MHz ARM710)...

(BTW, I'm not seeing any threading here other than on subject. Would you two
mind including at least an In-Reply-To header?)

-- 
| Darren Salt    | d youmustbejoking.demon.co.uk | nr. Ashington,
| Running Debian | s zap.tartarus.org            | Northumberland
| and RISC OS    | @                             | Toon Army
|   <URL:http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)

M$: "You will use Windows. Resistance is futile."