{"thread":{"id":"26139","subject":"[PATCH] Fix false positives in t3404 due to SHELL=/bin/false","startedAt":"2010-12-27T02:50:43Z","lastAt":"2011-01-05T18:51:09Z","messageCount":11,"participants":["Robin H. Johnson","Junio C Hamano","Vallon, Justin","Matthieu Moy","Jonathan Nieder"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"158608","messageId":"robbat2-20101227T024837-537032076Z@orbis-terrarum.net","threadId":"26139","inReplyTo":null,"subject":"[PATCH] Fix false positives in t3404 due to SHELL=/bin/false","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2010-12-27T02:50:43Z","receivedAt":"2010-12-27T02:50:43Z","isPatch":true,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"If the user's shell in NSS passwd is /bin/false (eg as found during Gentoo's\npackage building), the git-rebase exec tests will fail, because they call\n$SHELL around the command, and in the existing testcase, $SHELL was not being\ncleared sufficently.\n\nThis lead to false positive failures of t3404 on systems where the package\nbuild user was locked down as noted above.\n\nSigned-off-by: \"Robin H. Johnson\" \nX-Gentoo-Bug: 349083\nX-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=349083\n\ndiff -Nuar git-1.7.3.4.orig/t/t3404-rebase-interactive.sh git-1.7.3.4/t/t3404-rebase-interactive.sh\n--- git-1.7.3.4.orig/t/t3404-rebase-interactive.sh\t2010-12-16 02:52:11.000000000 +0000\n+++ git-1.7.3.4/t/t3404-rebase-interactive.sh\t2010-12-26 22:30:47.826421313 +0000\n@@ -67,8 +67,8 @@\n # \"exec\" commands are ran with the user shell by default, but this may\n # be non-POSIX. For example, if SHELL=zsh then \">file\" doesn't work\n # to create a file. Unseting SHELL avoids such non-portable behavior\n-# in tests.\n-SHELL=\n+# in tests. It must be exported for it to take effect where needed.\n+export SHELL=\n \n test_expect_success 'rebase -i with the exec command' '\n \tgit checkout master &&\n\n-- \nRobin Hugh Johnson\nGentoo Linux: Developer, Trustee & Infrastructure Lead\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85\n"},{"id":"158609","messageId":"7vsjxjyce6.fsf@alter.siamese.dyndns.org","threadId":"26139","inReplyTo":"robbat2-20101227T024837-537032076Z@orbis-terrarum.net","subject":"Re: [PATCH] Fix false positives in t3404 due to SHELL=/bin/false","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-27T06:10:09Z","receivedAt":"2010-12-27T06:10:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Robin H. Johnson\" writes:\n\n> # \"exec\" commands are ran with the user shell by default, but this may\n> # be non-POSIX. For example, if SHELL=zsh then \">file\" doesn't work\n> # to create a file. Unseting SHELL avoids such non-portable behavior\n> -# in tests.\n> -SHELL=\n> +# in tests. It must be exported for it to take effect where needed.\n> +export SHELL=\n\nThanks.\n\nThis probably is still not portable.\n\n\tSHELL=\n export SHELL\n\nwould be Ok, though.\n"},{"id":"158613","messageId":"20101227080343.GA15026@orbis-terrarum.net","threadId":"26139","inReplyTo":"7vsjxjyce6.fsf@alter.siamese.dyndns.org","subject":"[PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2010-12-27T08:03:43Z","receivedAt":"2010-12-27T08:03:43Z","isPatch":true,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"If the user's shell in NSS passwd is /bin/false (eg as found during Gentoo's\npackage building), the git-rebase exec tests will fail, because they call\n$SHELL around the command, and in the existing testcase, $SHELL was not being\ncleared sufficently.\n\nThis lead to false positive failures of t3404 on systems where the package\nbuild user was locked down as noted above.\n\nSigned-off-by: \"Robin H. Johnson\" \nX-Gentoo-Bug: 349083\nX-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=349083\n---\n t/t3404-rebase-interactive.sh | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\nindex d3a3bd2..7d8147b 100755\n--- a/t/t3404-rebase-interactive.sh\n+++ b/t/t3404-rebase-interactive.sh\n@@ -71,8 +71,9 @@ test_expect_success 'setup' '\n # \"exec\" commands are ran with the user shell by default, but this may\n # be non-POSIX. For example, if SHELL=zsh then \">file\" doesn't work\n # to create a file. Unseting SHELL avoids such non-portable behavior\n-# in tests.\n+# in tests. It must be exported for it to take effect where needed.\n SHELL=\n+export SHELL\n \n test_expect_success 'rebase -i with the exec command' '\n \tgit checkout master &&\n\n-- \nRobin Hugh Johnson\nGentoo Linux: Developer, Trustee & Infrastructure Lead\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85\n"},{"id":"158687","messageId":"7vmxnpwtyn.fsf@alter.siamese.dyndns.org","threadId":"26139","inReplyTo":"20101227080343.GA15026@orbis-terrarum.net","subject":"Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-28T19:58:08Z","receivedAt":"2010-12-28T19:58:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Robin H. Johnson\" writes:\n\n> If the user's shell in NSS passwd is /bin/false (eg as found during Gentoo's\n> package building), the git-rebase exec tests will fail, because they call\n> $SHELL around the command, and in the existing testcase, $SHELL was not being\n> cleared sufficently.\n\n> ---\n> t/t3404-rebase-interactive.sh | 3 ++-\n> 1 files changed, 2 insertions(+), 1 deletions(-)\n>\n> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\n> index d3a3bd2..7d8147b 100755\n> --- a/t/t3404-rebase-interactive.sh\n> +++ b/t/t3404-rebase-interactive.sh\n> @@ -71,8 +71,9 @@ test_expect_success 'setup' '\n> # \"exec\" commands are ran with the user shell by default, but this may\n> # be non-POSIX. For example, if SHELL=zsh then \">file\" doesn't work\n> # to create a file. Unseting SHELL avoids such non-portable behavior\n> -# in tests.\n> +# in tests. It must be exported for it to take effect where needed.\n> SHELL=\n> +export SHELL\n\nThanks; will queue this version to 'maint'.\n\nI have this nagging suspicion that we may want to revisit this to assign\n$SHELL_PATH to it before exporting, and that this might be better done in\nt/test-lib.sh at the beginning. Note that unlike my earlier \"your v1\nmight be less portable than desired\", these two points are only\nspeculations and RFCs.\n"},{"id":"158890","messageId":"982E526FA742C94E9AC26DA766FD07090A3399@NYCMBX3.winmail.deshaw.com","threadId":"26139","inReplyTo":"20101227080343.GA15026@orbis-terrarum.net","subject":"RE: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false","fromName":"Vallon, Justin","fromEmail":"justin.vallon@deshaw.com","sentAt":"2011-01-04T14:43:12Z","receivedAt":"2011-01-04T14:43:12Z","isPatch":true,"sender":{"key":"justin.vallon@deshaw.com","avatar":null},"body":" # \"exec\" commands are ran with the user shell by default, but this may\n # be non-POSIX. For example, if SHELL=zsh then \">file\" doesn't work\n # to create a file. Unseting SHELL avoids such non-portable behavior\n\nPerl's exec and system do not use SHELL (as far as perlfunc states). It uses /bin/sh -c \"$cmd\", or a platform-dependent equivalent.\n\n$SHELL is typically only used when a program wants to invoke a user-shell (ie: editor shell-escape, xterm, typescript, screen).\n\nHow was SHELL=/bin/false causing problems? Is git using $SHELL?\n\n-- \n-Justin\n\n\n-----Original Message-----\nFrom: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Robin H. Johnson\nSent: Monday, December 27, 2010 3:04 AM\nTo: Junio C Hamano; git@vger.kernel.org\nSubject: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false\n\nIf the user's shell in NSS passwd is /bin/false (eg as found during Gentoo's\npackage building), the git-rebase exec tests will fail, because they call\n$SHELL around the command, and in the existing testcase, $SHELL was not being\ncleared sufficently.\n\nThis lead to false positive failures of t3404 on systems where the package\nbuild user was locked down as noted above.\n\nSigned-off-by: \"Robin H. Johnson\" \nX-Gentoo-Bug: 349083\nX-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=349083\n---\n t/t3404-rebase-interactive.sh | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\nindex d3a3bd2..7d8147b 100755\n--- a/t/t3404-rebase-interactive.sh\n+++ b/t/t3404-rebase-interactive.sh\n@@ -71,8 +71,9 @@ test_expect_success 'setup' '\n # \"exec\" commands are ran with the user shell by default, but this may\n # be non-POSIX. For example, if SHELL=zsh then \">file\" doesn't work\n # to create a file. Unseting SHELL avoids such non-portable behavior\n-# in tests.\n+# in tests. It must be exported for it to take effect where needed.\n SHELL=\n+export SHELL\n \n test_expect_success 'rebase -i with the exec command' '\n \tgit checkout master &&\n\n-- \nRobin Hugh Johnson\nGentoo Linux: Developer, Trustee & Infrastructure Lead\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85\n"},{"id":"158913","messageId":"robbat2-20110104T203312-513011947Z@orbis-terrarum.net","threadId":"26139","inReplyTo":"982E526FA742C94E9AC26DA766FD07090A3399@NYCMBX3.winmail.deshaw.com","subject":"Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2011-01-04T20:35:38Z","receivedAt":"2011-01-04T20:35:38Z","isPatch":true,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Tue, Jan 04, 2011 at 09:43:12AM -0500, Vallon, Justin wrote:\n> # \"exec\" commands are ran with the user shell by default, but this may\n> # be non-POSIX. For example, if SHELL=zsh then \">file\" doesn't work\n> # to create a file. Unseting SHELL avoids such non-portable behavior\n> \n> Perl's exec and system do not use SHELL (as far as perlfunc states). It uses\n> /bin/sh -c \"$cmd\", or a platform-dependent equivalent.\n> \n> $SHELL is typically only used when a program wants to invoke a user-shell\n> (ie: editor shell-escape, xterm, typescript, screen).\n> \n> How was SHELL=/bin/false causing problems? Is git using $SHELL?\ngit-rebase--interactive.sh:\n====\n${SHELL:-@SHELL_PATH@} -c \"$rest\" # Actual execution\nstatus=$?\nif test \"$status\" -ne 0\nthen\n\twarn \"Execution failed: $rest\"\n====\n\nThis always triggers with SHELL=/bin/false if SHELL is unset or empty,\nSHELL_PATH gets substituted, which tends to be the correct /bin/sh.\n\n-- \nRobin Hugh Johnson\nGentoo Linux: Developer, Trustee & Infrastructure Lead\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85\n"},{"id":"158918","messageId":"vpqhbdoxpzp.fsf@bauges.imag.fr","threadId":"26139","inReplyTo":"982E526FA742C94E9AC26DA766FD07090A3399@NYCMBX3.winmail.deshaw.com","subject":"Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-01-04T22:28:58Z","receivedAt":"2011-01-04T22:28:58Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"Vallon, Justin\" writes:\n\n> How was SHELL=/bin/false causing problems? Is git using $SHELL?\n\nThe explanation is in the comment right above the modification in the\npatch. \"user's shell\" can be read as \"$SHELL\":\n\n> --- a/t/t3404-rebase-interactive.sh\n> +++ b/t/t3404-rebase-interactive.sh\n> @@ -71,8 +71,9 @@ test_expect_success 'setup' '\n> # \"exec\" commands are ran with the user shell by default, but this may\n> # be non-POSIX. For example, if SHELL=zsh then \">file\" doesn't work\n> # to create a file. Unseting SHELL avoids such non-portable behavior\n> -# in tests.\n> +# in tests. It must be exported for it to take effect where needed.\n> SHELL=\n> +export SHELL\n\n(my bad, I wrote this SHELL= without exporting it. Since bash\nre-exports already exported variables when they are assigned, and my\n/bin/sh points to bash, I didn't notice)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"158919","messageId":"20110104225826.GA2122@burratino","threadId":"26139","inReplyTo":"vpqhbdoxpzp.fsf@bauges.imag.fr","subject":"Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-01-04T22:58:26Z","receivedAt":"2011-01-04T22:58:26Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Matthieu Moy wrote:\n> \"Vallon, Justin\" writes:\n\n>> --- a/t/t3404-rebase-interactive.sh\n>> +++ b/t/t3404-rebase-interactive.sh\n>> @@ -71,8 +71,9 @@ test_expect_success 'setup' '\n>> # \"exec\" commands are ran with the user shell by default, but this may\n>> # be non-POSIX. For example, if SHELL=zsh then \">file\" doesn't work\n>> # to create a file. Unseting SHELL avoids such non-portable behavior\n>> -# in tests.\n>> +# in tests. It must be exported for it to take effect where needed.\n>> SHELL=\n>> +export SHELL\n>\n> (my bad, I wrote this SHELL= without exporting it. Since bash\n> re-exports already exported variables when they are assigned, and my\n> /bin/sh points to bash, I didn't notice)\n\nIsn't that how export works in all Bourne-style shells? For example:\n\n\t$ env var=outside dash -c '\n\t\tvar=inside;\n\t\tdash -c \"echo \\$var\"\n\t '\n\tinside\n\t$\n\nMaybe in the failing case SHELL was not exported but just set to\n/bin/false in .bashrc or similar?\n"},{"id":"158922","messageId":"7vmxngdys8.fsf@alter.siamese.dyndns.org","threadId":"26139","inReplyTo":"20110104225826.GA2122@burratino","subject":"Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-04T23:39:19Z","receivedAt":"2011-01-04T23:39:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Matthieu Moy wrote:\n>> \"Vallon, Justin\" writes:\n>\n>>> --- a/t/t3404-rebase-interactive.sh\n>>> +++ b/t/t3404-rebase-interactive.sh\n>>> @@ -71,8 +71,9 @@ test_expect_success 'setup' '\n>>> # \"exec\" commands are ran with the user shell by default, but this may\n>>> # be non-POSIX. For example, if SHELL=zsh then \">file\" doesn't work\n>>> # to create a file. Unseting SHELL avoids such non-portable behavior\n>>> -# in tests.\n>>> +# in tests. It must be exported for it to take effect where needed.\n>>> SHELL=\n>>> +export SHELL\n>>\n>> (my bad, I wrote this SHELL= without exporting it. Since bash\n>> re-exports already exported variables when they are assigned, and my\n>> /bin/sh points to bash, I didn't notice)\n>\n> Isn't that how export works in all Bourne-style shells? For example:\n>\n> \t$ env var=outside dash -c '\n> \t\tvar=inside;\n> \t\tdash -c \"echo \\$var\"\n> \t '\n> \tinside\n> \t$\n>\n> Maybe in the failing case SHELL was not exported but just set to\n> /bin/false in .bashrc or similar?\n\nThanks, you saved me some time responding ;-)\n\nMatthieu's diagnosis is only half correct in that bash is why he didn't\nnotice the problem, but if in this sequence\n\n\tvar=foo\n export var\n var=bar\n some-command\n\nsome-command does not see \"bar\" as the value of environment variable\n\"var\", your shell is not POSIX (there is no such thing as \"re-exporting\").\n\nEither a variable is marked with the export attribute, in which case the\nprocesses spawned from the shell sees the value of the then-current shell\nvariable in their environments, or they don't for shell variables that are\nnot marked with the export attribute.\n\nThe real reason the problem went unnoticed was because bash automatially\nmarks SHELL with the export attribute.\n\nBecause POSIX shells are required to mark variables they inherit from the\nenvironment with the export attribute, your tests will run with SHELL\nexported to the environment if your usual shell is bash (i.e. SHELL is\nalready exported to processes it spawns), even if you use another POSIX\nshell to run your git and tests. That makes the issue doubly harder to\nnotice.\n"},{"id":"158962","messageId":"982E526FA742C94E9AC26DA766FD07090A33A5@NYCMBX3.winmail.deshaw.com","threadId":"26139","inReplyTo":"7vmxngdys8.fsf@alter.siamese.dyndns.org","subject":"RE: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false","fromName":"Vallon, Justin","fromEmail":"justin.vallon@deshaw.com","sentAt":"2011-01-05T15:04:54Z","receivedAt":"2011-01-05T15:04:54Z","isPatch":true,"sender":{"key":"justin.vallon@deshaw.com","avatar":null},"body":">-----Original Message-----\n>From: Junio C Hamano [mailto:gitster@pobox.com]\n>Sent: Tuesday, January 04, 2011 6:39 PM\n>To: Jonathan Nieder\n>Cc: Matthieu Moy; Vallon, Justin; Robin H. Johnson; git@vger.kernel.org\n>Subject: Re: [PATCH v2] Fix false positives in t3404 due to\n>SHELL=/bin/false\n>\n>Jonathan Nieder writes:\n>\n>> Matthieu Moy wrote:\n>>>\n>>> (my bad, I wrote this SHELL= without exporting it. Since bash\n>>> re-exports already exported variables when they are assigned, and my\n>>> /bin/sh points to bash, I didn't notice)\n>>\n>> Isn't that how export works in all Bourne-style shells? For example:\n>>\n>> \t$ env var=outside dash -c '\n>> \t\tvar=inside;\n>> \t\tdash -c \"echo \\$var\"\n>> \t '\n>> \tinside\n>> \t$\n>>\n>> Maybe in the failing case SHELL was not exported but just set to\n>> /bin/false in .bashrc or similar?\n>\n>Thanks, you saved me some time responding ;-)\n>\n>Matthieu's diagnosis is only half correct in that bash is why he didn't\n>notice the problem, but if in this sequence\n>\n>\tvar=foo\n> export var\n> var=bar\n> some-command\n>\n>some-command does not see \"bar\" as the value of environment variable\n>\"var\", your shell is not POSIX (there is no such thing as \"re-exporting\").\n\nBut, when you say \"your shell\", you are really referring to /bin/sh, because this behavior is being observed in t/t3404-rebase-interactive.sh. Which leads to...\n\nRobin: have you observed the problem with Gentoo's /bin/sh?\n\nX=1 ; export X ; /bin/sh -c 'X= ; env | grep ^X='\n\nIf so, I would qualify the export with a comment about the mis-behavior:\n\n# Reexport in case sh is non-POSIX\nexport SHELL\n\n(or, just unset SHELL)\n\nElse, I don't think the re-export is needed (something else is causing your trouble).\n\n>Because POSIX shells are required to mark variables they inherit from the\n>environment with the export attribute, your tests will run with SHELL\n>exported to the environment if your usual shell is bash (i.e. SHELL is\n>already exported to processes it spawns), even if you use another POSIX\n>shell to run your git and tests. That makes the issue doubly harder to\n>notice.\n\nI 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.\n\n-- \n-Justin\n"},{"id":"158978","messageId":"7vsjx7chgi.fsf@alter.siamese.dyndns.org","threadId":"26139","inReplyTo":"982E526FA742C94E9AC26DA766FD07090A33A5@NYCMBX3.winmail.deshaw.com","subject":"Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-05T18:51:09Z","receivedAt":"2011-01-05T18:51:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Vallon, Justin\" writes:\n\n>>Because POSIX shells are required to mark variables they inherit from the\n>>environment with the export attribute, your tests will run with SHELL\n>>exported to the environment if your usual shell is bash (i.e. SHELL is\n>>already exported to processes it spawns), even if you use another POSIX\n>>shell to run your git and tests. That makes the issue doubly harder to\n>>notice.\n>\n> I don't really follow this. The #! line is /bin/sh. The user's $SHELL\n> does not come into play. Either SHELL is in /bin/sh's environment and\n> it should be cleared in the child, or it isn't and it won't matter.\n\nRead what you are responding to again.\n\nThe \"doubly harder to notice\" is _not_ about gentoo's /bin/sh, but about\nthe experiment Matthieu did (ask: \"what shell spawned t3404 that has the\nshe-bang /bin/sh?\").\n\nIf that shell is bash, which automatically marks SHELL with the export\nattribute, it places the variable in the environment. t3404 is run under\n/bin/sh, which presumably is POSIX and initializes its shell variable SHELL\nwith what was in the environment, and while doing so, it also marks the\nvariable with the export attribute. The script does not \"unset SHELL\" but\nmerely assigns an empty string to it, which is the value to be exported to\nthe processes the script runs.\n\nImagine that whoever was having trouble did not have SHELL exported to the\nenvironment when t3404 is run. The script assigns an empty string to its\nshell variable SHELL but nothing marks the variable with the export\nattribute, hence the processes the script runs will never see that as the\nvalue of the environment variable (in fact, they wouldn't see SHELL\nenvironment variable at all).\n"}]}