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: Bernard Dautrevaux <DAUTREVAUX at microprocess dot com>
- Date: Tue, 12 Oct 1999 16:41:45 +0200
> -----Original Message-----
> From: Earnie Boyd [mailto:firstname.lastname@example.org]
> Sent: Tuesday, October 12, 1999 4:29 PM
> To: Bernard Dautrevaux; 'Kai Henningsen'; email@example.com
> Subject: RE: make, bash, or cygwin bug?
> --- Bernard Dautrevaux <DAUTREVAUX@microprocess.com> wrote:
> > 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
> END-OF-FILE is indicated. :-(
Why would you put a ^Z in a text file? ;-?
> > 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.
That's what I make in my tools that read text files (so that if I edit a
Makefile on Losedows, I can still "make" on UNIX :-)). However as far as
pipes (and especially pipes used by /bin/sh for `command substitution`) I
think it is safe to handle the read side in text-mode, and stop at the first
end-of-file and then close the pipe.
The only problem is if the substitude command writes binary data on its
output, but anyway, if I expect an ascii-coded integer, if I get it's 32-bit
integer value instead, I don't think sh will be able to do anything with it
:-). In all other cases, if there is a ^Z in the data read by sh, it's
indeed the EOF indicator, so all is fine.
97 bis, rue de Colombes
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org