2017-09-10 05:54:48 +0700, Robert Elz: > Date: Sat, 9 Sep 2017 20:41:42 +0200 > From: Martijn Dekker <mart...@inlv.org> > Message-ID: <a2026657-ab97-c920-e19d-dc3a32877...@inlv.org> > > | Relevant here is that 'exec' is a special builtin (unlike 'command'). > | 2.9.1 Simple Commands seems to suggest[*1] that it is unspecified > MD> - Whether or not the variables gain the export attribute MD> during the execution of the special built-in utility
> No it doesn't. The first bullet applies to the execution of exec itself > (so a var assignment to PATH might not affect the search for the command > to be executed - or might - unspecified) not to the command that is run. [...] I don't agree. To me, that text (which changed in issue7-TC2) is clearly there explicitly to allow shells not to export the variable in things like: VAR=foo eval 'some shell code' as is the case in most shells or VAR=foo exec cmd as is the case in the Bourne shell and ksh88 (on which is based the specification). (see also VAR=value myfunction or VAR=value . script) In any case, one can't rely on it, I remember I needed to do exec env SHELL=/path/to/zsh screen for instance on Solaris (which also has the merit to work with shells of other families like csh, fish, rc, or with variables names that are not valid in the current shell). In the case of "exec", I agree it makes more sense to pass the variables in the environment of cmd, especially if we now want to force shells to make sure exec always execve()s an external command. -- Stephane
