This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: make, bash, or cygwin bug?


> -----Original Message-----
> From: Earnie Boyd [mailto:earnie_boyd@yahoo.com]
> Sent: Tuesday, October 12, 1999 4:29 PM
> To: Bernard Dautrevaux; 'Kai Henningsen'; cygwin@sourceware.cygnus.com
> Subject: RE: make, bash, or cygwin bug?
> 
> 
> --- Bernard Dautrevaux <DAUTREVAUX@microprocess.com> wrote:
	
		<snipped>

> > 
> > 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. :-(

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.

Regards,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]