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
Content-Language: en-US
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>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk

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;
 }