On Fri, Nov 27, 2015 at 08:52:01PM +0100, Philip Hands wrote: > Stephen Harris <lists@xxxxxxxxxx> writes: > > > On Thu, Nov 26, 2015 at 08:34:50PM -0500, Nico Kadel-Garcia wrote: > >> It's not clear, even to a reasonably intelligent bash progammer, that > >> the use of "exec" is to insure compatibility with fish and tcsh users. > > > > The use of exec is not to ensure compatability. Just doing > > sh -c "..." > > would be enough. > > > > The "exec" is for efficiency. It is not _needed_. > I doubt I'd have put the "exec" in, but having thought about it briefly, > I decided to keep it (at least until someone points to a shell that > doesn't have exec, but would otherwise succeed in running sh). I can come up with an artificial case (a "menu shell" type construct, or some embedded device with a limited CLI) but I can't think of any regular shell that'd suffer the issue. > FWIW I think Nico does have a point about having a comment that would > act as a reminder not to break the portability features of that line, so > that's what I'll do. A comment is definitely necessary because this thread has shown that a multi-decade old coding construct (I first came across it in 1991) isn't properly understood, even by the smart people on this list. If I was doing it from scratch I might have considered just having something like ssh -t "$@" /bin/sh -i and then putting the umask/mkdir/... commands on stdin before the pubkeys (that's how I've built solutions in the past) to keep complicated commands and quoting away from the CLI parser, but in this case the commands are simple enough that the proposed patch works well enough. -- rgds Stephen _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
