Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <19991012142837.13612.rocketmail@web106.yahoomail.com>
Date: Tue, 12 Oct 1999 07:28:37 -0700 (PDT)
From: Earnie Boyd <earnie_boyd AT yahoo DOT com>
Reply-To: earnie_boyd AT yahoo DOT com
Subject: RE: make, bash, or cygwin bug?
To: Bernard Dautrevaux <DAUTREVAUX AT microprocess DOT com>,
        "'Kai Henningsen'" <kai AT cats DOT ms>, cygwin AT sourceware DOT cygnus DOT com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Bernard Dautrevaux <DAUTREVAUX AT microprocess DOT com> wrote:
> > Typically, these places already have some way to handle '\n' so as 
> > to make it work as white space. Under cygwin, this should 
> > probably be extended to '\r'. (This way may well be that later 
> > parsing routines handle '\n' like white space, not the place that 
> > takes the output from a program. OTOH, I can see no reason why 
> > parsing text should ever need to handle '\r' as something different 
> > from white space, so doing this change should not result in 
> > problems.)
> > 
> 
> Right. 
> 
> I've implemented this in my own programs: the pipes are by default opened
> binary-mode on the write side and text-mode on the read side, then a program
> that needs to read binary data open its read side explicitely binary-mode.
> This way we get rid of the superfluous \r in all programs that are not
> prepared to cope with binary data; and if I read this way pure binary data
> in such a program, I miss the \r's but anyway I will not understand what I
> read, so there is no harm :-(. 
> 

The problem with this is, if a ^Z|C-z|Ctrl-Z is read then a superfluous
END-OF-FILE is indicated. :-(

> Always opening the write side binary-mode will further simplify the problem:
> even someone forgot to open the read side text-mode, if I write text, he
> gets properly parsed text lines :-)
> 
> I remember this subject already was debated on the list some months ago, but
> obviously with no satisfactory solution, as the problem is still there :-(
> 

There is not an "easy" solution to different OSes ending lines in different
fashions.  The real fix is to have every vendor agree upon what ends a line and
to do away with the ^Z indicating EOF.

I think that possibly adding a "AUTO" text processing mode similar to what TCL
now is doing would be great.  Then if the file contains \r\n or \n or \r as
line endings it would just open the file mode appropriately and process it.

=====
Earnie Boyd <mailto:earnie_boyd AT yahoo DOT com>

Newbies, please visit
<http://www.freeyellow.com/members5/gw32/index.html>

(If you respond to the list, then please don't cc me)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com