Chapter 3. Using Cygwin
On a UNIX system, when an application reads from a file it gets exactly what’s in the file on disk and the converse is true for writing. The situation is different in the
DOS/Windows world where a file can be opened in one of two modes, binary or text. In the binary mode the system behaves exactly as in UNIX. However in text mode there are major differences: a. On writing in text mode, a NL (\n, ^J) is transformed into the sequence CR (\r, ^M)
NL.
b. On reading in text mode, a CR followed by an NL is deleted and a ^Z character signals the end of file.
This can wreak havoc with the seek/fseek calls since the number of bytes actually in the file may differ from that seen by the application.
The mode can be specified explicitly as explained in the Programming section below.
In an ideal DOS/Windows world, all programs using lines as records (such as bash,
make, sed ...) would open files (and change the mode of their standard input and output) as text. All other programs (such as cat, cmp, tr ...) would use binary mode. In practice with Cygwin, programs that deal explicitly with object files specify binary mode (this is the case of od, which is helpful to diagnose CR problems). Most other programs (such as cat, cmp, tr) use the default mode.
3.2.2. The default Cygwin behavior
The Cygwin system gives us some flexibility in deciding how files are to be opened when the mode is not specified explicitly. The rules are evolving, this section gives the design goals.
a. If the file appears to reside on a file system that is mounted (i.e. if its pathname starts with a directory displayed by mount), then the default is specified by the mount flag. If the file is a symbolic link, the mode of the target file system applies.
b. If the file appears to reside on a file system that is not mounted (as can happen when the path contains a drive letter), the default is text.
40
