I need to turn automatic margins off according the following statement from Screen's manual in my Mac
If your terminal is a "true"
auto-margin terminal (it doesn't allow
the last position on the screen
to be updated without scrolling the screen) consider using a version
of your terminal's termcap that
has automatic margins turned off.
How can you turn automatic margins off by your terminal's termcap?
Most terminal emulators, including the mac default terminal, are not "true auto-margin terminals" in the sense being discussed here - they emulate a vt100-series terminal, which had "smart" wraparound. You can check by running cat and typing to the end of the last line - after you type the last character, the cursor remains at the end of the line (highlighting the character you just typed) until you type another character.
The only consequence of a 'true auto-margin terminal' is that a character cannot be displayed in the lower right hand corner (though some programs are able to work around that by shifting a character into place with ich/ich1)
According to XTerm Control Sequences, this sequence should do what was asked:
CSI ? 7 l
That is,
printf '\033[?7l'
The 7 is documented as
Ps = 7 -> Wraparound Mode (DECAWM).
and the final character l (lowercase L) denotes this as a reset rather than a set control.
For whatever reason, the terminfo name for this is more obscure: "automatic margins". These terminfo capabilities deal with the feature (see terminfo(5)):
auto_right_margin am am terminal has auto‐
matic margins
enter_am_mode smam SA turn on automatic
margins
exit_am_mode rmam RA turn off automatic
margins
Interestingly, the vt100-nam terminal description in ncurses (which apparently no one uses) initializes the terminal to use automargins margins using this string:
rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h,
(the \E[?7h sets it), and asserts that the terminal does not use automatic margins by cancelling am. It also has the terminfo capabilities rmam and smam. So you could do this to prove that it works:
tput rmam
stty columns 999
ps -efwwwwwl
and (for the ordinary user) see the ps listing nicely truncated against the right margin of the terminal window.
The other variants vt220-nam and vt320-nam appear correct...
By the way, for Mac, you would use the terminfo names such as rmcup rather than the termcap RA, because OSX uses ncurses' tput (terminfo) rather than the BSD variant.
Further reading:
tput, reset - initialize a terminal or query terminfo
database
history section for tput
history section for tset
Occasionally someone asks about suppressing automargins because they suppose that terminals can pan/scroll left/right to show the information which was not wrapped to a new line. Terminals which do this are rare, and OSX Terminal is not one of those. It behaves like a subset of xterm, which itself emulates the series of DEC terminals vt52/vt100/vt220/etc. In this question, OP is concerned/confused about this paragraph from the screen manual:
If your terminal is a "true" auto-margin terminal (it doesn't allow the
last position on the screen to be updated without scrolling the screen)
consider using a version of your terminal's termcap that has automatic
margins turned off. This will ensure an accurate and optimal update of
the screen in all circumstances. Most terminals nowadays have "magic"
margins (automatic margins plus usable last column). This is the VT100
style type and perfectly suited for screen. If all you've got is a
"true" auto-margin terminal screen will be content to use it, but
updating a character put into the last position on the screen may not
be possible until the screen scrolls or the character is moved into a
safe position in some other way. This delay can be shortened by using a
terminal with insert-character capability.
That last position on the screen refers to the lower-right corner of the terminal. In the normal case, if your cursor is on the lower-right corner and you print a character, you would expect the display to scroll up by one line and show the character on the next line. Also (because terminals can be implemented in different ways), some could scroll up when you print a character in the last position. The VT100 does not do this. Not only does it not scroll up in that case, but it ignores non-printing characters while on the margin (see xterm FAQ That description of wrapping is odd, say more?). There is a terminfo flag xenl which is set to show when the terminal does this special behavior. About a third of the terminal descriptions in the terminal database have this flag. While most of those are for terminals which you likely will never encounter, keep in mind that the advice in the manual page was written back in an era when those other terminals were as likely to be found as a VT100-lookalike. The early change-history for screen is poor, but the text was in screen's second posting to Usenet in 1992. The initial posting in 1987 said something similar:
Screen
never writes in the last position of the screen, unless the boolean
capability LP is found in the termcap entry of the terminal.
Usually,
screen
cannot predict whether or not a particular terminal scrolls when
a character is written in the last column of the last line;
LP indicates that it is safe to write in this position.
Note that the LP capability is independent of am (automatic
margins); for certain terminals, such as the VT100, it is reasonable
to set am as well as LP in the corresponding termcap entry
(the VT100 does not move the cursor when a character is written in
the last column of each line).
The later wording reflects the fact that the terminfo system was prevalent, and the name LP was not termcap name chosen for corresponding with xenl (it is xn).
The point of all of this is that screen attempts to convert between programs writing to different terminal types and make them all appear like one type of terminal — which means that it tries to put text on the terminal's display in all of the locations. The lower-right corner is a problem because some terminals would scroll up, spoiling the attempt to write there. As a workaround, some terminals provided an alternative:
using a different mode (insert),
put the cursor on the next to last position of the display,
write characters to fill in, pushing a character into the last position, and
turn insert-mode off once it is done (otherwise a nuisance).
About two thirds of the descriptions in the terminal database have the capability to do this insert-mode (smir). That still was not perfect, but it certainly was worth mentioning in 1992. About a quarter implement a similar similar feature ich1. Some implement both (and vi could get confused by those, by trying to do both methods).
VT100-lookalikes provide a third way to write that last position; screen checks for and uses whatever is there.
If I understand you correctly you're looking to set the autowrap feature to NO using terminfo database. If so I believe you can use the -nam flag to turn it off - something like vt100-nam should do it. You can also check by looking at the man pages for terminfo.
If this solves your question, mark this up. (^_^) If not... well comment back and I'll check again for you. Cheers!
Update: There's also a shortcut that may apply to you to toggle the wrap off and on. Check out the shortcut sheet here. And additional information for Screen can be found here (search for wrap). You can also check here on how to use setterm (section 17.14 Changing the Terminal Settings). Also check here for examples of changing settings.
Good luck again. (^_^)
Related
In Ubuntu gnome-terminal it can be done by doing Ctrl + or Ctrl -
Is there a way to write a python script that when executed would resize the font size of the terminal it is executed from?
I need this in order to display images in terminal with high resolution using timg.
Checking the source (vte and gnome-terminal), looks like there's no way to do this. Other terminals (e.g., xterm) can do this using escape sequences. See XTerm Control Sequences:
OSC Ps ; Pt ST
Set Text Parameters. For colors and font, if Pt is a "?", the
control sequence elicits a response which consists of the con-
trol sequence which would set the corresponding value. The
dtterm control sequences allow you to determine the icon name
and window title.
...
Ps = 5 0 -> Set Font to Pt. These controls may be disabled
using the allowFontOps resource. If Pt begins with a "#",
index in the font menu, relative (if the next character is a
plus or minus sign) or absolute. A number is expected but not
required after the sign (the default is the current entry for
relative, zero for absolute indexing).
vte recognizes the 50, but that (like a lot of other xterm features) is just a stub that doesn't do anything. The xterm sources include a 20-year old script which demonstrates the feature (see fonts.sh).
Rather than using an escape sequence, you might be able to use the wmctrl tool (which could ask the window manager to negotiate with the terminal). Some have done that with other terminals, e.g, terminology (but ultimately using an escape sequence).
vte does have some code which might be accessible from a python script, using g_signal_connect to associate decrease-font-size and increase-font-size signal (see source code). The signal code is what you're using with the keyboard. But how you might determine the object pointer from a script starting outside the terminal emulator isn't clear.
There is no easy way to do this across terminals. Terminals support so called control sequences, which can set a bunch of options, like text color and others, but there is no control sequence for setting the font size. See for example https://en.wikipedia.org/wiki/ANSI_escape_code and https://invisible-island.net/xterm/ctlseqs/ctlseqs.html for what kind of actions are supported.
Is there any way to determine what the color of the cursor is in a terminal running something like vim? I know that you can use tput cols and tput rows to determine the height and width of the terminal, are there similar tools for cursor color/obtaining the ansi standard foreground/background color of any character location in the current terminal?
The answer to your question is "No, there is no standard way to do that."
Consider that your terminal is modelled after ancient text terminals (like DEC VT100 and the like) which communicated with a server over a serial port or modem. And those terminals were in turn modelled after TeleTYpe (tty) devices which were connected to computers back in the 1960s.
Teletype machines ("dumb" terminals) provided no data back to the server that was not typed in to the keyboard. Devices like the VT100 ("smart" terminals) provided VERY LITTLE back to the server, but the list of what's available hasn't changed in many years.
Other resources:
The full list of reports available in VT220 emulation.
Another useful unofficial resource with slightly easier to follow wording.
Note that not all terminals are VT100/VT220, and your system may have locak extensions that provide what you need in a non-standard way.
For extra reading, have a look at man termcap and man terminfo. Check out the references in the "SEE ALSO" section of those pages.
Short answer: no
Long answer: the feature, if widely available would be another capability of tput, which allows you to retrieve any of the terminal capabilities for scripting. Those are documented in the terminfo manual page. None of those deal with cursor color, only with the (rather vague) cvvis (very visible), cnorm (normal) and civis (invisible) cursor attributes.
That is, most terminals do not
provide a way to set the cursor color or
provide a way to retrieve the cursor color
xterm is a rare exception, providing both. But the feature is not often supported in terminals imitating xterm. It is documented in XTerm Control Sequences as part of the dynamic colors feature:
OSC Ps ; Pt ST
OSC Ps ; Pt BEL
Set Text Parameters. For colors and font, if Pt is a "?", the
control sequence elicits a response which consists of the con-
trol sequence which would set the corresponding value. The
dtterm control sequences allow you to determine the icon name
and window title.
The 10 colors (below) which may be set or queried using 1 0
through 1 9 are denoted dynamic colors, since the correspond-
ing control sequences were the first means for setting xterm's
colors dynamically, i.e., after it was started. They are not
the same as the ANSI colors. These controls may be disabled
using the allowColorOps resource. At least one parameter is
expected for Pt. Each successive parameter changes the next
color in the list. The value of Ps tells the starting point
in the list. The colors are specified by name or RGB specifi-
cation as per XParseColor.
If a "?" is given rather than a name or RGB specification,
xterm replies with a control sequence of the same form which
can be used to set the corresponding dynamic color. Because
more than one pair of color number and specification can be
given in one control sequence, xterm can make more than one
reply.
Ps = 1 2 -> Change text cursor color to Pt.
The command-line program xtermcontrol uses these escape sequences to set and get the cursor color:
--cursor=COLOR
Set cursor color to COLOR.
--get-cursor
Report cursor color.
For example
$ xtermcontrol --get-cursor
rgb:0000/0000/0000
$ xtermcontrol --cursor limegreen
$ xtermcontrol --get-cursor
rgb:3232/cdcd/3232
For what it's worth, it is supported by VTE (e.g., gnome-terminal).
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 found out that the Bash shell supports a type of autocompletion that is different from the "traditional" autocompletion, where all possibilities get listed on the following line.
With the "traditional" autocompletion, if I type ch and then press the Tab key, I get something like:
$ ch
chacl chgrp chmod chown chvt
But if I add the following line to my /etc/inputrc (which remaps the Tab key to the built-in menu-complete function):
Tab: menu-complete
then the behavior of the shell changes: the word to be completed is replaced "inline" with a single match from the list of possible completions, and if I press the Tab key again, the word gets replaced with the next match.
I found this useful, but I still wanted to keep the traditional autocompletion and have it bound to the key combination Ctrl + Tab. So I added the following line to my /etc/inputrc file, according to what the readline library documentation suggests:
Ctrl-Tab: complete
However, adding this line only seems to make both Tab and Ctrl-Tab call the traditional complete function.
Does anyone know what I am doing wrong?
Thanks in advance!
To start with, I'm not a massive expert in this area, but I think I can answer your question. First of all, while you are using Bash, Bash is a shell which interprets keyboard commands that it receives from a terminal / console. While you are informing Bash how to react to specific key combinations in the inputrc file, your Terminal determines precisely which character is 'sent' to the Shell before the inputrc file even enters the equation.
Unfortunately, on my system (granted, it's OSX - but I don't think this is strange behaviour when compared to Linux), both Tab and Ctrl-Tab send the same keyboard input to the shell. Infact, both Tab and Ctrl-Tab send a Ctrl-I command to the shell, and indeed, if I enter Ctrl-I when using the terminal, it performs the completion as if I hit Tab.
The software (installed on most Linux systems by default), showkey will tell you what keys the shell is receiving when you press specific keyboard inputs as you push them.
Anyway, my suggestion to you is to use Shift-Tab, which does appear to send it's own key-code to the shell. Shift-Tab on my computer shows up (using showkey) as '<ESC>[Z', which I think is pretty standard across the board. As such, your inputrc file with the following bindings should allow you to use shift-tab instead of ctrl-tab to achieve what you desire:
Tab: menu-complete
"\e[Z": complete
The \e in the second binding represents the escape character, and the [Z are simply the characters as shown using showkey. You can get a similar effect on OSX by simply using cat, running cat from within a terminal and pressing Shift-Tab will show you "^[[Z", where ^[ represents the escape character and the other characters are as before.
I know this doesn't resolve your question precisely, but as I don't think you are able to use Ctrl-Tab as a key combination, without re-mapping Ctrl-Tab to another keybinding within your terminal (more likely to be easier if you are using a GUI terminal), this is likely as close as you can get without significant effort!
I have ShiftTab bound to menu-complete-backward, so it goes back one step if I skipped the right completion, and I've mapped Ctrlq to complete, so if there are several possible completions I hit Ctrlq to list them without having to cycle through them.
# Make Tab cycle between possible completions
# Cycle forward: Tab
# Cycle backward: Shift-Tab
TAB: menu-complete
"\e[Z": menu-complete-backward
# Make C-q display the list of possible completions
Control-q: complete
# Display the list of matches when no further completion is possible
set show-all-if-unmodified on
Edit: Ctrlq is bound to quoted-insert by default, that is, it tells the shell to take the next key literally. quoted-insert is also bound to Ctrlv, so you don't lose that functionality if you rebind Ctrlq. Anyway, I've found that AltESC also works, by default, for showing the possible completions (as far as I can tell it is equivalent to TAB); note that it may be seized by Gnome, then either double press ESC or rebind "Switch windows directly" in Settings → Devices → Keyboard → Navigation.
The following should achieve what you're looking for (if I understand correctly!)
In your .inputrc
# display all possible matches for an ambiguous pattern at first tab
set show-all-if-ambiguous on
# next tab(s) will cycle through matches
TAB: menu-complete
# shift tab cycles backward
"\e[Z": menu-complete-backward
Where to start, if you can or cant do this is dependent your keyboard and your drivers and there isn't one catch all answer. Each key press and release generates a sequenced key pair (key down and release) (scancode) these codes are then translated by the kernel into keycodes for example on my laptop keyboard 0x3a 0xba are translated to keycode 15 (down and up) these are then translated into actions such as return letter c a / you can assign actions to keysyms using the keycode/hex/binary/octal notation which codes match which letters is determined by the kernel translation table which is fairly standardized, however the first part signal that's translated to keycodes is different for most keyboards.
Continuing with the earlier example for me shift tab (and alt and control and any combination) produce keycode 15 however in hex it produces 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a and this is because shift alt and control are special keys (modifiers) these multiply out against the keycodes and fill out the dumpkeys table the kernel is limited to the number of assignments as well this is determined by your choice of keymap and shares resources with your terminal colors (if your char set its defined above the threshold it limits your terminal color scope). And this all goes out the window if your in an xserver and has a whole new system. Most of these things can be changed,modified and manipulated by the user and programs installed. My point to all this is to emphasize that there is no catch all for the mapping of the tab key and its going to vary keyboard drivers to kbd drivers (now if you find a solution that happens to work for you excellent :)) but chances are it won't be portable and might not work if you change keyboards and might not translate between xserver and tui. What i recommend is learning the steps to modify your kbd on the go.
will give you the decimal octal hex notation for a key press on the same line
--full-table -1 >> keytable
will give you a documented with your full list of keycode->keysym pairing in a format that will give you a better picture of your layout and from there you can either use loadkey to change a keys value or ad an entry in .inputrc or your main rc file. You can also create a custom key.map file.
Further escape sequence translation is determined by the "$TERM" variable and each virtual terminal emulator can be different
infocmp "$TERM"
will give you a list of your terminal escape sequences
Resources:
https://man7.org/linux/man-pages/man4/console_codes.4.html
https://www.gnu.org/software/screen/manual/html_node/Input-Translation.html
http://kbd-project.org/docs/scancodes/scancodes.html
https://www.vt100.net/
So to sum up.
Your keyboard drivers
Your kemap choice
Your virtual terminal emulator
and your kernel
form the backbone of remapping dificult keys (tab/s-tab/a-tab)
I'm not sure Ctrl-Tab is a real character; my terminal, for instance, ignores the combination. I think the only way to use Ctrl-Tab is to use your terminal emulator to map it to some otherwise unused escape sequence, then bind that sequence to complete.
There are several libraries like ncurses that assist in making command-line GUIs.
Simply put, how do they work?
My first thought was that ncurses intercepts all keyboard input, and draws each "frame" by outputting it line-by-line normally. Closer inspection, however, reveals that each new frame overwrites the previous one. How does it modify lines that have already been outputted? Furthermore, how does it handle color?
EDIT: The same question applies to anything with a "fancy" interface, like vim and emacs.
Text terminals have command sequences that do things like move the cursor to a particular position on the screen, insert characters, delete lines etc.
Each terminal type is different and has its own set of command sequences. ncurses has a databse (see terminfo for details)
Internally ncurses maintains 2 views of the screen: the current contents and what the screen should look like after the current pending changes are applied. Once the program requests a screen redraw, ncurses calculates an efficient way to update the screen to look like the desired view. The exact characters/command sequences output depend on what terminal type is in use.
curses (and ncurses, too, I think) works by moving the cursor around on the screen. There are control sequences to do such things. Take a look at the code again and you'll see them. These sequences are not ASCII control characters, they are strings starting with (umm...) ESC, maybe. Have a look here for a higher-level explanation.