This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: upload: diffstat-1.40-1, tar-1.15.1-1


> -----Original Message-----
> From: Dave Korn
> Sent: Wednesday, August 17, 2005 1:23 PM
> Subject: RE: upload: diffstat-1.40-1, tar-1.15.1-1
> 
> ----Original Message----
> >From: Christopher Faylor
> >Sent: 17 August 2005 18:20
> 
> > Let's apply some common sense here, too.  You specify "wt", 
> what would 
> > you expect?  You'd expect a file with CRLF endings, i.e., 
> LF should be 
> > translated to CRLF.
> 
>   Well, not on a linux box I wouldn't.
> 
>   If I open a file in textmode, I expect LF to be translated 
> to CRLF on systems that use CRLF as their native lineends.
> 
>   On a pure POSIX system, I would expect no translation and 
> LF endings.
> 

Then your expectations are wrong AFAIK.  There's no such thing as a "POSIX
text file" that I'm aware of.

>   On a pure 'doze system, I would expect translation and CRLF endings.
> 
>   Cygwin is meant to be emulating a POSIX system.  But it's 
> hosted on windows.  That's why we have different mount kinds: 
> they're a way of specifying what kind of native line-ends you 
> want cygwin to pretend to apps that the underlying system has.
> 

There's no such thing as "native line endings".  To wit: what is Linux's
"native graphics file format"?  Right, the question makes no sense.  Just
like saying an OS has a "native text file format" makes no sense.  When you
say "native line endings", you're saying "os-specific file format", which is
a beast that simply doesn't exist, and never has.

(I know, I know, insert a half-dozen counterexamples here, starting with the
IBM OSes from the Paleozoic Era that forced you to use EBCDIC)

>   So I would expect a file opened in binary mode to be 
> written absolutely verbatim, and I would expect a file 
> written in text mode to be written verbatim on a binary 
> mount, with POSIX-style LF endings, and I would expect a file 
> written in text mode on a textmode mound to be translated so 
> that LF was written to disk as CRLF.
> 
>   That is to say, I believe that "wt" indicates that \n 
> should be translated into system-native EOL, and that the 
> mountmode specifies what the system-native EOL should be 
> considered to be.  It's *binary* mode that is the 
> "programmer's-clearly-specified-intentions-override", and 
> textmode is the default, not a special postprocessing option.
> 
>   I think this entire discussion is coming from the wrong perspective!

It is, as almost all such discussions do, but the wrong perspective is that
the OS somehow should or does care what a text file looks like, and that
applications should blindly assume that all files are text files.  They
aren't.  Fprintf(), fscanf(), etc etc etc on a non-"{r,w}t"-opened file
should be punishable by death, as should fseek()ing around in a
"{r,w}t"-opened file.  And these things shall cease to happen amongst you.

-- 
Gary R. Van Sickle




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]