On Fri, Jun 21, 2024 at 13:44:35 +0200, Nicolas George wrote: > Greg Wooledge (12024-06-21): > > The original message began with the assertion that the OP had run > > across a bug in dash, and gave two URLs, with no description of the bug > > or the impact it was having on their life. > > > > I read one of the URLs, and the bug is rather obscure. It involves a > > second script embedded inside a here document inside the first script, > > with the second script being passed to an interpreter process on stdin. > > I'm not surprised that nobody knew about the bug for many years. > > The purported bug boils down to this: if you pipe to a non-interactive > shell a command and data for that command, then the non-interactive > shell might read more than just the command as part of its input > buffering and leave less or nothing as data to the command itself. > > It is indeed a bug, since the standard says: > > When the shell is using standard input and it invokes a command that > also uses standard input, the shell shall ensure that the standard > input file pointer points directly after the command it has read when > the command begins execution.
I understood the bug as described. I've been doing shell stuff for a while now, and I've picked up a few bits of knowledge here and there. I still claim that it's an obscure corner case that most script writers will never encounter. That's why I find it frustrating when someone claims that this bug is so severe that Debian has to *change their policy* without even describing how this bug is affecting them in real life. > But I consider this clause is misguided, it should apply only when the > input is a tty. Relying on it is a terrible idea. I think the POSIX wording is there primarily because of here documents, and people doing what I can only *guess* is similar to what the OP of this thread wanted to do -- embedding layers of scripts inside scripts using here documents. I doubt that the wording was intended only for input coming from terminals.