For reference purposes: I am using a Macbook Pro Retina (2014) and all software is up to date as of the time I am posting this question. (Using OSX 10.10.2 Yosemite)
I have been struggling for the past few days as I attempted to customized the Terminal window. Everything was going fine... until I decided I only wanted to change the color for the text that you are currently typing (text input) which will then be executed.
I have no problems getting into my .bash_profile and adjusting anything. I simply cannot seem to grasp the color concept well enough such that it only does this one thing for me. Currently my .bash_profile looks like this:
export PS1="\n\n\njboned$ "
export PATH="/usr/local/mysql/bin:$PATH"
export CLICOLOR=1
export LSCOLORS=ExFxCxDxBxegedabagacad
Any assistance would be greatly appreciated. As a sidenote: I understand the 8-bit snippets used to represent the individual colors, however it seems I cannot figure out how to use them to address only the text input only.
To do what you are asking, these steps would be needed:
at the end of the prompt, turn on the text color which you want to show
when you press return (to complete editing) turn the text-color off.
bash does not reset attributes while you edit, so the color "should" work — while editing. As you edit, bash is likely to use escape sequences which clear the current line (which may fill it with whatever background color you have selected).
The real problem is how to reset the colors when you press Enter. That does not appear to have a straightforward solution: I do not see a way to rebind the Enter key to add features—no distinction is made between levels of interpretation, and you may not find it possible to enhance the Enter key. The key binding feature in bash talks mainly to the readline library; leftovers are sent to bash. In a binding you may be able to do these things:
send the name of a macro to bash, or a full echo command which resets colors (since readline has no echo of its own, it seems)
the Enter key (i.e., ^M), and
to readline directly, the accept-line function
Alternatively, what you could do is bind another key, say control/L to do the bash accept-line function as well as resetting color. Here are a couple of links which you would find useful to investigate how to do this:
how to bind the 'Enter key'
Complex keybinding in bash
In bash, how do I bind a function key to a command?
Smart preparsing with the bash shell
Related
Several *NIX commands, such as screen, man, vim and others, create a temporary canvas/screen/overlay in a shell environment. When such programs execute, they cover or hide whatever content was displayed in the terminal before — almost like a "full screen" mode, within the terminal window. When they terminate, however, they reveal or restore whatever had been on the terminal before.
In the example below, I create some filler text on the screen, then invoke man bash. The man page opens up and covers all other characters on the terminal display. When I close the man page, the characters that had been covered up are again shown.
Before
While an example full-screen program is running
After
I would expect that programs writing to stdout/stderr could accomplish the first step (replacing the content of the terminal with program-specific content), but then it would produce a ton of text that I could scroll through, and therefore couldn't do the second step: restoring the contents of the terminal. That means that somehow either the program memorizes the previous contents of the screen and re-outputs them (I doubt it?), or it creates some sort of sub-window within a terminal and something else keeps track of the previous contents of the terminal.
My Question
How can I accomplish that behavior in my own program and/or script?
Perhaps I should use curses/ncurses, tput, termcap/terminfo, or ANSI escape sequences?
Update:
This revised question is essentially the same as https://unix.stackexchange.com/questions/27941/show-output-on-another-screen-and-return-to-normal-when-done. (I hadn't found it when I had written this question despite lots of searching.) The difference is that my question is more general (any language) whereas that question is specific to Bash. The answers to both questions are essentially the same. If it's too similar to a question on another site, feel free to close it here for that reason.
How do these programs accomplish that behavior?
ANSI escape sequences. Try running this script:
#/bin/bash -
tput smcup
echo 'Hello world!'
sleep 3
tput rmcup
Using infocmp, you can see underlying sequences that create this overlaying effect, e.g:
$ infocmp -1 | grep 'rmcup\|smcup'
rmcup=\E[?1049l\E[23;0;0t,
smcup=\E[?1049h\E[22;0;0t,
is this behavior shell-dependent or system-dependent?
None, it depends on whether the terminal emulator supports save/restore operations.
I am trying to create a program which will have live updates from some data source. And I also want to wait for user input just like a normal terminal. Right now, whenever there is update, I will print the content and print the prompt message for input again which create something like this:
Enter command >
This is a live update message
Enter command >
This is a multi-line li......
......ve update message
Enter command > quit
Bye bye!
The problem is that for every live message I received, I will print it and the "Enter command >" will be displayed again again and again, which is not desired. I want the live update to be update on the main part of the terminal, while the "Enter command >" always stay at the bottom
The closest package I can found on Github is https://github.com/gizak/termui but most of the examples inside is trying to display text, gauge and graphs. So I am not quite sure how to get started.
Is there any package or example of the termui package to achieve this? Thank you.
With github.com/gizak/termui you're heading in the correct direction.
To understand why you can't get that
I want the live update to be update on the main part of the terminal, while the "Enter command >" always stay at the bottom
part sorted out, a little excursion to the history of computing is due. ;-)
The thing is, the mode your teminal emulator¹ works by default originated
in how computers would communicate to the operator in the era which predated
alphanumeric displays — they would print their responses using a line printer. Now think of it: a line printer works like this: it prints whatever is sent to it on a roll of paper. What was output, was output.
The new output always appears physically below the older.
When alphanumeric displays (screens) came into existence they
naturally continued to support this mode:
the line text to be output was rendered at the bottom of the screen
with the text above it scrolled upwards.
That's what you see in your typical terminal emulator all the time when you're working in the command line of a shell (such as bash) running by the emulator window.
This, default, work mode of a terminal is called "canonical" or "cooked".
Then came more advanced displays, for which it was possible to change
individual positions on the screen — identified by their column and
row numbers.
This changed the paradigm of how the information was output: the concept
of a so-called "full-screen application" was born.
Typical examples of them are text editors such as Vim and Emacs.
To support full-screen text output, terminals (and terminal emulators)
were adapted by implementing certain extensions to their protocols.
A full-screen application first requests the terminal to switch into another
mode called "raw", in which the terminal sends most of what is input by the
user directly to the program running on the terminal.
The program handles this input and orders the terminal where and what
to draw.
You can read this good summary
of the distinction between the both modes.
As you are supposedly suspecting by now, to be able to keep some block
of information at a certain fixed place of the terminal's text screen,
you want your program to be a full-screen program and use the terminal's
raw mode and its special commands allowing you to directly modify
text at certain character cells.
Now the problem is that different terminals (and terminal emulators)
have different commands to do that, so there exist libraries to isolate
the programs from these gory details. They rely on the special "terminal
information databases" to figure out what capabilities a terminal has
and how to make it do what the program asks.
See man terminfo for more background.
The most widely known such library (written in C) is called ncurses,
and there exist native solutions for Go with supposedly the most visible
one being github.com/nsf/termbox-go.
The github.com/gizak/termui makes use of termbox-go but for you it might
suffice to use the latter directly.
¹ Chances are very high you're not sitting at
a real hardware terminal
connected to a UNIX® machine but are rather working in a GUI application
such as GNOME Terminal or xterm or Termial.app etc.
These are not "terminals" per se but are rather
terminal emulators —
that is, pieces of software emulating a hardware terminal.
When typing the beginning of a command in the fish shell the most recent (or frequently?) possible completion of the command is visible in dark grey.
Say I type:
fish
in dark grey: _config is appended.
at this time it is not yet evident, what I'm about to do. So the TAB key shows me all possible completions of 'fish'
I can keep on typing characters, until it's clear what I want. E.g: _con
Now there is only one option to which this could be completed. So I can hit the tab key to see fish_config. However: this was not indicated somehow. In other words: After typing fish_con nothing really tells me that I don't have to keep on typing. Is this the case? Wouldn't this be extremely helpful?
Second question: What is the actual sense of the grey characters? I'd only understand their purpose if there was a way to accept this propose. After typing f, I'd expect a key combination that immediately fully completes to the propose in grey: fish_config.
Even better would be the option let the grey letters cycle through all options, or possible completions based on the history.
The characters to the right of the cursor are called the autosuggestion. They are gray to indicate that they are not actually part of the command, just a suggested completion of what you've typed so far.
So I can hit the tab key to see fish_config. However: this was not indicated somehow. In other words: After typing fish_con nothing really tells me that I don't have to keep on typing
This sounds like you have an idea for an indication when the partial command is a unique prefix of another command. I am not sure what UI you have in mind - what would the indication look like? Please feel welcome to open an issue with your UI ideas.
However if your command is unique, the autosuggestion will always contain it.
Second question: What is the actual sense of the grey characters? I'd only understand their purpose if there was a way to accept this propose. After typing f, I'd expect a key combination that immediately fully completes to the propose in grey: fish_config.
You can accept the autosuggestion by hitting right arrow or control-F. Tab shows you all possible completions, and up arrow lets you cycle through matching history.
You may want to read the fish tutorial, which covers autosuggestions here: http://fishshell.com/docs/current/tutorial.html#tut_autosuggestions
I would like to query and store the current terminal color pair in BASH e.g.:
#!/bin/bash
#some ANSI colour escape sequences
red="\033[0;31m"
grn="\033[0;32m"
blu="\033[0;34m"
def="\033[0;00m" # default
echo -e "Change to ${red} red to ${def} default to ${blu} blue."
# now store the current color (which happens to be blue) e.g.:
cur=????
echo -e "Change to ${grn} green and back to what I had before ${cur}"
echo -e "This would be in blue if variable cur contained e.g.: 0;34m."
echo -e "Back to default${def}"
exit 0
The answer that eludes me is how to capture the current color
cur=????
The question was about the current color, not the cursor position.
Both are "nonstandard" (though the latter, cursor position report is implemented by anything which has a valid claim to "VT100 emulator").
However, xterm implements a set of escape sequences referred to as dynamic colors, which predate the ANSI color functionality. Those set the working colors including text foreground and background. I modified this in 2002 to allow an application to send the sequence with a "?" rather than a color to tell xterm to return the color value, e.g.,
OSC 1 1 ? ST
using the notation given in XTerm Control Sequences
You can't; there is no standard control sequence to report the current cursor attributes.
What does exist, however, is a sequence to save and restore the current cursor position and attributes:
\e7 (DECSC) will save the cursor position and attributes.
\e8 (DECRC) will restore the saved cursor position and attributes.
There is no standard way to restore only the cursor attributes; however, as rici mentioned, you can get a report of the current position using \e[6n (DSR), then use the response to manually "un-restore" the cursor position after restoring its position and attributes.
Again, though, it's probably easier (and better) to just keep track of the colors in your application, rather than making the terminal responsible for that.
It's important to understand that the terminal state has nothing to do with bash. Bash doesn't care. It simply reads from stdin and writes to stdout and stderr. (See Note 1)
All terminal effects are implemented by the terminal emulator you happen to be using, of which there are many. In a graphical environment, you might be using, for example, xterm or konsole. You'll need to search the documentation for those emulators for specific terminal control codes which they interpret.
As far as I know, there is no standard code to get a report of the current terminal state, other than the cursor position (ESC[6n).
So your best bet is to remember the changes you made when you make them.
You can find a list of the standard codes implemented by the Linux console using man console_codes (although few people use the Linux console these days); most of those are also interpreted by xterm and other graphical consoles. There's an list of xterm sequences in Thomas Dickey's xterm site; it's a more or less de facto standard for terminal emulators but, as I said, you'll need to search in each emulator's documentation for idiosyncratic control sequences.
Notes
In interactive mode, bash uses a library called readline to help it handle some terminal effects. In particular, readline tries to maintain the current console cursor position, although it is easy to fool it. In PS1 you need to surround console control sequences with \[ and \] precisely because readline does not know that they are control sequences.
What I understood, is that u are asking to to get the default profile color of the user, of which u have change color of!
Eg: User is using 'Bright Green font color on Black background', you change it to 'Red font color on White background'. Now how to get/know the default colors and set them back to it!
You can use the sequence \033[0m in bash [also for command prompt (batch scripting) / powershell (ps scripting)]
I want to know if it's possible to detect available colors in terminal which vim was called, so I could select different colorschemes for each color situation.
This is different from checking &t_Co variable. Sometimes I open a vim with 8 colors, and can set t_Co=256 to use some colorschemes, but sometimes (Like in Terminal.app in mac), setting this variable doesn't throw an error but the t_Co isn't changed because Terminal.app's color limit is 16.
Fact is: I only know this limit by experience, I would like to know if it's possible to know this value from calling a function (if terminal_supports > 256) or something like that.
Can I do it using just viml functions, or I would need to create some bash scripts and call them from vimrc for example? I would like to have this information in Linux, Mac and Windows (also, using Cygwin).
(If I, for some reason, can't get this information from the system, is there a table or in vim help some information about different terminals and their color capabilities? If so, then I could create a hash table with all terminals and ther colors capabilities.)
Another try: some information is here, if you haven't found it already, including informative link at bottom of the linked page:
256_colors_in_vim
So far as I know Vim gets the t_Co number from termcap. So if you can get value from termcap to accurately reflect max colors supported then you're set. I think that's what the info in linked page does, at least for 256 color terms. . .