This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3.1 and gdb 5.2?
- From: Michael Veksler <veksler at il dot ibm dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: Joe Buck <Joe dot Buck at synopsys dot com>, doug at ikos dot com, gcc at gcc dot gnu dot org
- Date: Sun, 16 Jun 2002 09:21:31 +0300
- Subject: Re: gcc 3.1 and gdb 5.2?
- Reply-to: veksler at il dot ibm dot com
References: <200206141522.IAA27441@atrus.synopsys.com>
Andreas Schwab <schwab at suse dot de> writes:
> Joe Buck <Joe.Buck@synopsys.com> writes:
>
> |> The user does not expect gdb to invoke a shell.
>
> Well, he could just read the fine manual. :-)
In fact many utilities/applications do that. If your .cshrc is
messed up, then 'less' won't work either.
> |> The user is in csh
> |> and has already changed environment variables and is not expecting
> |> gdb to start up a new shell and wipe out the changes.
I tend to agreee with that.
This problem is not unique to csh/tcsh. It may happen with any
shell that reads startup files not only during login (zsh's
.zshenv comes to mind)
> Then he should fix his shell startup scripts. Setting environment
> variables in .cshrc is not TRT.
That's right, but......
The .cshrc startup file normally contains interactive csh setup only.
It is quite safe to disable .cshrc, and to call csh/tcsh with '-f'. For
that, gdb will have
to figure out that SHELL=*csh is csh/tcsh. and not ksh.
Is it acceptible to detect the type of shell in gdb, or is it considered
a hack too terrible to utter?