Mail Archives: cygwin/1998/10/21/23:51:51
---=?iso-8859-1?Q?Bj=F8rn_Hell_Larsen?= <blarsen AT intervett DOT no> wrote:
>
>
> Earnie writes:
> > It is rather easy for the porter to fix with 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.
>
> The problem with this, again, it that creating strict divisions
> between "text" and "binary" files, and "text" and "binary" tools
> at times doesn't make much sense.
>
> For instance, in the GNU-Win32 distribution, the tools "cat" and
"grep"
> are classified as "text tools", allowing them to handle MS files
> with CRLF line separation and CTRL-Z end-of-file markers correctly.
>
> Unfortunately, this also means that I won't be able to use the
> tools the way I'm used to from my Unix days, i.e.
>
> cat part* | tar tzvf -
>
> fails miserably, and
>
> MATCHES=`grep -c pattern binaryfile`
>
> won't do what I expected it to do.
>
> I would much prefer a single global setting that I could toggle,
> that would make all tools work in complete binary mode, under
> the assumption that I *know* about the MS/Unix file format
> differences, and would prefer to be left to deal with them
> myself.
>
>
>
> Bjorn
>
>
Bjorn, you've just given proof that some of the utilities that come
with the CDK aren't completely compliant/ported yet either. I just
added at line 646 of textutils-1.22/src/cat.c:
#ifdef __CYGWIN32__
setmode( input_desc, O_BINARY );
setmode( output_desc, O_BINARY );
#endif
and the result is exactly as _I_ would expect it to be. The results
were also the same regardless of the cygwin mounted filesystem binary
mode switch.
If CYGWIN32=tty and the file contains \n line endings then a \r is
added before being displayed. I.E.:
// This line ends here ->
// This is the next line.
If CYGWIN32=notty or is not set and the file contains \n line endings
then the file is displayed with no \r ever happening. I.E.:
// This line ends here ->
// This is the next line.
If the file contains \r\n line endings then the file is displayed
exactly the same way regardless of the tty setting. I.E.:
// This line ends here ->
// This is the next line.
The UNIX filesystem treats all files as binary files and the /dev/tty
adds the \r to the output display for the \n it receives or has it as
an option. The MSDOS/WIN32 filesystem has two methods/modes of file
processing known as text or binary and the output display doesn't add
a \r for the \n.
Now we have to give thought to how to handle the differences. In my
modification to cat.c I chose to treat everything as binary since that
is the way it would have been working in UNIX. The result is correct
for text!=binary as well as text=binary eliminating the dependency on
this switch/parameter.
Let me apologize to you and the list for fanning flames. But, I
intend to sing this song until there is no need to sing it again. As
can be seen from the support for this position this is a much needed
concept. The only problem with it is understanding when it should be
text and when it should be binary. I tend to set file descriptors to
binary processing mode unless I'm absolutely positive it is supposed
to be treated as text (e.g.: a shell script file).
==
- \\||//
-------------o0O0--Earnie--0O0o--------------
-- earnie_boyd AT yahoo DOT com --
-- http://www.freeyellow.com/members5/gw32 --
----------------ooo0O--O0ooo-----------------
PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -