Guake doesn't work with some shells

[zanko]

When I try using Guake with zsh or ksh as default shell, it doesn't work (the tab automatically closes itself or, if there is no other tab, the window hides itself).

[flow]

I experience the same problem: Gauke 0.3, Debian package. Shell: /usr/bin/fish (friendly interactive shell) Command line output of guake:

Error in sys.excepthook: RuntimeError?: maximum recursion depth exceeded

Original exception was: RuntimeError?: maximum recursion depth exceeded

But, by the way, great work you're doing here!

[lincoln]

I can't reproduce this bug, I tested with ksh, zsh, csh and other shells, but the problem did not happen. Is some error message being shown if you run guake from a gnome-terminal?

It will be really helpful if you can give me more info, like the content of your $SHELL variable before starting guake or something else.

ps.: I think the RuntimeError? is not a guake bug, but I'll try work around it. And I don't think it's the reason for problems with different shells.

Thank you for reporting.

[flow]

Well, probably you're right. I can use fish if executed from a bash shell, but not if set as default in the guake settings.

[zanko]

Replying to lincoln:

I can't reproduce this bug, I tested with ksh, zsh, csh and other shells, but the problem did not happen. Is some error message being shown if you run guake from a gnome-terminal?

No error message appear in gnome-terminal.

It will be really helpful if you can give me more info, like the content of your $SHELL variable before starting guake or something else.

My $SHELL variable countains /usr/bin/zsh but I tried with bash and it doesn't change anything.

I confirm that I can run zsh if executed from a bash shell, so I just have to put zsh in my .bashrc and set bash as the default guake shell but IMHO it's a ugly workaround... (and a bit slower as two shells have to start).

[BigForNothing]

I'm getting an error message launching zsh:
zsh4[19321]: segfault at 0 ip b7d87690 sp bfb09ca8 error 4 in libc-2.8.90.so[b7d0e000+158000]

That is being reported in my syslog. I'm running Ubuntu Intrepid Ibex, fully updated. 32bit.

[meux]

Hi,

are there some changes to this bug? I get same errors in syslog as BigForNothing?. I am using Ubuntu Intrepid Ibex.

Dec 16 15:42:30 msgw207 kernel: [105810.247556] zsh[24891]: segfault at 0 ip b7eea690 sp bf96aea8 error 4 in libc-2.8.90.so[b7e71000+158000] Dec 16 15:43:19 msgw207 kernel: [105859.943423] zsh[24949]: segfault at 0 ip b7e8f690 sp bf90fe48 error 4 in libc-2.8.90.so[b7e16000+158000] Dec 16 15:43:21 msgw207 kernel: [105862.170898] zsh[24951]: segfault at 0 ip b7f3a690 sp bf9baef8 error 4 in libc-2.8.90.so[b7ec1000+158000] Dec 16 15:43:38 msgw207 kernel: [105878.834986] zsh[24955]: segfault at 0 ip b7e54690 sp bfed7c08 error 4 in libc-2.8.90.so[b7ddb000+158000] Dec 16 15:43:39 msgw207 kernel: [105879.506997] zsh[24956]: segfault at 0 ip b7e57690 sp bffd8508 error 4 in libc-2.8.90.so[b7dde000+158000] Dec 16 15:44:49 msgw207 kernel: [105949.419805] zsh[24987]: segfault at 0 ip b7f2b690 sp bfcac9e8 error 4 in libc-2.8.90.so[b7eb2000+158000] Dec 16 15:45:11 msgw207 kernel: [105971.902461] zsh[25028]: segfault at 0 ip b7f15690 sp bfd98ac8 error 4 in libc-2.8.90.so[b7e9c000+158000] Dec 16 15:45:13 msgw207 kernel: [105974.054734] zsh[25031]: segfault at 0 ip b7e2b690 sp bfcaecc8 error 4 in libc-2.8.90.so[b7db2000+158000] Dec 16 15:45:39 msgw207 kernel: [105999.400517] zsh[25055]: segfault at 0 ip b7f1b690 sp bfd9e2d8 error 4 in libc-2.8.90.so[b7ea2000+158000] Dec 16 15:45:40 msgw207 kernel: [106000.744005] zsh[25056]: segfault at 0 ip b7e08690 sp bf888dc8 error 4 in libc-2.8.90.so[b7d8f000+158000]

[lincoln]

Hey, in #110 our friend snapshot killed a bug that makes zsh works, can someone test if that fix also kills this bug?

Thank you.

[lincoln]

As I said, I think it is already fixed by snapshot patch so if you have this problem again, please reopen this bug.

Thank you!

[andrei]

The same for me with the fish shell - the windows tends to show and then immediately hides itself I did some in-source research, and so far I found that

When hitting show:

def add_tab(self, *args):

works, at the end of the function len(self.term_list) is >= 1

but suddenly after that, the event box.terminal.connect('child-exited', self.on_terminal_exited, box) is received - that will lead to delete_tab

The add / delete calls never stop.

My config: Ubuntu 9.04 Jaunty amd64 guake version : 0.4.0 - latest git clone

I'll see further, I post this hoping that someone will have an idea...

[andrei]

I just said 0.4.0... no, it is the latest... 0.4.1...

[pingou]

That mean that you found a bug in a version not released yet :) Congrats ! :)

(No, you have version 0.4.0, lastest git)

[andrei]

I had to find it the hard way..

if login_shell:

paramsargv? = -?

So, if I could just checked Run command as a login shell in the preferences :)

But I must say... maybe guake should know about this Gnome Vte bug and set login shell = true for fish and zsh...

[andrei]

pingou said:

(No, you have version 0.4.0, lastest git)

Well, mine says 0.4.1 :) . It's not a release, it's the git clone from the repos I would upload a screenshot, but it doesn't really matter :)

[pingou]

I am a bit confuse there, you changed something in the code to make that working right ?

So why do you close the bug ? It's not close since it has not been integrated to the source.

Or did I misunderstood your comment ?

(And your guake says 0.4.1 because it's the latest version from git, but 0.4.1 is in development, so 0.4.1 does not exist yet (at least not really) ;-), but doesn't matter anyway, we agree :-) )

Thanks for your help :)

[andrei]

I'll first describe de bug:

The fork_command function NEEDS argv=-? parameter for zsh/fish

I found this by looking several hours in the code (ya... so proud) and so I found via debugging that there is an option in the preferences that activated this parameter ( Run command as a login shell ) ... my bad... I could have just tried all the options there :)

So, the bug is solved, but the solution is not documented, that's what I'm saying :)

[pingou]

Ok Thanks for your report and your help then :)

We know there are some effort to put on documentation (especially on those types of "not so well documented" options)

See Ticket #136 ;)

[andrei]

It was my pleasure :) I really like this program I'll stick around.. and if I see some 'I can handle bugs' in the tickets... I'll do my best to help :)