Re: .ONESHELL enhancement?
David Boyce <[email protected]>
| Newsgroups | gmane.comp.gnu.make.devel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Sep 23, 2009 at 1:43 AM, Eric Melski <[email protected]> wrote: > If you imagine that > the command recipe is written to a temporary file and invoked as, eg, "sh > script.sh" when .ONESHELL is enabled, it would allow you to use arbitrary > interpreters as your shell. True - but are you imagining or suggesting? I don't think it's likely that make will be changed to _actually_ write its recipes to a temp file (though what do I know, I'm just an occasional lurker). And if you don't use a temp file you have the command line problem (sh -c vs perl -e vs ???). There's also the fact that interpreters other than sh may not have a "set -e" equivalent, though I suspect that once you've reassigned SHELL you're off the POSIX patch anyway. All I see in the standard on this question is "Other effects of defining SHELL in the makefile or on the command line are implementation-defined." I believe BSD make has the capacity to present the recipe to $(SHELL) on stdin, but that raises its own set of compatibility issues IIRC. > This wouldn't work with the "concatenate with &&" proposal. Yes, but the "concatenate with &&" proposal seems to have devolved into the "don't bother splitting on newlines" proposal anyway, so these unfortunate assumptions about the value of $(SHELL) go away. DSB