TERM_PROGRAM is not set to 'WezTerm' in root shells

eugenesvk commented 1 year ago

What Operating System(s) are you seeing this problem on?

macOS

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

wezterm 20230212-103106-a5c2b1f3

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

I'm using $TERM_PROGRAM to detect if I'm running in a WezTerm terminal, and while testing discovered that in root shells this variable is not set

To Reproduce

Print $TERM_PROGRAM before and after entering a root shell

$ echo i=$TERMINFO, t=$TERM, p=$TERM_PROGRAM
i=, t=xterm-256color, p=WezTerm
$ sudo /bin/bash
$ echo i=$TERMINFO, t=$TERM, p=$TERM_PROGRAM
i=, t=xterm-256color, p=

Configuration

None, tested with an empty config

Expected Behavior

Some indication of running a shell inside WezTerm should be available

Logs

Debug Overlay wezterm version: 20230212-103106-a5c2b1f3 x86_64-apple-darwin Window Environment: Mac OS X 10.15.7 (19H2026) OpenGL version: Intel HD Graphics 4000 OpenGL Engine 4.1 INTEL-14.7.28

Anything else?

was testing this a part of trying to add OSC/semantic prompt integration in a shell, and this relies on auto-detection of the terminal to load the relevant terminal-specific integration file I understand setting env var in sudo might be tricky, but don't understand what a good workaround would be

wez commented 1 year ago

I don't view this as a bug so much as it is a side effect of local policy/configuration.

I think manipulating the sudoers config is a bit fraught with peril, especially on macOS where the system doesn't provide a means for this to happen safely (there's no official package manager) and we're at the mercy of whatever installation method the user has selected.

In addition that won't help with the same sort of situation arising on a remote host where it may not be feasible to install any wezterm packages.

What I think may be the way to address this situation is to probe to see if wezterm is present.

https://github.com/neovim/neovim/issues/21699#issuecomment-1375682786 discusses a way to ask the terminal to see if it is a wezterm:

; printf "\e[>0q\e[c" ; od -c
^[P>|WezTerm 20230209-125651-51e0c1b3^[\^[[?65;4;6;18;22c

It is important to send both of those escape sequences as not all terminals will respond to the first one, but all of them will respond to the second one. Sending both means that you can safely do a blocking read and then decode the response.

eugenesvk commented 1 year ago

Reading a bit through the issue, am I correct that there is also another (which seems to be a a cleaner) alternative: setting $TERM=wezterm and installing the WezTerm's terminfo file on a system. As far as I understand, this variable is exported properly to the sudo context as well, at least the rudimentary test in this issue seems to be passing now

Is there a way to put a config in wezterm so that it always sets this $TERM variable to wezterm? Is there any other downside besides having to have this terminfo file installed?

Also, I'm a bit confused by the suggested alternative: how do I actually capture this output to search whether 'wezterm' is in it, but without printing anything to the user?

wez / wezterm