X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 496MTBOc2986607
Authentication-Results:	delorie.com;
	dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=CtYqX/8Z
X-Recipient:	djgpp AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20230601; t=1728253749; x=1728858549; darn=delorie.com;
	h=content-transfer-encoding:in-reply-to:from:references:to
	:content-language:subject:user-agent:mime-version:date:message-id
	:from:to:cc:subject:date:message-id:reply-to;
	bh=vNdL9eIApYpv+UjDbOAnxLmueX0H+fe1+xC479EOGKY=;
	b=CtYqX/8ZVCJAlpA7hVyEr0pEgKsYiYOMMiM0rb/cS24ylexp4mT23rmZLDEBoBF52b
	tFSyRLOKG6BIULJsypcrFe7hKBkrIp4U5pg0+YKtMBRuf3XsaHR4PijcO54/NLzdDSh0
	z1Zd65CJ/2bT7Gt6PaRrVaUC4s79B1Z65jN7IASuAVnRHgNhPJqOxeYDhRwzZc+h40Uh
	9WpnVSHXjV/NHwA/9UL2xGcZTwPxcfqm8x4LNLa4mfaAq9peUrw5l6G0BZOPeiMdjmeF
	bVKG61xsI084PN1VZBLTe9KnFM7xln2rd0xxMlZzkcw9SeRYztg1wvGUz2s0Tq5/gESP
	DEtw==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20230601; t=1728253749; x=1728858549;
	h=content-transfer-encoding:in-reply-to:from:references:to
	:content-language:subject:user-agent:mime-version:date:message-id
	:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
	bh=vNdL9eIApYpv+UjDbOAnxLmueX0H+fe1+xC479EOGKY=;
	b=ZEWoQJdCRWCxyQwx1ichQyahPoBbokPrGDfQa/ZJEA+j17p4xKU4t3BDzwUTbziN7N
	C5OqgKWbEVi7FXZuwofwaMNLlzwSbrB3o9scIbKP6CQgbA+a2ch1odnjLll9r2SbS7Cf
	JQrrPofaW4wcxXlzdx3Oeo7Gmna9eEkkSsvvC5HX4lJDCtC0TUCKpKKeeGUyH+1NI58S
	jdtKzoLNCeXGx2jJrKR6ev0RfZBTYxH2ziEcPuvkarxOIwCKUDf8fV23bEUnJR7zhurS
	17BxAziPYCFYxVyiDAOBch5MUYNZcv3OwOCA+KbsmhEYa8c7wcV1iAm3H9E4EjAAGsUZ
	bAug==
X-Gm-Message-State:	AOJu0Yyw9dDungRiXPv2GjweztxfeG+Dy2Av5Jc0ZRgpGJ4ai5R3dMh8
	rEkVe15zR90pTzgSB/8+1Z/MU08eg/s1IrMHm9928oBUan7+W6vQCqbNtA==
X-Google-Smtp-Source:	AGHT+IHvFdb0e9xXSGz+nmAdHU5x/LdG0eW1qjf9+BBO5fWcWhVGxBmcnM/Lg6d2OzTXsqpdf6DscA==
X-Received:	by 2002:a05:6402:5112:b0:5c8:83f1:2531 with SMTP id 4fb4d7f45d1cf-5c8d2e742f5mr10654553a12.28.1728253748368;
	Sun, 06 Oct 2024 15:29:08 -0700 (PDT)
Message-ID:	<947eafcc-d3ac-4588-8a02-9f44a759309b@gmail.com>
Date:	Mon, 7 Oct 2024 00:29:07 +0200
MIME-Version:	1.0
User-Agent:	Mozilla Thunderbird
Subject:	Re: Weird redirection behavior/bug in bash 4.4.28
To:	djgpp AT delorie DOT com
References:	<CAAxjCExA-MVJNGXNBXPGmxuON_YGZtMUJb7xjaG0c+JB-yxLhQ AT mail DOT gmail DOT com>
From:	"J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
In-Reply-To:	<CAAxjCExA-MVJNGXNBXPGmxuON_YGZtMUJb7xjaG0c+JB-yxLhQ@mail.gmail.com>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 2024-10-05 06:37, Stefan Ring (stefanrin AT gmail DOT com) [via djgpp AT delorie DOT com] wrote:
> I have been able to rebuild DJGPP gcc from the source zip files
> (gcc*s.zip) on Windows Vista for quite a while now and recently wanted
> to find out if it also works on Windows XP. The first stumbling block
> was that for some reason, bash kept crashing almost immediately. It
> was the old version 2.05b, which works perfectly fine on Vista, but
> not on XP, so I just swapped it for the most recent binary release,
> bsh4428, and tried to go ahead. After a while, the build would fail
> with libtool complaining "`atomic.lo' is not a valid libtool object",
> which was surprising, as the file looked perfectly normal (inside
> libbacktrace/):
> 
> --- %< ---
> # atomic.lo - a libtool object file
> # Generated by libtool (GNU libtool 1.3134 2009-11-29) 2.2.7a
> #
> # Please DO NOT delete this file!
> # It is necessary for linking the library.
> 
> # Name of the PIC object.
> pic_object=none
> 
> # Name of the non-PIC object
> non_pic_object='atomic.o'
> --- %< ---
> 
> After downgrading bash to 4.2.53, this started to work mysteriously,
> which sent me on a longish journey trying to build and patch interim
> bash versions (which is horrible and proved not to be useful anyway)
> and ultimately found that inside libtool, something like this short
> script is used, and somehow the DOS line endings in atomic.lo confuse
> bash:
> 
> set -o posix
> exec <atomic.lo
> while read a; do
> echo $a
> done
> 
> With the broken version 4.4, this is what comes out:
> 
> --- %< ---
> # atomic.lo - a libtool object file
> Generated by libtool (GNU libtool 1.3134 2009-11-29) 2.2.7a
> 
> se DO NOT delete this file!
> is necessary for linking the library.
> ame of the PIC object.
> bject=none
> Name of the non-PIC object
> n_pic_object='atomic.o'
> --- %< ---
> 
> So it loses a few characters or even the newline itself on all lines
> but the first one. This is what makes libtool unhappy, because it
> specifically looks for the pattern "# Generated by [...]". The same
> thing does not happen for a file with Unix line endings.

I had a look at this.  (BTW, the provided sources didn't cross-compile
out of the box, had to edit some files).

The problem lies in lib/sh/zread.c.  Normally, input is acquired from
_read() (via zreadbin()), which preserves CR as in binary mode.  The CRs
are then skipped over in the local buffer.  With 'set -o posix', it
instead uses read() (via zreadintr()), which skips CRs automatically.
After processing one line, it seeks back to the beginning of the next
line, but lseek() does not take the automatically-skipped CRs into
account.

Patch below fixes it by using binary _read() for POSIX-mode too and
copying the CR-skip logic.

This has the side effect that 'read -N' does not skip CR in POSIX-mode.
But zreadn() used for non-POSIX seems to have the same problem (there is
a *cp == '\r' check, but that doesn't look quite right).

---
--- a/lib/sh/zread.c
+++ b/lib/sh/zread.c
@@ -132,7 +132,7 @@ zreadintr (fd, buf, len)
      char *buf;
      size_t len;
 {
-  return (read (fd, buf, len));
+  return (_read (fd, buf, len));
 }
 
 /* Read one character from FD and return it in CP.  Return values are as
@@ -179,19 +179,24 @@ zreadcintr (fd, cp)
 {
   ssize_t nr;
 
-  if (lind == lused || lused == 0)
+  do
     {
-      nr = zreadintr (fd, lbuf, sizeof (lbuf));
-      lind = 0;
-      if (nr <= 0)
+      if (lind == lused || lused == 0)
 	{
-	  lused = 0;
-	  return nr;
+	  nr = zreadintr (fd, lbuf, sizeof (lbuf));
+	  lind = 0;
+	  if (nr <= 0)
+	    {
+	      lused = 0;
+	      return nr;
+	    }
+	  lused = nr;
 	}
-      lused = nr;
+      if (cp)
+	*cp = lbuf[lind++];
     }
-  if (cp)
-    *cp = lbuf[lind++];
+  while (cp && *cp == '\r');
+
   return 1;
 }
 

- Raw text -