garbage in command line after exiting from turbo under putty4far2l about turbo HOT 13 CLOSED

And here is what we get in the case where we hang:

^[_far2lok^G
^[_far2lBA==^G // reply to ping 
^[_f2lAQASAAAAAgAAAAAAAABL^G // alt down
^[_f2lAQBYAAAAAgAAAFgAAABL^G // alt x
<ERR> // wgetch returns -1
f // ?
<ERR> // wgetch returns -1

Therefore, I think far2l is acting strangely but we should use a timeout when doing this. If despite all of this there's still garbage in the command line, then there's nothing else we can do.

I experienced the same behaviour while testing the win32-input-mode support, so I figured out this had nothing to do with far2l. That strange trace was caused by a problem with the way I was debugging the input characters, and the fact that the application got frozen was entirely a bug in Turbo Vision (which is now fixed).

from turbo.

I can't look into it right now, but that looks like an input event sent at the very end of the program's duration, maybe when the far2l extensions have already been disabled.

from turbo.

When I run turbo with some command line params, like turbo 1 2 3, garbage string starts not with executable file name, but with last param, 3f2lAQAmAAAAIAEAAAAAAABr

from turbo.

also reproduced under far2l if you run turbo not directly, but from bash shell

from turbo.

but reproduces only on remote (ssh) systems. so possibly some timing issue

from turbo.

AQAmAAAAIAEAAAAAAABr

That's a FARTTY_INPUT_KEYUP event.

from turbo.

That should fix it. If the connection is slow, then far2l will very likely send us events before extensions get disabled. The only way to consume these events without blocking forever is to send far2l a request right before disabling extensions so that we can keep discarding events until we get the response to that request.

This works with far2l since it replies to invalid requests. I don't know if putty4far2l supports it too, but if it doesn't you'll have to add support for it.

from turbo.

Now turbo often hangs with green screen when trying to exit, both under far2l and putty4far2l:

from turbo.

Damn it.

from turbo.

Btw, putty4far2l is indeed capable of replying to invalid requests, see https://github.com/unxed/putty4far2l/blob/master/terminal.c#L3639

from turbo.

Okay, here is what far2l replies in the normal case:

^[_far2lok^G
^[_far2lBA==^G // reply to ping
^[_f2lAQASAAAAAgAAAAAAAABL^G // alt down
^[_f2lAQBYAAAAAgAAAFgAAABL^G // x down
^[_f2lAQASAAAAAAAAAAAAAABr^G // alt up
^[_f2lAQBYAAAAAAAAAFgAAABr^G // x up
^[_far2lBA==^G // reply to ping
<ERR> // wgetch returns -1

And here is what we get in the case where we hang:

^[_far2lok^G
^[_far2lBA==^G // reply to ping 
^[_f2lAQASAAAAAgAAAAAAAABL^G // alt down
^[_f2lAQBYAAAAAgAAAFgAAABL^G // alt x
<ERR> // wgetch returns -1
f // ?
<ERR> // wgetch returns -1

Therefore, I think far2l is acting strangely but we should use a timeout when doing this. If despite all of this there's still garbage in the command line, then there's nothing else we can do.

from turbo.

@elfmz maybe you can suggest something?

from turbo.

Bug not reproduced any more, thanks!

from turbo.