X-Spam-Check-By: sourceware.org
Date: Mon, 27 Feb 2006 11:23:21 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: sed: 4.1.5 breaks libtool generation
Message-ID: <20060227102321.GC30238@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <43FE1CEF DOT 9030905 AT users DOT sourceforge DOT net> <43FECB5A DOT 7060908 AT cwilson DOT fastmail DOT fm> <20060224094106 DOT GK4294 AT calimero DOT vinschen DOT de> <dtmpf1$o83$1 AT sea DOT gmane DOT org> <20060224114151 DOT GL4294 AT calimero DOT vinschen DOT de> <loom DOT 20060225T045242-102 AT post DOT gmane DOT org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <loom.20060225T045242-102@post.gmane.org>
User-Agent: Mutt/1.4.2i
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Feb 25 04:19, Wlodek Szafran wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> 
> > sed's internal getline enforces CRLF line ending recognition regardless
> > of the mount type, which results in mishandling of binary input files.
> > sed has no -b/--binary option.  So by using newlib's getline which
> > doesn't enforce CRLF->LF conversion, sed 4.1.5 should be actually
> > "fixed", FWIW.  If you need CRLF->LF conversion, you can use a filter
> > application like dos2unix.
> > 
> > Nothing's impossible, but I'd be actually surprised if that's the cause
> > for the libtool misbehaviour.
> 
> It seems to be the true reason, though.  I've noticed this strange behaviour
> with one of configure scripts I'm using.  The script uses sed to edit a file
> which consists of description/value pairs and before version 4.1.5 there were no
> problems.  After updating sed to this version, I've noted that the contents of
> the mentioned file were left unedited after the script ran, which was puzzling
> until reading here about the line endings.  A simple experiment shows that if
> the input file has CRLF line endings, no replacements of text happen -- the
> output file seems to be just a copy of the input one.  However, after the input
> file was converted to LF line endings, everything went back to normal.

Actually, what you describe is clear enough, but since CRLF handling
isn't done by the Linux version of sed either, you would have the same
problem on Linux.  The question here is how did this file get created
with CRLF in the first place?

However, I have a bit of a problem here, either files are read with CRLF
conversion, as up to 4.1.4.  In that case you can't use sed on binary
files.  Or sed does not do CRLF conversion as on any other OS.  Then you
get trouble with plain DOS files.  However, this latter problem can be
solved by using a filter like dos2unix before feeding the input to sed,
while the first problem can never be solved if sed always makes a CRLF
conversion.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/