Subject: RE: mount type, compiler barf, and sym links
From: [email-masked] (Earnie Boyd)

21 Oct 1998 23:51:51 -0700
Message-ID: <[email-masked]>
Reply-To: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: "Bjørn_Hell_Larsen" <[email-masked]>, [email-masked]

---=?iso-8859-1?Q?Bj=F8rn_Hell_Larsen?= <[email-masked]> 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--------------
--          [email-masked]          --
-- 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
"[email-masked]" with one line of text: "help".