garbage in command line after exiting from turbo under putty4far2l

[unxed]

When using putti4far2l, sometimes when exiting turbo, garbage appears in the bash command line. Like this:

./turbof2lAQANABwAIAAAAA0AAABr

Maybe some bug with disabling far2l extensions mode?

[magiblot]

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.

[unxed]

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

[unxed]

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

[unxed]

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

[magiblot]

AQAmAAAAIAEAAAAAAABr

That's a FARTTY_INPUT_KEYUP event.

[magiblot]

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.

[unxed]

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

https://user-images.githubusercontent.com/1151423/211117621-78128a0e-0dc3-4b68-bf98-4f112c420c6e.mp4

[magiblot]

Damn it.

[unxed]

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

[magiblot]

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.

[unxed]

@elfmz maybe you can suggest something?

[unxed]

Bug not reproduced any more, thanks!

[magiblot]

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).