Cannot input command once in full screen interface

[gloria-ho]

After using the goto command to enter the full screen interface, I'm unable to input commands. I can't escape, so I'm forced to close the terminal I'm running the emulator in.
I'm on macOS (Sonoma 14.4), and I see the same issue in both the mac and VS Code terminals.

When I try to enter a command (d icsf to displace icsf info) and hit the enter key, nothing happens, and the cursor moves back to the beginning of the command line:

When I hit the escape key to try to go back to the zti interface, I get these symbols:

When I hit the delete key to try to delete the symbols, I get these:

[najohnsn]

From your description and the looks of the screenshot, it looks as if zti is not getting your keyboard input. It looks like it is being intercepted and pretty much echoed back to your screen. Is there anything odd about the way you are starting zti?

[gloria-ho]

zti is being invoked programmatically from another program and that is what is causing the issue. When we run zti by itself, it works as expected.

[john-craig]

Here's a rough psuedo-code of what we're doing to cause this:

my_zti = Zti()
ati.set("SESSION", "OPERATOR")
my_zti.cmdloop()

This sequence works fine on my machine but puts Gloria in a state where inputs do not seem to work correctly.

[najohnsn]

There are various ways that programs can access "the terminal". Zti uses sys.stdin and sys.stdout. The expectation is that those are associated with the controlling terminal. And they are typically file descriptors 0 and 1, respectively. You may want to check that any code that runs before you use Zti isn't manipulated them. If necessary, you can pass in files for stdin/stdout when creating the Zti object.

[gloria-ho]

We were able to determine that input from the user is being received by tnz's terminal library by adding some code to print out the characters received by the getkey command in _termlib.py. Based on the character codes received, _termlib.py is receiving the correct input but the behavior is still unexpected with most control characters such as escape and enter not being interpreted correctly. Attached is a screenshot of what this looks like with the printed characters in the terminal below.

[najohnsn]

Great investigation!

But I don't think those codes look right. The text looks right. But I think your [Enter] is sending 0xa (\n/LF) according to your screenshot. I expect it to send 0xc (\r/CR).

I haven't looked at the stty setting in a while, but I think it means that there is something weird about either your incrnl or ocrnl setting. Here is mine:

$ stty -a
speed 38400 baud; rows 51; columns 209; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

[najohnsn]

Sorry... the stty output in the previous comment isn't as interesting as I intended. Because zti will change those settings when in "full screen" mode. After changed, mine look like this:

speed 38400 baud; rows 67; columns 209; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

Windows is special, but on other platforms, functions in the Python tty package are used to set the tty up like that. And there is specific code in tnz to ensure that icrnl is not set.

Given what you said about being driven by another program... could it be that there are two tty's involved? One original given to the program and one created by the program? The 2nd would be the one controlled by zti. But zti would not know about the first. If the first has icrnl set, the enter key \r would be converted to \n by the original tty. If that were then passed to the 2nd tty, it cause what you are seeing. When a program is such an intermediate, it should set the original tty to raw mode ... but maybe that isn't happening?

There is also a potentially relevant note about ICRNL in the Python doc for tty.

[john-craig]

Did you retrieve the information in the second post by just running the stty -a command after Zti exits?

We're working on gathering that information in Gloria's environment so that we can compare.

[najohnsn]

Did you retrieve the information in the second post by just running the stty -a command after Zti exits?

No. I added code to zti to do os.system("stty -a > stty.txt") while in full screen mode.

[najohnsn]

Is this still being looked at? Or can this be closed?