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 ...
Related
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.
I want to know if anyone does know a way to dump or copy the whole lot of viewable messages in a xterm window on linux. The very important thing is I don't want to know how to send a command out and kapture its output for stream 1 and 2 as well as the input, as this is well known to me.
I may explain for what this is needed. You do something and expect not any complications but than you got pages of msg's als err msg or normal output. To be able to see later after it you should be able to get them in a file and as long as you are able to scroll that all back and forther with your mouse it is sure the data is there some where. But the time may be not to scroll and screenshot and scroll ....
I would be glad to help me out in such cases and it would be fine to have the full view including all your own typing and all the msg's in same order as you watch it when you scroll it back.
I don't really know where this is stored and how you could get that saved. I know that I could dump the whole lot of Memory and search it for a part of the xterm window, but that is a bit over the top I think.
There is a control sequence, which I had forgotten. This question reminded me. In XTerm Control Sequences, it is noted "print all pages":
CSI ? Pm i
Media Copy (MC, DEC-specific).
Ps = 1 -> Print line containing cursor.
Ps = 4 -> Turn off autoprint mode.
Ps = 5 -> Turn on autoprint mode.
Ps = 1 0 -> Print composed display, ignores DECPEX.
Ps = 1 1 -> Print all pages.
That dates from 1999 (patch #119), so you likely have it in your xterm. You could do this in a shell command like this:
printf '\033[?11i'
A comment mentions the page Hidden gems of xterm, which uses the corresponding action print-everything (something that can be executed via the translations resource). It is in the manual page, of course. The same comment points to Extra characters in XTerm printerCommand output, which mentions the resource printAttributes. By default, the control sequences for the printer tell xterm to send extra control characters (to reconstruct video attributes). The resource can be modified (set to 0) to suppress that. That is even older (patch #74).
Without that — Conceivably one could construct an application which used the X SendEvent protocol to construct a series of events which would be interpreted as xterm actions to scroll back, select text and copy it chunk-by-chunk via the clipboard. You could even write it in Perl (there is a module for X protocol). But seriously, no.
If you want to capture text which was written to xterm, you can do this by preparing before the text is needed by different methods (see manual):
turn on the xterm logging feature (not that user-friendly because it generates the filename). This can be enabled using the "Log to File (logging)" menu entry.
use the printer control sequences to write lines as they are written (again, not that friendly, though there is a menu entry to turn it on and off, "Redirect to Printer (print-redir)")
use script to capture all output to the terminal. I use this, because it works with any terminal on any POSIX-like system (even Cygwin).
Each of these methods produces a file containing escape/control sequences, which requires filtering out. The hypothetical program using SendEvent could in principle eliminate that.
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.
I can scroll trough bash output using shift+pgup/pgdown.
But lets say, some command outputted lot of text, I have to pageup few times to go to beginning of output of this command.
Can I just simply do this by some shortcut? Something that simply allows me to scroll between previous commands (not history!), seeing their output.
You could try piping the output into less:
someCommand | less
less will allow you to search and scroll through the output text pretty easily.
once in less you can just type % to jump back to the top of the page. Essentially that means jump to 0% of the page. There are also a bunch of extra commands on the page I linked to above.
Another option is to use screen and use backward search (beware: read the Overview first, especially the part about the C-a prefix) to e.g. search for some specific characters in your prompt (like your username).
The scroll back history in Unix shells is a shell specific functionality, meaning that it is up to the specific shell (xterm, rxvt, text console, etc) to handle it. The functionality you request would require the shell to identify the individual program runs, to know where to scroll to. Scanning text is not technically hard per se, but as prompts and command display can differ due to user settings it can be hard to make it work generally good. Some communication between the shell and the terminal could make it better.
There sure are some nice fancy terminal programs doing things like this, to for example show syntax help when writing commands, but for your case I agree with previous answer, that piping commands to less is a good way to isolate the output. It might be a bit cumbersome first, as it requires you to think about it first, and not just go back in history, but if you learn the shell better and learn to use the command history it will probably work fine. I recommend you to, if you haven't already. What I mean is ctrl-r etc. More described for example here:
http://www.catonmat.net/blog/the-definitive-guide-to-bash-command-line-history/
Warning: you know how they say "there's not such thing as a stupid question"? Well, this one is, or, I suspect it's really minor, but wth, why not ask. Search engines didn't bring me anything remotely useful, though that could be bad searchterm-fu.
I recently downloaded sqlite3 onto Ubuntu 10 to start learning SQL commands. I un-tar'd 3.7.12.01 and make installed.
After creating a test.db with create table test (id) I decided to see what I'd get if I cat it. Just because.
The result is an EOT character (u+0004) which is sitting right over my prompt. Illustrated screenshot: http://imgur.com/omfMa
I realise this is not the type of file you would use cat on. I only want to know, before I go further,
does the strange placement of this character signal any future issues when actually playing around with SQL, or some issue with newlines, or fonts (this is monofur set at a high font size) or similar?
I've never seen a result character placed directly over my prompt before.
The character is placed over your prompt, because it is a double-width character, and terminals in general are not good at handling double-width characters. It does not mean anything.
There are some control codes which can do very funny things with your terminal, such as changing colors, fonts etc.
But none of them do really harm - you should be able to reset your terminal to a healthy state, or close it and open a new one.