This is the mail archive of the 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: Has CR/LF and cat problem with textutils-2.0 been solved?

> -----Original Message-----
> From: Chet Ramey []
> Sent: Wednesday, September 27, 2000 6:03 PM
> To:
> Cc:
> Subject: Re: Has CR/LF and cat problem with textutils-2.0 been solved?
> > >However *all* shells (and not only bash) *must* read the standard
> > >output of command expansion (backtick) in *text* mode, as it *does*
> > >expect text and is *not* willing to handle binary data there.
> > 
> > This was my point.  We fixed ash to do the right thing and 
> I've been waiting
> > patiently for the bash maintainer to fix bash as well.
> How about a bug report?  Or maybe an email?  I don't read this list
> very often, so, unless I get mail about it, `waiting patiently' is
> probably not going to get the job done.
> Now, do you want all '\r's stripped, or \r\n translated to \n when
> reading command substitution output?

The latter for sure; stripping all '\r's would be a bad thing IMHO, as you
may want to *mean* 'carriage return' (for overstriking for example) and then
will output a single '\r'. 

As a matter of fact now (both in UNIX and Win32 worlds) if you want to
*mean* 'line feed' and not 'end of line', you have to emit '\r\n<spaces>'
and you have to know how many spaces to emit ;-< The only justification one
may put to the Win32 CR-LF sequence is to restore the real meaning of LF;
but as one already pointed out 99.9% (or more) of Win32 programs interpret a
lone LF the UNIX way :-)



Bernard Dautrevaux
Microprocess Ingenierie
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

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