I'm tempted to be snarky and say "you think this is just an optimization, but it is not", but that's probably a bit too harsh.
I would tend not to want this type of hidden semantic change to occur in dash if it can practically be avoided, because it would make dash less simple and clean in an unobvious way in exchange for a small gain in performance and a small gain in compatibility with Bash. "exec foo ..." and "foo ..." do not have exactly equivalent semantics even when each is the only command that will be executed by the shell before exiting, and Bash's behavior is something I would consider a somewhat kludgy extension behavior. It is entirely possible for a parent process that knows it is invoking a POSIX shell and needs the process tree to be shaped a certain way to specify the 'exec' itself---and for that matter it may as well just _do_ the exec itself in most cases. Depending on how it's implemented, this can also cause a sort of inconsistency fault line. Seemingly unrelated elements, such as changing one parameter into a backquote expansion or adding a redirect, can then introduce a new process even when the final execve() could theoretically be done the same way. Inserting, say, a debugging echo before the actual command is virtually guaranteed to not exec the final command directly. Essentially the question boils down to whether a provably final execution in a shell script should be treated as a tail execution in the absence of an explicit 'exec'. I would argue that for cleanliness either they should always be (which would be a lot of work and potentially more inconsistent with classic shell behavior and may make certain operations very difficult) or they should never be (which I believe is the current behavior). I believe Tim Connors's notion that not doing the exec transformation "causes the PPid line in /proc/$pid/status to be WRONG" is _thoroughly unjustified_ from a theoretical perspective, since system() does not specify that it will optimize away the shell process for a single command. This concern may however be valid as a matter of unfortunate backward compatibility for many forms of GNU/Linux. Nonetheless, POSIX:2001[1] seems to be ambiguous on the matter: it states that "the shell shall execute the utility in a separate utility environment with actions equivalent to calling the execve() function defined in the System Interfaces volume of IEEE Std 1003.1-2001 [...]" but the relation between utility environments and process environments seems to be unspecified, so the exec transformation may be acceptable to POSIX. (The dash man page doesn't seem to say which version of POSIX it's targeting.) [1] http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html ---> Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
