This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Clear GREP_OPTIONS environment variable.
On 16/03/2011 16:14, Joel Brobecker wrote:
>> Andrew> The test gdb.base/maint.exp shells out from gdb to use grep. I
>> Andrew> have GREP_OPTIONS="--color=auto" in my environment and this
>> Andrew> causes the test to fail. The patch below clears this environment
>> Andrew> variable before running gdb. Ok to apply?
>>
>> Andrew> 2011-03-15 Andrew Burgess<aburgess@broadcom.com>
>> Andrew> * lib/gdb.exp (default_gdb_start): Clear the GREP_OPTIONS
>> Andrew> environment variable to make grep output more predictable.
>>
>> Ok.
>
> I think that this is OK too. However, I'm wondering whether, as
> a followup, we should be moving this type of code to the gdb_init
> routine, rather than putting it there. The idea is to run this
> once per testcase, rather than once everytime we start a new GDB
> process.
>
So the patch below moves the environment setup into gdb_init. I don't see any regressions here. If this is preferred then I can commit this instead of the original patch.
Cheers,
Andrew
gdb/testsuite/ChangeLog
2011-03-15 Andrew Burgess <aburgess@broadcom.com>
* lib/gdb.exp (default_gdb_start,gdb_init): Clear the GREP_OPTIONS
environment variable to make grep output more predictable. Move
all the environment setup into gdb_init so it's done once per test
case rather than each time we start gdb.
* gdb.arch/altivec-abi.exp: Skip "generic" tests on 64-bit when
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 1b601af..7be05d1 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -1316,21 +1316,6 @@ proc default_gdb_start { } {
gdb_stop_suppressing_tests;
- set env(LC_CTYPE) C
-
- # Don't let a .inputrc file or an existing setting of INPUTRC mess up
- # the test results. Even if /dev/null doesn't exist on the particular
- # platform, the readline library will use the default setting just by
- # failing to open the file. OTOH, opening /dev/null successfully will
- # also result in the default settings being used since nothing will be
- # read from this file.
- set env(INPUTRC) "/dev/null"
-
- # The gdb.base/readline.exp arrow key test relies on the standard VT100
- # bindings, so make sure that an appropriate terminal is selected.
- # The same bug doesn't show up if we use ^P / ^N instead.
- set env(TERM) "vt100"
-
verbose "Spawning $GDB $INTERNAL_GDBFLAGS $GDBFLAGS"
if [info exists gdb_spawn_id] {
@@ -2797,11 +2782,30 @@ proc gdb_init { args } {
set banned_variables_traced 1
}
- # We set LC_ALL and LANG to C so that we get the same messages as
- # expected.
+ # We set LC_ALL, LC_CTYPE, and LANG to C so that we get the same
+ # messages as expected.
setenv LC_ALL C
+ setenv LC_CTYPE C
setenv LANG C
+ # Don't let a .inputrc file or an existing setting of INPUTRC mess up
+ # the test results. Even if /dev/null doesn't exist on the particular
+ # platform, the readline library will use the default setting just by
+ # failing to open the file. OTOH, opening /dev/null successfully will
+ # also result in the default settings being used since nothing will be
+ # read from this file.
+ setenv INPUTRC "/dev/null"
+
+ # The gdb.base/readline.exp arrow key test relies on the standard VT100
+ # bindings, so make sure that an appropriate terminal is selected.
+ # The same bug doesn't show up if we use ^P / ^N instead.
+ setenv TERM "vt100"
+
+ # Some tests (for example gdb.base/maint.exp) shell out from gdb to use
+ # grep. Clear GREP_OPTIONS to make the behavoiur predictable,
+ # especially having color output turned on can cause tests to fail.
+ setenv GREP_OPTIONS ""
+
return [eval default_gdb_init $args];
}