Date: Fri, 07 Sep 2001 17:41:55 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Juan Manuel Guerrero" Message-Id: <6480-Fri07Sep2001174153+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9 CC: pavenis AT lanet DOT lv, djgpp-workers AT delorie DOT com In-reply-to: <6745033395E@HRZ1.hrz.tu-darmstadt.de> (ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De) Subject: Re: Problem with sed3028b.zip References: <6745033395E AT HRZ1 DOT hrz DOT tu-darmstadt DOT de> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Juan Manuel Guerrero" > Date: Fri, 7 Sep 2001 14:43:28 +0200 > > Only FYI: I have used the following very naive test file: > > bar\ > foo\ > bar > > and run the sed command: > > "s/bar/rab/;s/foo/oof/" > > I have inspected the produced file with a hex-editor. The file > is completely ok. Especially, all backslashes are followed *only* > by CR LF. This is independent of the EOL used in the source file. The code I wrote to remove CRs only if followed by an LF might have some obscure bug, that only raises its ugly head in some rare situation, like when the CR character is the last one in the buffer (and Sed needs to look ahead to see if there's an LF after it). The logic there is pretty tricky. I will take another look, but don't hold your breath: I usually don't find obscure bugs by just looking at the code. So I agree a small test case that reproduces this would be useful: there's nothing like GDB to find such bugs. Also, this might not be a bug in Sed, but rather something caused by another utility (e.g., `tr'), which the new Sed exposes, since it doesn't remove lone CR characters, like the older ports did.