"Vallon, Justin" <Justin.Vallon@xxxxxxxxxx> writes: >>Because POSIX shells are required to mark variables they inherit from the >>environment with the export attribute, your tests will run with SHELL >>exported to the environment if your usual shell is bash (i.e. SHELL is >>already exported to processes it spawns), even if you use another POSIX >>shell to run your git and tests. That makes the issue doubly harder to >>notice. > > I don't really follow this. The #! line is /bin/sh. The user's $SHELL > does not come into play. Either SHELL is in /bin/sh's environment and > it should be cleared in the child, or it isn't and it won't matter. Read what you are responding to again. The "doubly harder to notice" is _not_ about gentoo's /bin/sh, but about the experiment Matthieu did (ask: "what shell spawned t3404 that has the she-bang /bin/sh?"). If that shell is bash, which automatically marks SHELL with the export attribute, it places the variable in the environment. t3404 is run under /bin/sh, which presumably is POSIX and initializes its shell variable SHELL with what was in the environment, and while doing so, it also marks the variable with the export attribute. The script does not "unset SHELL" but merely assigns an empty string to it, which is the value to be exported to the processes the script runs. Imagine that whoever was having trouble did not have SHELL exported to the environment when t3404 is run. The script assigns an empty string to its shell variable SHELL but nothing marks the variable with the export attribute, hence the processes the script runs will never see that as the value of the environment variable (in fact, they wouldn't see SHELL environment variable at all). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html