This is the mail archive of the
mailing list for the Cygwin project.
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
- Subject: RE: make, bash, or cygwin bug?
- From: Earnie Boyd <earnie_boyd at yahoo dot com>
- Date: Tue, 12 Oct 1999 07:28:37 -0700 (PDT)
- Reply-To: earnie_boyd at yahoo dot com
--- Bernard Dautrevaux <DAUTREVAUX@microprocess.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.)
> 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:firstname.lastname@example.org>
Newbies, please visit
(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 email@example.com