henry (05/30/82)
Consider the following shell program: PATH=/bin:/usr/bin readnews ... The obvious intent here (since the change to PATH is not exported) is to change PATH for the search for readnews, but preserve the original PATH into readnews for the benefit of shell escapes. Call that program "tryit". Now try the following two invocations, testing each time to determine whether the PATH change really did get exported: tryit sh tryit Only in the second case is the PATH change local to the shellfile itself. The problem is that in the first case, the shell is forking itself without an unnecessary exec (a reasonable optimization, and part of the reason why shell files work so much better in V7 than in V6) and is **not** reinitializing itself properly. The export status of PATH is inherited from the parent shell rather than being properly reset to "no export". I have argued in the past that the export status of variables inherited from the parent should be "exported" by default; that is somewhat debatable, not the least because there is software that depends on the "no export" default. What is *not* debatable is that the above problem represents a bug regardless: the net effect is that the default is "exported" for shell files invoked directly and "no export" for less direct invocations, a troublesome and bug-prone behavior difference. I do not have a fix for this one, and am reluctant to plunge into the morass inside /bin/sh. Has anybody else cured this one? Does anybody know if 3.0's sh has it fixed?