Re: Handling text files

Greg wrote:

> > I propose not to modify zip so that "zip -l" leaves CR LF intact,
> > instead of transforming it to CR CR LF.
>
>"not"?

Sorry, I missed that at proofreading :)
I propose TO modify zip so that "zip -l" leaves CR LF intact.

> > 2). If a text file contains the sequence CR CR LF, this is interpreted
> > by "unzip -a" 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.

MacOS up to v9 uses exclusively CR, doesn't it? Files that contain
"text\r\r\ntext\r\r\ntext\r\r\n" are unlikely to come from MacOS.

My proposal is to interpret CR .. CR LF (broken DOS/Win) as one line,
but CR .. CR (Mac) as many lines. I don't know what happens if you load
a file like this into a Mac editor, but if you load it into a Windows
editor, it shows one line. I mean, a decent editor. Notepad is anything
but decent, and it shows silly characters.

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

Thanks for the offer, I really appreciate it!

There are the problems that you are all so familiar with [sigh].
I am very busy (so are you), and I can consecrate only a tiny amount
of time on it (so can you). So these statements are not real complaints.

There are a couple of problems having me maintaining unzip, however.
I don't always answer emails right away, and I only have Windows,
Cygwin and Linux available for testing. Furthermore, I have little
sympathy towards the compilers that don't know about ANSI C,
I personally value code reuse above a self-contained compilable bundle
(e.g. I would prefer integrating zlib into the Info-ZIP code), and
I prefer code readability against less-than-necessary portability
(specifically: I would prefer that the user upgrades his or her compiler
to something much better, if that's available and affordable [gcc],
instead of crippling my code beyond reconnaissance).

I realize that Info-ZIP has other goals, and I will have to adhere to
them. Maybe I won't like doing it, or you won't like me doing it, or
both.

> > 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.

My proposed method does not incur any performance penalty.
In set_file_type() from trees.c, you set the file type as follows:
  set file type to ASCII
  for n in { 0, 1, ..., 8, 14, ... 31 } do
    if dyn_tree[n].Freq != 0 then
      set file type to BINARY
    end if
  end for

>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.

'\0' appears early in MSOffice documents, and also in compiled
executables on all platforms I know about, so yes, this scheme should
work.

Best regards,
Cosmin

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.  
http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca