When the Terminal is invoked for a defterm connection, cmd.exe is already running. The defterm scenario is never going to work with WT_SESSION. The idea there is that if WT eventually supports reloading and showing a session's history, that resumed state will use the same session GUID so the shell can do additional things like restoring the working directory or anything else it might have saved off. This feature was inspired by both Terminal.app (the stock terminal emulator on OS X) and its featureful replacement, iTerm2. WT_SESSION tags an individual session - it is a GUID that the shell (or some other enlightened application) can use in coordination with the terminal to support application state resumption. It is informative, not normative, as a detection mechanism. Today, it can be used to detect Windows Terminal.
What does it do? Who is expected to use it, and for what? Unfortunately, TERM has become somewhat like a user agent: "I work like this terminal, I promise" - right up until it doesn't. We should definitely support TERM or TERM_PROGRAM. Hold up, I think there's been a misunderstanding here.
0 kommentar(er)
