Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
Message-ID: <00e901c027e9$f5ec6f30$c4acb018@home.com>
From: "Erik Nolte" <enolte@campuspipeline.com>
To: "Bernard Dautrevaux" <Dautrevaux@microprocess.com>,
        "'Matthew Smith'" <matts@bluesguitar.org>,
        "Cygwin" <cygwin@sources.redhat.com>
References: <17B78BDF120BD411B70100500422FC6309E10E@IIS000>
Subject: Re: Has CR/LF and cat problem with textutils-2.0 been solved?
Date: Tue, 26 Sep 2000 12:45:35 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> I don't think cat should strip \r's on input; I quite often use cat to
> concatenate binary data :-)
>
> 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.
>
> The problem here is thus IMNSHO in cat but in the shell, so *please* don't
> feed the cat with a new bug :-)

I agree.  Bash should do the CR-LF conversion for both forms of command
output expansion: `cmd` and $(cmd).  Sh should do the conversion for the
backticks form.

It's interesting that cat was placed in the line-oriented textutils package
rather than something like fileutils or shellutils.  But then again so was
od and the checksum utilities like sum and md5sum.

What cat's -B option for?  Since it's not in the FSF documentation, I
thought it was a cygwin addition that forced cat to *not* do the LF to CR-LF
output translation.  To me it implies that cat is reading and writing in
textmode, not binmode.

Since it will take a while to fix all the shells, should a --text flag be
added to cat?  I know it's ugly, but it saves people the trouble of having
to find a B20.1 version of cat.

- Erik


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