-
Notifications
You must be signed in to change notification settings - Fork 53
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
Don't override TERM #23
Comments
simply put, setting For example, when I'm running in the framebuffer console this propmt would set my TERM to something completely incompatible. as for screenshots, here is my case with but when That's a relatively small issue, there are other visual bugs when the terminal capabilities aren't properly read.
Not sure what your environment's issue is. It might be missing/invalid/outdated terminfo db. Or maybe something is setting Tmux specifically recommends:
(emphasis mine) If you want to set set -g default-terminal "tmux-256color" And if you really need to override alias tmux='TERM=xterm-256color tmux` Or, at the very least, your overriding |
@qubidt Thanks a lot for explain. I see it maybe cause some problem, but those details seems not a "case" ? Honestly, I still don't know what really usage scenarios problem that set Such as the |
Sorry, I'm not explaining myself well.
But to give a more straightforward example. Consider: I want to bind the When you press You can see that matches zsh's $ printf '%q\n' TERM=$TERM F1=
TERM=xterm-256color
F1=$'\033'OP xterm will send $ bindkey -s ${terminfo[kf1]} 'echo working!\n'
$ ###press F1 here
$ echo working!
working! no matter which terminal you are using, the keybind will work because it is specified against rxvt-unicode uses a different escape code for $ env | grep TERM; printf '%q\n' F1=${terminfo[kf1]}
COLORTERM=rxvt-xpm
TERM=rxvt-unicode-256color
F1=$'\033'\[11\~
$ bindkey -s ${terminfo[kf1]} 'echo working!\n'
$ ###press F1
$ echo working!
working! everything still works because zsh can read the escape sequence from However, when zsh sees $ env | grep TERM; printf '%q\n' F1=${terminfo[kf1]}
COLORTERM=rxvt-xpm
TERM=xterm-256color
F1=$'\033'OP
$ bindkey -s ${terminfo[kf1]} 'echo working!\n'
$ ###press F1
$ this is just one symptom. even if $ infocmp xterm-256color
# Reconstructed via infocmp from file: /usr/share/terminfo/x/xterm-256color
xterm-256color|xterm with 256 colors,
am, bce, ccc, km, mc5i, mir, msgr, npc, xenl,
colors#0x100, cols#80, it#8, lines#24, pairs#0x10000,
...
$ infocmp rxvt-unicode-256color :(
# Reconstructed via infocmp from file: /usr/share/terminfo/r/rxvt-unicode-256color
rxvt-unicode-256color|rxvt-unicode terminal with 256 colors (X Window System),
am, bce, bw, ccc, eo, hs, km, mc5i, mir, msgr, npc, xenl, xon,
btns#5, colors#0x100, cols#80, it#8, lines#24, lm#0, ncv#0,
pairs#0x7fff,
...
$ ls -lah /usr/share/terminfo/*/* | wc -l
2825 let me know if that makes sense, or if I misunderstood your question |
@qubidt Thanks for explaining so many details~ Maybe I need some to understand all about |
Happy to help! Unfortunately, doing Don't worry about me, though, I already patched this script in my local environment. I just wanted to make you and any other users aware, in case anyone else ran into similar issues. |
@qubidt I'm sorry about this. Could you show some fragments of .zshrc configuration which you used for me, to reproduce the problem? |
Is this what you mean?
Sourcing |
@qubidt Is this appropriate? # the default `TERM`` in `screen` command is 'linux' which will cause colorless in terminal,
# so set it with a compatible colorful value,
# otherwise shouldn't override TERM because it maybe a specific user setting.
if [[ ${TERM} == 'linux' ]]; then
export TERM=xterm-256color
fi Update in v2.3.1. |
Exporting
TERM
here is unexpected and causes issues when there's a mismatch between the capabilities ofxterm-256color
and your actual terminal. e.g. I expected$terminfo[fsl]
and$terminfo[tsl]
to be available for iTerm/Alacritty, but it's not available because my environment thinksTERM=xterm-256color
jovial/jovial.zsh-theme
Line 33 in 0bb2bab
The text was updated successfully, but these errors were encountered: