I am programming in Linux using ncurses. When I use attron() to switch on attributes, it works for all attributes except A_DIM (which is meant to yield half bright characters). A_BOLD, A_ITALIC, A_BLINK, A_UNDERLINE, A_STANDOUT - all of these have effect, but A_DIM has no any visible effect at all, no matter if I use console or xterm. What might be wrong with that?
It depends on the actual terminal, and on the terminal description used. For the latter, you can see immediately if it is provided by looking at the output of infocmp, e.g.,
# Reconstructed via infocmp from file: /usr/local/ncurses/share/terminfo/x/xterm-new
xterm-new|modern xterm terminal emulator,
am, bce, km, mc5i, mir, msgr, npc, xenl,
colors#8, cols#80, it#8, lines#24, pairs#64,
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=^M,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
XTerm provides all of the video attributes (though "dim" and "italics" are relatively recent):
Linux console provides some attributes (dim for example), but not underline or italics (it uses color). The usual Linux console terminal description does not include "dim", since that has some caveats:
These screenshots use the main ncurses test-program, named ncurses (see webpage and source).
Related
Python 3.7, on Windows print does not work as expected for ANSI color codes until shell=True once in subprocess.call().
In the below links it appears to imply that the ANSI color codes should work using the "print" command out of the box.
How to print colour/color in python?
Print in terminal with colors using Python?
the second one mentions VT100 emulation... not sure what exactly that means. I am able to write a batch file that outputs the color fine so I would think (naively) that it should work the same way in Python.
However I am not able to use the ANSI color codes as it seems that the ESC character is being "commented out"(?) because for instance when I
print(u"\u001b[31mHelloWorld")
I am not able to see the colored output, as the ESC character seems to be necessary in Windows and prints in the python shell as "[?]" (a box with a question mark)
Is there something I am missing here?
I found myself an answer. As often happens I just did not look far enough.
the Colorama module can be installed with
py -m pip install colorama
and comes with a method definition at the root of the module called init
colorama.init()
This is a cross platform function in that it is only useful on windows (it saves the active Terminal state for reversal and writes the Terminal to preprocess ANSI codes), it does nothing for other operating systems.
I am thinking about implementing an even more lightweight solution using ctypes and setting the Interpret flags on the active terminal myself.
If you are interested in more information, see here:
https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
Output Sequences
The following terminal sequences are intercepted by the console host when written into the output stream, if the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag is set on the screen buffer handle using the SetConsoleMode flag. Note that the DISABLE_NEWLINE_AUTO_RETURN flag may also be useful in emulating the cursor positioning and scrolling behavior of other terminal emulators in relation to characters written to the final column in any row.
Emphasis mine.
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.
I've created a couple of very simple bash scripts for a home-made games arcade (input configuration, updating stuff etc). I've got a launcher, so it's not a problem to direct the user to run the wanted shell script, but while running a bash script functionality-wise gives me everything I need, the default low-res text-on-black look scares the end user.
What is the simplest way to "prettify" fullscreen shell scripts? Something that'll run the script in 1080p, use bigger bubbly antialiased fonts, add a fancy animated background etc., but still pretty much lets me stick to write good-old shell scripts?
I guess another way to ask is: Does a prettier, more modern GUI-looking alternative to whiptail exist?
I am running from the terminal, so the GUI library it would have to be as fully self-contained as possible.
The ability of a shell script to display a quit within the terminal window itself is limited entirely to the graphical capabilities of the terminal (and to what termcap/terminfo has support for).
Most terminals max out at 256 colors (though supposedly konsole has support for arbitrary RGB colors somehow).
Control over font sizing/etc. from the shell is limited to the escape sequences that the terminal is willing to respond to (and I don't know if those are at all standard or discoverable at runtime).
The best option for this might be to have your script re-exec itself in a new terminal window to which it passes appropriate arguments to control font selection, window geometry, color selection, etc.
That being said even reliably doing that isn't necessarily the easiest thing in the world (I'm not sure how portable the command line options are between different terminal emulators or how many more advanced features they expose).
You could use python with the library Gooey that makes easy to turn CLI applications to GUI:
It can be customized and it takes only one line for the magic to happen:
from gooey import Gooey
#Gooey <--- all it takes! :)
def main():
# rest of code
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.