echo TTY mode disabled for launched processes

[andyleejordan]

Similar to #15991, if Console.ReadKey() has been used by a .NET program, the echo TTY mode is disabled. To resolve the prior issues, dotnet/coreclr#2561 re-enabled the echo mode on program shutdown.

However, we've run into a different scenario: launching a process from the .NET program inherits the TTY modes. So if you launch Bash from the .NET program, you can't type in it until you've explicitly re-enabled echo.

[stephentoub]

@andschwa, can you share a small C# repro we can use to confirm the problem and verify when it's fixed? I tried:

var p = Process.Start("bash");
p.WaitForExit();

but I can type fine in the launched process.

[stephentoub]

@pallavit, once @andschwa provides a repro, could you take a look at this? My guess is we need to change how we handle initializing/uninitializing our terminal attributes, and that we need to reset the attributes in response to a variety of signals. For example, rather than only setting the attributes at start and unsetting them at exit, we could handle signals like SIGTTOU, SIGTTIN, etc., setting the attributes back to the original values, and then the next time I/O is performed, re-call our initialize operation to set the attributes back. Or something like that. Related, we don't do a good job today with a console app that's been put into the background, as our read operations trigger EIO errors (see the man page for read for details)... for example, try creating a simple C# app that sits in a Console.ReadLine/Console.WriteLine loop and then launch it as a background process.

[pallavit]

@stephentoub Sure, I will take a look. @andschwa Please share a repro.

[andyleejordan]

This repros with the internal project you should both have access to; however, I understand the additional amount of complexity involved with said project. I'll assign one of our contractors to debug this until we can repro outside said project.

@palladia Pulling you into this discussion, I've assigned our linked issue to you. In order to fix this, the CoreFX team needs a repro outside our project.

[andyleejordan]

@pallavit This gist reproduces what we're seeing.

If Console.ReadKey() or Readline() are used, then any subsequent invocation of interactive processes (like Bash) will still have the ECHO TTY mode disabled.

So for our project, if you try to launch Bash, you can't actually use it (until you've executed stty echo to turn it back on).

Thanks for the repro @palladia.

[andyleejordan]

@stephentoub Any movement on this? It makes self hosting a bit of a pain.

[stephentoub]

@stephentoub Any movement on this?

This is assigned to @pallavit.

[pallavit]

@andschwa I have not had a chance to look at this yet as I have been busy with some feature work. I will try to get to this ASAP.

[andyleejordan]

Just checking, thanks guys!

[andyleejordan]

Along a really similar vein, when most interactive apps are run and then closed (say, Vim), Console.ReadKey() no longer recognizes the arrow or home/end keys, and instead reports letters: "A, B, C, D, 1~, 4~" for "Up, Down, Right, Left, Home, End".

If this isn't System.Console, then it may be our own use of it, and we'd appreciate any pointers to debug it.

I've verified that TERM remains xterm and stty -a emits the following both before and after an interactive application is launched and closed and the problem manifests:

speed 38400 baud; rows 59; columns 190; 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; flush = ^O;
min = 1; time = 0;
-parenb -parodd 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

[stephentoub]

no longer recognizes the arrow or home/end keys, and instead reports letters: "A, B, C, D, 1~, 4~" for "Up, Down, Right, Left, Home, End"

This is likely very related. We likely need to handle some of the signals I mentioned, and potentially SIGCONT, to redo some of the initialization previously done, including re-sending KeypadXmit: https://github.com/dotnet/corefx/blob/master/src/System.Console/src/System/ConsolePal.Unix.cs#L618.

[andyleejordan]

Going to add another, related, thing
Comment moved to new issue dotnet/corefx#6377

[stephentoub]

I'll take a look at this one, Pallavi. Thanks.