[haiku-3rdparty-dev] Re: Running gdb in a TerminalC.f

  • From: DarkWyrm <darkwyrm@xxxxxxxxx>
  • To: haiku-3rdparty-dev@xxxxxxxxxxxxx
  • Date: Wed, 7 Jul 2010 09:28:47 -0400

On Mon, Jul 5, 2010 at 3:11 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> On 2010-07-05 at 19:29:54 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> wrote:
>> "DarkWyrm" <darkwyrm@xxxxxxxxx> wrote:
>> > I've been coding for about 4 hours straight on not a lot of sleep, so
>> > sorry about the mixup. Any ideas?
>>
>> No. Since a "Terminal sleep 1" does what it should, a "Terminal gdb x"
>> should do so as well, but apparently, it does not. I'm afraid you don't
>> get around to do some debugging.
>
> "Terminal cat /system/boot/Bootscript" has problems too. The terminal
> window doesn't close automatically and most of the time it remains empty.
> Though I believe that is an unrelated issue -- probably a race condition
> between shell start and the rest of the terminal initialization.
>
> I guess the gdb issue is due to the Terminal setting the SHELL
> environmental variable to the program it starts. And gdb in turn uses SHELL
> to start the debugged program. Not sure if it's the terminal's
> responsibility to set that variable at all.
I did some testing and if Terminal doesn't set SHELL, then both
problems go away. The official bash documentation says that the bash
assigns it the full pathname of the current user's login shell if it's
not already set when the shell starts. I don't know much about UNIX
stuff like this, but it appears that it isn't needed. With that in
mind, should I go ahead and check in my patch?

--DW

Other related posts: