Re: Handling text files

Cosmin T wrote:
> 
> Greg wrote:

...

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

There may be users that depend on the LF to CR LF conversion just adding
CR before each LF.  Changing zip -l would likely lead to incompatibility
problems for some users and catch them by surprise.  Maybe a new option
like -lc might convert LF CR LF to CR LF CR LF.  Changing defined
options to act differently is I think generally a bad idea.

...

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

The above does sound reasonable, but there are a couple cases that might
cause trouble.  Corrupted text files for one, where random characters
get inserted by accident.  A single corrupted line could force binary
using the above.  Another is special characters used as printable by one
platform character set that are not printable on another.  This should
consider other languages.  I guess could assume text is pure ASCII 7-bit
character set text as filtered above, but having no tolerance for port
variations or noise seems a little extreme.

Regards,
Ed Gordon