Identifying the editor running a program

Editor/IDE Integration
1

I can’t speak from the point of view of editors/IDE but this seems to be a good idea.

For my purpose, I’d be interested in the reverse information, that is identifying which editor/IDE is used to run a program. The following is the heuristic I am using, but do not know how reliable it is.

if "TERM_PROGRAM" in os.environ:  # used by VS Code
    terminal_type = os.environ["TERM_PROGRAM"]
elif "TERMINAL_EMULATOR" in os.environ:  # used by PyCharm
    terminal_type = os.environ["TERMINAL_EMULATOR"]
elif "TERM" in os.environ:  # Unix?
    terminal_type = os.environ["TERM"]
elif sys.platform == "win32":
    # The following might not be reliable.
    _ps = len(os.getenv("PSModulePath", "").split(os.pathsep))
    if _ps == 3:
        terminal_type = "powershell"
    elif _ps == 2:
        terminal_type = "cmd"
    else:
        terminal_type = ""
else:
    terminal_type = ""
2

This seems a bit orthogonal to the inverse information discussed here…but I am curious, what is your use case for this?

3

Well, at a minimum, the check that PSModulePath has exactly 3 entries is wrong. I’m on Powershell and I have 5 entries in that variable. And if I open a cmd prompt, it has 3 entries.

1 Like
4

Thanks for that info; I got this from a stackoverflow question and it worked for me. I’ll have to find a more reliable way to get the information.

5

I have a program that sets up a custom exception hook and provides additional information. Depending on the interpreter (for example CPython and IPython), the exception hook has to be set up differently. The output is themeable for enhanced readability, depending on the background colour of the environment in which it is run. The language in which the information can also be changed.

For a given running environment (terminal type, IDE, and possibly browser [for Jupyter]), and a given interpreter, usually the theme will be different; Once a user sets up preferences, I store the user’s preference based on the interpreter and running environment so that it does not have to be set explicitly at the start of each session. To do so reliably, I need to figure out the environment in which it is run.

In addition, I found that running IPython in PyCharm in the debugging mode (which uses Pydev) does not play nicely (yet) with my program. In other cases (running within IDLE), based on the python version used, some features are not directly available and I need to implement workarounds.

So, for greater reliability, I need to have accurate information about the Python version used and the environment (including editor/ide) in which it is run.

6

PowerShell and CMD are shells, not terminals. The system terminal in Windows is “conhost.exe”. (Prior to Windows 7, the console host was a loaded module in the session server, csrss.exe.) In Windows 10+, Microsoft’s “Terminal” app improves and extends the builtin terminal capabilities of conhost (e.g. automatic font fallback and rendering of non-BMP text). There are also popular alternatives, such as ConEmu and mintty.

For conhost, what matters most is whether it’s in virtual-terminal mode or classic console mode. VT mode can be enabled or disabled via SetConsoleMode(). By default it’s initially disabled in a new console session, but this can be changed by setting the registry REG_DWORD value “VirtualTerminalLevel” in “HKCU\Console”.

A pseudoconsole (headless) mode is also supported, which has the console host act as a middle man between client applications and a terminal. A pair of pipes is used to communicate between the console host and the terminal. For example, conhost serializes changes to its screen buffer as a stream of text and VT sequences written to the output pipe, which the terminal can process or render in a window or tab. Some behaviors and supported capabilities may be different when conhost is in pseudoconsole mode. In particular, most registry settings in “HKCU\Console” are ignored in pseudoconsole mode, and VT mode is enabled by default.

The source code for conhost is open sourced in the Terminal repository. (The condrv.sys console I/O driver and client-side console API, however, are not open source.) Terminal Preview has the latest version of conhost, distributed as “openconsole.exe”. As currently designed, every tab in Terminal is a pseudoconsole session that’s hosted by an instance of openconsole.

7

Sorry, “terminal” is just a generic variable name I use inside my program; I just copy pasted the code I have there.