On Sep 13, 2012, at 10:35 AM, Jeff Morriss <jeff.morriss...@gmail.com> wrote:
> Gisle Vanem wrote:
>> The files in tools/tpg seems to have DOS/Win line-endings (CR-LF). This
>> doesn't work well with the Cygwin compiled perl I have here. Could you pass
>> them through dos2unix before adding to svn?
>
> Those files all have svn:eol-style set to 'native' (like most of the rest of
> Wireshark) which means they should have, well, native line endings. I forget
> exactly what that means in the Cygwin world though...
The problem is that "in the Cygwin world", you're running Windows, and, in
Windows, native line endings are CR-LF, but:
http://cygwin.com/faq-nochunks.html#faq.api.cr-lf
"5.3. How is the DOS/Unix CR/LF thing handled?
Let's start with some background.
On POSIX systems, a file is a file and what the file contains is whatever the
program/programmer/user told it to put into it. In Windows, a file is also a
file and what the file contains depends not only on the program/programmer/user
but also the file processing mode.
When processing in text mode, certain values of data are treated specially. A
\n (new line, NL) written to the file will prepend a \r (carriage return, CR)
so that if you `printf("Hello\n") you in fact get "Hello\r\n". Upon reading
this combination, the \r is removed and the number of bytes returned by the
read is 1 less than was actually read. This tends to confuse programs dependent
on ftell() and fseek(). A Ctrl-Z encountered while reading a file sets the End
Of File flags even though it truly isn't the end of file.
One of Cygwin's goals is to make it possible to mix Cygwin-ported POSIX
programs with generic Windows programs. As a result, Cygwin allows to open
files in text mode. In the accompanying tools, tools that deal with binaries
(e.g. objdump) operate in POSIX binary mode and many (but not all) tools that
deal with text files (e.g. bash) operate in text mode. There are also some text
tools which operate in a mixed mode. They read files always in text mode, but
write files in binary mode, or they write in the mode (text or binary) which is
specified by the underlying mount point. For a description of mount points, see
the Cygwin User's Guide.
Actually there's no really good reason to do text mode processing since it only
slows down reading and writing files. Additionally many Windows applications
can deal with POSIX \n line endings just fine (unfortunate exception: Notepad).
So we suggest to use binary mode as much as possible and only convert files
from or to DOS text mode using tools specifically created to do that job, for
instance, d2u and u2d from the cygutils package.
It is rather easy for the porter of a Unix package to fix the source code by
supplying the appropriate file processing mode switches to the open/fopen
functions. Treat all text files as text and treat all binary files as binary.
To be specific, you can select binary mode by adding O_BINARY to the second
argument of an open call, or "b" to second argument of an fopen call. You can
also call setmode (fd, O_BINARY). To select text mode add O_TEXT to the second
argument of an open call, or "t" to second argument of an fopen call, or just
call setmode (fd, O_TEXT).
You can also avoid to change the source code at all by linking an additional
object file to your executable. Cygwin provides various object files in the
/usr/lib directory which, when linked to an executable, changes the default
open modes of any file opened within the executed process itself. The files are
binmode.o - Open all files in binary mode.
textmode.o - Open all files in text mode.
textreadmode.o - Open all files opened for reading in text mode.
automode.o - Open all files opened for reading in text mode,
all files opened for writing in binary mode.
Note
Linking against these object files does not change the open mode of files
propagated to a process by its parent process, for instance, if the process is
part of a shell pipe expression.
Note that of the above flags only the "b" fopen flags are defined by ANSI. They
exist under most flavors of Unix. However, using O_BINARY, O_TEXT, or the "t"
flag is non-portable."
so a given Cygwin ported-from-UNIX program might or might not handle CR-LF line
endings.
I'm not sure what the right fix for this is. Googling for
cygwin perl script line endings
found a bunch of stuff about problems with Perl scripts processing text files,
and some stuff about problems with *bash* handling shell scripts with CR-LF
line endings, but nothing specifically about Perl.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
