From: earnie_boyd AT yahoo DOT com (Earnie Boyd) Subject: RE: mount type, compiler barf, and sym links 21 Oct 1998 23:51:51 -0700 Message-ID: <19981021133519.10626.rocketmail.cygnus.gnu-win32@send1e.yahoomail.com> Reply-To: earnie_boyd AT yahoo DOT com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: "Bjørn_Hell_Larsen" , gnu-win32 AT cygnus DOT com ---=?iso-8859-1?Q?Bj=F8rn_Hell_Larsen?= 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".