Hi Thomas,
On 2025年8月16日 13:22:35 +0200
Thomas Wolff wrote:
There is an weird interworking issue when launching WSL from a minimal
standalone installation of cygwin.
(It can be reproced with a full installation, though, see below).
When calling Windows-native wsl.exe, as implicitly done via mintty
--WSL, and there is no terminfo database installed, something fails
about pty setup, and the WSL shell will be run in pty-less mode (no
prompt, no stty signal handling, ^C terminates the shell). When
terminfo
is present, everything works as expected.
Test case:
remove /usr/share/terminfo/78/$TERM (xterm or xterm-256color, or the
whole subdirectory, or the 6d or 76 subdirectories when using
TERM=mintty* or vt settings), i.e. move it to some saving place.
Run mintty --WSL, observe the issue described above.
Interestingly, cygwin shells are not affected by the issue, so some
obscure interworking of the dreadful Windows ConPTY layer or so might
contribute to the issue, but in any case I doubt that the presence of
terminfo should affect the effective pty behaviour.
ConPTY assumes xterm sequences unconditionally and use CSI 6n at the
startup. If the terminal does not support CSI 6n and no responce from
the terminal, CreatePseudoConsole() hangs. So pty checks terminfo to
determine whethter ConPTY can be used.
If the terminal does not support CSI 6n, pty does not use ConPTY for
non-cygwin app like WSL. In this case, the stdin/stdout is just a
pipe for WSL, so shell does not shows prompt. However, the shell
itself is running, so the command should be accepted. Please try
to type ls, ps and so on.
I understand the behaviour of cygwin1.dll should not depends on
the terminal aspects, however, ConPTY forcibly uses xterm sequences.
So this is a desperate measure.