At Thu, 06 Mar 2025 14:05:33 +0700, Robert Elz <kre%munnari.OZ.AU@localhost> wrote: Subject: Re: parallel build failure with .c.o rule interrupted mid-step! > > Hmm - that's a dangerous way to operate, it reverts sh back to having > Thompson shell style semantics - the shell's command input is being > shared as stdin for all the commands that are run, so if anything being > run does anything to affect the position of stdin, almost anything is > possible (particularly as with Bourne type shells, it is much harder > to predict where the shell will have stdin positioned when a command > is executed. Sending commands through a pipe would be safer, at > least then commands can't alter the position via lseek() only an > actual read would do it, and that would be easier to observe. Setting up job shells to read from a pipe, and then feeding the commands to the pipe, could be more complex for make to do, I think, especially if the rule's commands are larger than a pipe can hold in one write. What about running the job script as a command file, i.e. "sh tempfile"? Of course then make can't unlink the file while holding an open file descriptor for it that is passed as stdin to the shell. It would have to wait until the shell started and had opened the command file before it unlinked the file. Make could inject an "rm tempfile" as the first command I suppose.... Possibly with "set +v" and "set -v" around it.... On the other hand this line of make has been feeding the job scripts to a shell's stdin for a great long time now, and I don't think I've seen or heard even the hint of any complaint about the shell mis-reading a job file, i.e. because of stdin being repositioned. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpPX0NLrDonZ.pgp
Description: OpenPGP Digital Signature