Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TERM_PROGRAM is not set to 'WezTerm' in root shells #3114

Open
eugenesvk opened this issue Feb 15, 2023 · 2 comments
Open

TERM_PROGRAM is not set to 'WezTerm' in root shells #3114

eugenesvk opened this issue Feb 15, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@eugenesvk
Copy link
Contributor

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

@eugenesvk eugenesvk added the bug Something isn't working label Feb 15, 2023
@wez
Copy link
Owner

wez commented Feb 17, 2023

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.

neovim/neovim#21699 (comment) 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
Copy link
Contributor Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants