Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Fernando Nasser <fnasser@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH RFA] gdb.base/completion.exp: Set INPUTRC env variable
Date: Wed, 23 May 2001 17:35:00 -0000	[thread overview]
Message-ID: <3B0C56B9.567986F1@redhat.com> (raw)
In-Reply-To: <1010518235834.ZM16437@ocotillo.lan>

Wow! Nice catch! Thanks!

But we need to make sure tests do not interfere with others.  So, what
we always do (I hope) when changing globals inside the scope of a test
is to save the global value, set to whatever the test wants it to be,
change it back at the end.  In this case, you can test if the element
INPUTRC of the global array "env" exists and, if it does, save it's
previous value.

However, I can't think of anything else wanting to set or being
influenced by INPUTRC, so maybe we can be lazy this time and just check
your patch as is -- better add a FIXME or a NOTE to this fact at least.
If you feel confident that this is so, please go ahead and check it in.

Regards,
Fernando


Kevin Buettner wrote:
> 
> I have a ~/.inputrc file whose settings ("set editing-mode vi") are
> causing failures when running the gdb.base/completion.exp tests.  These
> are the failures that I'm seeing:
> 
>     FAIL: gdb.base/completion.exp: (timeout) complete 'p' 1
>     FAIL: gdb.base/completion.exp: (timeout) complete 'p ' 2
>     FAIL: gdb.base/completion.exp: (timeout) complete 'info t foo'
>     FAIL: gdb.base/completion.exp: (timeout) complete 'info t'
>     FAIL: gdb.base/completion.exp: (timeout) complete 'info t '
>     FAIL: gdb.base/completion.exp: (timeout) complete 'info asdfgh'
>     FAIL: gdb.base/completion.exp: (timeout) complete 'info asdfgh '
>     FAIL: gdb.base/completion.exp: (timeout) complete 'info'
>     FAIL: gdb.base/completion.exp: (timeout) complete 'info '
>     FAIL: gdb.base/completion.exp: (timeout) complete (2) 'info '
>     FAIL: gdb.base/completion.exp: (timeout) complete 'p "a'
>     FAIL: gdb.base/completion.exp: (timeout) complete 'p 'a'
>     FAIL: gdb.base/completion.exp: (timeout) complete (2) 'p 'a'
>     FAIL: gdb.base/completion.exp: (timeout) complete 'p b-a'
>     FAIL: gdb.base/completion.exp: (timeout) complete (2) 'p b-a'
>     FAIL: gdb.base/completion.exp: (timeout) complete (2) 'p b-'
>     FAIL: gdb.base/completion.exp: (timeout) complete 'file Make'
>     FAIL: gdb.base/completion.exp: (timeout) complete 'file gdb.base/compl'
>     FAIL: gdb.base/completion.exp: (timeout) complete 'info func mar'
>     FAIL: gdb.base/completion.exp: (timeout) complete 'set follow-fork-mode'
> 
> In order to solve this problem, it seems to me that we want to use the
> default editing mode, keybindings, and readline settings.  This means
> that simply making sure that GDB is in emacs mode won't be sufficient
> since an inputrc file could have changed another critical setting
> which could also cause testsuite failures.  E.g, I think that changing
> any of bell-style, disable-completion, or show-all-if-ambiguous from
> the default setting would change GDB's behavior enough to cause
> failures in completion.exp.
> 
> Since the presence of an INPUTRC environment variable overrides the a
> possible ~/.inputrc, it seems sufficient to set this variable to a
> value which will guarantee that the default settings are used.  I
> chose to use /dev/null; if it exists, it contains nothing thus causing
> all of the defaults to be used.  If it doesn't exist or can't be
> opened for some other reason, failure to open the file will also cause
> the defaults to be used.
> 
> Okay to commit?
> 
>         * gdb.base/completion.exp (INPUTRC): Set this environment variable
>         to a known value in order to get consistent results regardless
>         of the setting of INPUTRC or the presence or contents of .inputrc.
> 
> Index: testsuite/gdb.base/completion.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.base/completion.exp,v
> retrieving revision 1.3
> diff -u -p -r1.3 completion.exp
> --- completion.exp      2001/05/11 19:53:38     1.3
> +++ completion.exp      2001/05/18 23:04:10
> @@ -72,6 +72,16 @@ if [get_compiler_info ${binfile}] {
>  }
> 
>  gdb_exit
> +
> +# 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.
> +global env
> +set env(INPUTRC) "/dev/null"
> +
>  gdb_start
>  gdb_reinitialize_dir $srcdir/$subdir
>  gdb_load ${binfile}

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9


  reply	other threads:[~2001-05-23 17:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-18 16:59 Kevin Buettner
2001-05-23 17:35 ` Fernando Nasser [this message]
2001-05-29 20:22   ` Kevin Buettner
2001-05-30  5:17     ` Fernando Nasser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B0C56B9.567986F1@redhat.com \
    --to=fnasser@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kevinb@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox