Hi Jim,
I hope you can remember this issue (dircolors test failing with SHELL
unset) after more than five months. I'm quoting your whole mail:
On Sun, Mar 5 2006, Jim Meyering wrote:
Sven Joachim <[EMAIL PROTECTED]> wrote:
The reason why the help-version test failed on dircolors is that the SHELL
variable
was not set at all. This is probably rather unusual, since bash (and probably
other
shells as well) will set SHELL to the value of your login shell, if it is not
set.
But the "debuild" script removes most variables from the environment by default,
including SHELL. You can convince yourself that "dircolors" fails if SHELL is
unset:
$ SHELL="" dircolors
dircolors: no SHELL environment variable, and no shell type option given
$ echo $?
1
$
Maybe you want to set something like
dircolors_args=-b
Thanks. I've defined $SHELL, but only if it's not already set.
Then, we'll get slightly better coverage via people running with
different shells. But I'm not sure that's a benefit :-)
2006-03-05 Jim Meyering <[EMAIL PROTECTED]>
* tests/help-version: Set SHELL, if not already set, in order to
avoid failure when `make check' is run through debuild; dircolors
would fail due to lack of $SHELL. Reported by Sven Joachim.
Index: tests/help-version
===================================================================
RCS file: /fetish/cu/tests/help-version,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -p -u -r1.18 -r1.19
--- tests/help-version 7 Feb 2006 09:18:28 -0000 1.18
+++ tests/help-version 5 Mar 2006 17:28:42 -0000 1.19
@@ -4,6 +4,14 @@
test "$VERBOSE" = yes && set -x
+# Ensure that $SHELL is set to *some* value.
+# This is required for dircolors, which would fail e.g., when
+# invoked via debuild (which removes SHELL from the environment).
+if test "x$SHELL" = x; then
+ SHELL=/bin/sh
+ export SHELL
+fi
+
expected_failure_status_nohup=127
expected_failure_status_printenv=2
expected_failure_status_tty=3
Now that the coreutils 6.0 version is available in Debian
experimental, I tested this, but the dircolors test still fails. :-(
After some investigation I found out why: If SHELL is not set, bash
(/bin/sh) will set but not export it, as you can see from the
following session:
$ (unset SHELL; /bin/sh)
sh-3.1$ echo $SHELL
/bin/bash
sh-3.1$ printenv | grep 'SHELL'
sh-3.1$
So 'test "x$SHELL" = x' fails and SHELL is not exported. The following
patch should fix this, exporting SHELL in any case:
--- help-version~ 2006-06-01 09:32:43.000000000 +0200
+++ help-version 2006-08-19 16:40:45.000000000 +0200
@@ -9,8 +9,8 @@
# invoked via debuild (which removes SHELL from the environment).
if test "x$SHELL" = x; then
SHELL=/bin/sh
- export SHELL
fi
+export SHELL
expected_failure_status_nohup=127
expected_failure_status_printenv=2
Kind regards,
Sven
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
