CRLF again, was: Re[2]: smtp mail failed

[john_r_velman@mail.hac.com]

In my opinion, all archiving and zipping programs (tar, zip, unzip, etc) should 
*never* add CRs where they don't exist in the source file.  Likewise, *all* 
filters (tr, cat, pipes...) should *only* add CRs if instructed to do so on the 
options line.  Then if someone want's to use a text file from a non windows 
source in a windows program that needs the CRLF combination (like this ccmail) 
they can run the file through a Unix to Dos filter.   

This CRLF business has been the most difficult thing about using the cyg-win 
gnu-win tools.  The NT emacs I'm using seems to have some algorithm in it that 
decides what to do.  It doesn't always do the right thing.  The Vim I have is 
honest about it.  Unless you tell it specifically something like :se ff=dos, it 
just seems to keep things like they were.

Well, cyg-win32, gnu-win32 is still a great suite of software, but with a few 
growing pains.

Best to all,

John Velman
jrvelman@mail.hac.com
______________________________ Reply Separator _________________________________
Subject: Re: smtp mail failed
Author:  marcus@bighorn.dr.lucent.com at mime
Date:    10/14/98 9:17 AM


> As I've stated on my web pages under my Personal Reflections on this 
> subject, IF YOU DEPEND ON THE BINARY MODE MOUNT SETTING THEN YOU ARE 
> MASKING A PROBLEM WHICH WILL EVENTUALLY BYTE YOU SOMEWHERE ELSE.
> Consider yourself bytten.
>
> I suggest that you get the source code and find all of the open/fopen 
> statements and properly add the necessary file mode processing
> switches.  The only truly way to get rid of this for good is to 
> properly port the code and be specific about what mode your file 
> should be processing in.
>
> PORTERS OF SOFTWARE, please, don't depend on the binary mode mount
> setting!!  Make the appropriate changes to the open/fopen statements.
     
While I agree 100% with this view, there are some difficulties that are 
particularly apparent with archive software.  If tar is unpacking a file, 
(or packing it, for that matter) is it a binary file or a text file? 
Somehow, tar/zip/whatever must find out whether to open the file in text 
or binary mode, yet there seems to be no definitive way to tell which.
Do you try to see if the file has all characters < 0x100 and line breaks 
every so often to call it a text file?  What about various meta-character 
escapes (for extended character sets, bold/italic/underline, etc.).  What 
if an executable file actually does contain '\n' every so often.  These 
heuristics are bound to make mistakes, but what better way is there to 
tell?
     
marcus hall
-
For help on using this list (especially unsubscribing), send a message to 
"gnu-win32-request@cygnus.com" with one line of text: "help".