Is there a way to use ANSI escape codes inside mvwprintw?
mvwprintw(window, 0, 0,"%c[%dmCOLORED_TEXT!\n", 0x1B, 32);//doesn't work
even though:
printf("%c[%dmCOLORED_TEXT\n", 0x1B, 32); //works
This would be for cases where using wattron/wattroff is not convenient; for example, when redirecting output from stdout of a process that outputs such escape codes.
No. The only way to make that work would be to parse the string yourself, turning escape codes back into the appropriate curses commands, to issue along with your output.
One thing you should realize is that those codes, although widely implemented, are not universal. One of the major purposes of curses is to translate its standard commands into series of terminal-specific control codes. So, passing through codes that may or may not correspond to the current terminal type doesn't really fit the curses model. Even more fundamentally, the codes would change the terminal state in a way that curses wouldn't be able to keep track of, so that the contents of its window structures no longer matched what was on screen.
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 have a Tcl/Tk expect script, and log information is logged to external log file.
I can execute it on Linux server successfully without any wrong, and the log file do not have any weird ^H. But when the script is called by Jenkins job, run on the same Linux server. the log file will have a lot of ^H, And the expect will timeout.
What the possible reason could be?
The ^H is actually the backspace character, U+000008, and it is used in terminals (and terminal emulators) to move the current character insertion position one place to the left. This is used in turn to simulate various kinds of effects, such as making a character bold (by double-striking) or giving it an underline (by putting a _ on the same cell). Think like it's going to a traditional teletype, which prints things into the same position twice. It's definitely a hang-over from
the old days.
It seems that Jenkins (or maybe whatever it is calling, quite possibly maven though definitely not necessarily!) is using that device to back up over what it has written so it can write a new value there instead, probably for something like a simple download progress meter. Things that are writing to what they think is a terminal sometimes do this. You'll just have to cope. A \b in your Expect regular expressions will match it, though it is possibly unwise to do so, as whatever is being overwritten is transient info. If the characters are being written to a file, the col program (part of the nroff/groff suite) can be used to strip them; that might be easier.
Be aware that there are other ways that software can achieve the same effect, such as writing just a carriage return (which puts the cursor back at the start of the current line).
The make files generated by CMake have a colorful output for improved readability.
Is it possible to change the color? I have a green terminal font so I kind of loose the color for the messages indicating that objects are built.
I assume you are talking about the cmake added messages from the make output (and not the normal make output itself) in which case it looks like those lines are hard-coded into the generated makefiles with arguments to the cmake cmake_echo_color command that include literal color names as arguments. So there don't appear to be any variables to override or anything of the sort that would let you change that.
So, no, it looks like you cannot control the colors that cmake uses for its various messages. At all.
It doesn't even get the values it uses to control the colors from your terminal's termcap/terminfo it has hard-coded escape sequences in the source code from what I can tell.
The only think you can do is change your terminal's color definitions.
Edit:
While discussing this with a colleague we came up with a fairly obvious and unsophisticated workaround for this. Create a cmake wrapper script, assign the path to it to the $(CMAKE) variable (the only variable in use on that generated make line) and then your wrapper needs to scan for the -E cmake_echo_color command sequence and replace whatever color the command was going to be using with the appropriate argument for the color you want to use.
The only problem with this approach is that there is nothing in the command line that indicates any category or any of the sort other than the message itself so to do this in anything resembling a coherent fashion is going to require a filtering on (potentially random) message texts.
As of 2022, it still isn't possible to change the colors.
I've filed two bugs about this with Kitware:
https://gitlab.kitware.com/cmake/cmake/-/issues/23277
https://gitlab.kitware.com/cmake/cmake/-/issues/23279
So maybe things will improve like they have for ccmake.
How can you set a string to be used instead of standard input? For example, when running the latex command in Unix it will always find some trivial errors, to skip through all errors you have to enter "r" into the command line (I now know that with latex specifically you can use -interactionmode nonstopmode, but is there a more general solution to do this?)
Is there anyway to specify that this should be done automatically? I tried redirecting standard input to read from a file containing "r\n", but this didn't work.
How can I achieve this?
Not all applications that need input can be satisfied with their stdin redirected.
This is because the app can call the isatty C function (if written in C, or some equivalent call for other languages) to determine if the input come from a tty or not.
In such situation, there is a valuable tool to use, and this is expect.
latex --interaction=MODE
where MODE is one of:
errorstopmode: stop at every error and ask for input
scrollmode: scroll over non-fatal errors, but stop at fatal errors (such as "file not found")
nonstopmode: scroll over non-fatal errors, abort at fatal errors
batchmode: like nonstopmode, but don't show messaes at the terminal
For interactive use, errorstopmode (the default) is fine, for non-interactive use, nonstopmode and batchmode are better.
But beware, there are no trivial errors: all errors must be fixed, and all warnings should be fixed if possible.
Redirecting stdin works without problems here:
/tmp $ tex '\undefined\end' <<< r
This is TeX, Version 3.1415926 (TeX Live 2010)
! Undefined control sequence.
<*> \undefined
\end
? OK, entering \nonstopmode...
(see the transcript file for additional information)
No pages of output.
Transcript written on texput.log.
You've got two plausible answers detailing the way to handle Latex specifically. One comment indicates that you need a more general answer.
Most usually, the tool recommended for the general solution is 'expect'. It arranges for the command to have a pseudo-tty connected for input and output, and the command interacts with the pseudo-tty just as it would your real terminal. You tell 'expect' to send certain strings and expect certain other strings, with conditional code and regular expressions to help you do so.
Expect is built using Tcl/Tk. There are alternative implementations for other languages; Perl has an Expect module, for example.
From the man page:
-interaction mode
Sets the interaction mode. The mode can be either batchmode, nonstopmode, scrollmode, and errorstopmode. The meaning of these modes is the same as that of the corresponding \commands.
Looks like -interaction nonstopmode might help you.