This is a very specific issue but, based on what I've seen online, a surprisingly common one. I'm on a rather old version of Scientific Linux 5, which is based on Red Hat. I use vim with the Solarized vim color scheme, and my TERM environment variable is usually set to xterm-256color. This worked fine until I started using tmux. On non-empty lines in vim, the color scheme only extended to the end of the document's characters, the remaining whitespace being plain back background.
The stock fix for this in online guides is to set TERM='screen-256color'. However, upon doing this I would get the ominous warning: WARNING: terminal is not fully functional - (press RETURN), when trying to do innocuous things like read man pages. However, everything seemed to be working fine, and the Solarized bug was fixed.
I've found a functional fix - using TERM='xterm-256color' by default and adding this line to my .bashrc:
alias v='function _vim(){ TERM='screen-256color'; vim $1; TERM='xterm-256color'; };_vim'
but it seems like a hack. Anecdotally, I've also set alias tmux='tmux -2', which is a common suggestion with color-scheme-related issues.
I also know that the terminfo screen-256color is available on my machine.
So, really, the main befuddling thing is that, when using TERM='screen-256color', I'm getting those warnings about full functionality when nothing seems to be wrong.
I don't have root access, so ideally any fix suggestions wouldn't need that.
EDIT: I should mention that TERM='screen-256color-bce' gave the same problems as TERM='screen-256color'.
The user's environment is not specified, but likely using bash and less (Scientific Linux 5 does not have more).
The package list on Scientific Linux 5's ftp site, shows ncurses-5.5-24.20060715.src.rpm, which does not include screen-256color (it was added to ncurses in October 2006). That system might have the later terminal database by some post-install change.
An application using termcap would not see this terminal description. Scientific Linux's bash and less programs could have used termcap rather than terminfo. A quick check of the changelog for bash-3.2-21.el5 says
* Fri Feb 1 2008 Miroslav Lichvar <mlichvar#redhat.com> - 3.2-21
- Link with libtermcap
On some systems, a missing termcap entry will cause a warning. But with Scientific Linux 5, the given warning message comes from less, which checks its terminal description (using the termcap interface), to ensure that it can clear the remainder of the current line, the remainder of the screen and the entire screen.
In Scientific Linux 5, the less package is built with ncurses. A problem with less using TERM=screen-256color would be one of these possibilities
the screen-256color entry is not really installed, or
there is some problem with the termcap interface provided by ncurses.
While there were ongoing performance-fixes for the screen program around this time, the former seems the more likely, as seen in this discussion of a poorly-written entry for screen-256color in early 2006: Re: screen-256color terminfo entry?. What I get from reading this is that there was some poorly-written terminal description (not part of ncurses) which produced the problem. By the time it was proposed for inclusion in ncurses (October 2006), the problem had been repaired. In any case, it would have been corrected at that point.
Related
I am looking to implement a remote client in golang which connects to Linux through nc and starts bash. So I need to tell bash what features I can parse from the stdout that it sends to me, and how I am going to send keycodes and other stuff to its stdin, so that it could parse them too.
This is done with TERM=something environment variable, which I need to set to some value. If I don't set it, then various programs start to complain:
$ mc
The TERM environment variable is unset!
I found that I can set TERM to dumb to say that my client is really limited. And still it seems that I am missing something.
$ export TERM=dumb
$ mc
Your terminal lacks the ability to clear the screen or position the cursor.
From here it looks like dumb terminal don't have these two abilities, but what abilities it is still expected to have? Is there a specification or some de-facto standard about it?
Going to the source can help. The terminal database has comments. Here is a slice from that:
#### Specials
#
# Special "terminals". These are used to label tty lines when you don't
# know what kind of terminal is on it. The characteristics of an unknown
# terminal are the lowest common denominator - they look about like a ti 700.
#
dumb|80-column dumb tty,
am,
cols#80,
bel=^G, cr=^M, cud1=^J, ind=^J,
unknown|unknown terminal type,
gn, use=dumb,
The "dumb" and "unknown" terminal types are assumed, but rarely used:
"dumb" has automargins (text "wraps" at the right margin), is assumed to have 80 columns, and an ASCII BEL and carriage return. For lack of something better, cud1 (cursor down) is an ASCII line-feed. The ind (index) value is the same, implying that text scrolls up when you reach the bottom of the screen.
There is no cursor-addressing (cup) nor alternates (such as moving along a row or column arbitrarily).
"unknown" adds the "generic" flag, which marks it as unsuitable for use by curses applications. Think of it as a printer.
As for minimum requirements, that actually depends upon the individual application. ncurses can manage to move around the screen without actually having cup. It works with a half-dozen strategies. If you read the source for mvcur, you can get an idea of what it needs.
However, applications such as mc do not simply rely upon ncurses to decide if it works, since (in this case) it may link with slang (which doesn't check that closely). So mc does its own checks, which may add restrictions.
In practice, unless you choose a limited terminal description such as "dumb", most of the terminals you are likely to encounter will work.
Further reading:
terminfo - terminal capability data base
curses interfaces to terminfo database (including mvcur)
ncurses/tty/lib_mvcur.c
Your best source of information will be the terminfo entry, easily viewed with the infocmp tool:
infocmp dumb
# Reconstructed via infocmp from file: /lib/terminfo/d/dumb
dumb|80-column dumb tty,
am,
cols#80,
bel=^G, cr=^M, cud1=^J, ind=^J,
which makes it pretty clear that the dumb terminal is quite limited ...
I'm trying to make a bash script that behaves differently based on the terminal program that someone is using (Putty, mobaxterm, etc). Is there any way to retrieve this kind of information from a bash script?
I was searching around online but I was not able to find anything (or I'm just wording it incorrectly, which could be a distinct possibility).
thank you
You need to understand that these are terminal emulators. There is a simple, crude identification function for (most?) modern line terminals (now that's an oxymoron!) but it will return something like vt102 or xterm i.e. whatever the emulator is emulating; not the identity of the program performing this emulation. Incidentally, this is usually used when the session is initiated, and reflected in the value of the $TERM environment variable.
The common way to do this is the environment variable TERM. Try
echo $TERM
That should output the terminal emulator's type, indicating its capabilities. Often, though not always, the value of TERM will be the name of the terminal emulator. For example, xterm may set TERM to xterm, or to xterm-color, depending on configuration.
Note that the user can change this variable, so it may contain something completely different.
That said, if you want to do fancy things with the terminal from a script, you don't need to build support for different terminals by hand. There are various libraries that offer all the usual functions (clear terminal, resize window, change font etc.). The most popular one is terminfo; there are various packages that build on terminfo.
when I sshed into another machine in xterm, the character I deleted by either backspacce or ctrl+k, remains on the screen. but physically they have been deleted, as when you exectue the script, the machine responds in a way that the delete has conducted. The only way to display properly is to let the cursor moving through the deleted words, either by space or typing other characters.
Same thing applies when you using vim. specifically after page down, the screen displays a overlap between the previous page and current page.
The screen displays properly without ssh.
I am using gentoo with the following compile flag (if it is related).
[ebuild R ] x11-terms/xterm-314 USE="openpty truetype unicode -Xaw3d -toolbar" 0 KiB
Sounds like a locale problem. Some Linux's by the way honor an stty -iutf8 setting, and others may not. Either that, or a difference in locale settings on the local and remote machines is the first place to check.
Thomas's answer led me to a solution for this very same problem. My LANG environment variable was incorrectly set on my local machine. For my case,setting LANG=en_US.UTF-8
fixed the problem.
This is related to debugging the issue mentioned in: Plugin (vim-latex) crashing gVim on startup
After installing latex-suite, every time I open a .tex file, whether it's from gVim or terminal vim, whether it contains a \begin statement or not, Vim immediately crashes.
After repeatedly making it crash I was able to read a Python Traceback string in the status line, which mentioned line 530 in C:\Python27\lib\site.py (which only contains known_paths = addusersitepackages(known_paths)), but the rest of the traceback is not viewable since the statusline display truncates it and this only appears for a moment anyway before automatically crashing.
Is there a way I could capture this Traceback output in a more permanent and complete way, along with how things go from this plugin to Python, etc.?
(I tried the -V15filename.log option but it's (as usual) useless, containing some partial log upto an ancient point in the vim startup process.)
Edit: Apologies for not mentioning the OS previously (other than indirectly through the C:\ path), this problem is on Windows. And from the other linked question it seems like almost everyone who tries latex-suite on Windows runs into this problem.
Update: Just a FTR - setting verbosefile doesn't help (presumably because the writes are buffered per the doc), and :redir doesn't capture this either, ends with whatever operation happened before this error and crash.
OK, I put here as an answer.
This answer could be kind of work around for solving your latex plugin problem in windows vim. However if your question sticks to "getting error message before crashing" , it may not give you help. I don't have much experience with windows OS.
Latex Suite plugin uses python to generate some formatted text. It could bring better performance. However the plugin provides no-python ways for that as well, to let user without installing python runtime or with very old python version use the plugin too.
Since you mentioned that your problem was in python codes. You can try disabling python in that plugin, and test if the performance was acceptable.
The plugin provided a variable for that, you could add this line in your vimrc
let g:Tex_UsePython=0
Nice to see it helped.
Did you try to run with redirected stderr?
vim file.tex &> errors.log
or
vim file.tex 2> errors.log
1) If you are able to compile Vim from the source (using MinGW as you are on Windows), you could run it with gdb. Then you could set some breakpoints/check the stack trace until you detect a line near the crash. The instructions to run Vim with the gdb and read the stack traces are found in :help debug-gcc.
At the end of that help file (:help get-ms-debuggers) you can find instructions on how to obtain some debug tools for Windows.
These tools can be used on the following alternatives, explained in detail on :help debug-win32:
2) In case you didn't compile Vim, obtain the debug symbols (PDB), which should be available from the same place that you obtained the executable. Attach Visual Studio to the Vim process, reproduce the crash, then read the stack trace through Visual Studio's dialog reporting the crash.
3) Same as 2) but using WinDbg instead of Visual Studio.
4) Inspect the Minidump file, in case your crash generate one. In addition to the referenced help section, you may find useful information on the following links:
Where to find mini dmp files in windows 7
How to read the small memory dump file
In case you are on a computer running linux, did you try saving the strace output in a file?
strace gvim -V9log.txt file.tex > stdout.txt 2> stderr.txt
And then having a closer look at the output files, especially the last 10-100 lines? I am not sure if it will capture the system calls of the plugins though, but it could be a starting point.
I'm trying to setup vim on windows to work like it does in Linux. Basically, when I type ":make" in linux, I get the output of makeprg sort of streaming through vim itself.
On windows I get a cmd prompt that comes up, but behind vim. I have to switch focus to view the results until they are finished and then they can be viewed in the quickfix window.
I attempted to download a copy of "tee" and set shellpipe to |tee, but that didn't really change anything. Below are the sort of relevant settings in my vimrc, I use ninja, but the same happens if I switch to nmake or something similar.
set makeprg=ninja\ -C\ build-ninja
set shellpipe=2>&1\ \|tee
set efm+=%Dninja:\ Entering\ directory\ `%f',%Xninja:\ leaving\ directory
I think this is related to what you want, but provides only for a partial solution, because it will not wait until the program has finished running:
set makeprg=start\ /min\ ninja\ -C\ build-ninja
Getting it to work will not be trivial (see comments), it seems like an important oversight of the Windows version of Vim, because start cannot be executed from makeprg (see comments), only the internal (and more limited !start).
The full documentation of the start program (which it seems you would need to somehow invoke) you can find in this question