So, e.g., I notice terminal type of "linux" has some capabilities in its terminfo entry, which, at least in certain modes, aren't implemented - even though the terminfo entry has those capabilities there.Ī partial sample list of non-ANSI terminals (and variations). Sometimes some of those, or other artifacts/glitches are also described by the terminal's terminfo entry, and if so, some of those limitations may also be tested for, e.g. Note also that not all terminfo descriptions (and terminals, and terminal emulations) are always "perfect", and sometimes may not implement all capabilities in certain modes, or some capabilities/attributes may collide. # color numbers for tput setaf and tput setab:īlack=0 red=1 green=2 yellow=3 blue=4 magenta=5 cyan=6 white=7Ĭolors='black red green yellow blue magenta cyan white'
#Test for ansi escape sequences how to
here's some bits from terminfo(5), and bit of demonstration program using tput, including colors and some other modes: set_a_foreground setaf AF Set foregroundĮnter_standout_mode smso so begin standout modeĮxit_standout_mode rmso se exit standout modeĮnter_underline_mode smul us begin underline modeĮxit_underline_mode rmul ue exit underline modeĮnter_reverse_mode rev mr turn on reverseĮnter_blink_mode blink mb turn on blinkingĮnter_dim_mode dim mh turn on half-brightĮnter_bold_mode bold md turn on bold (extraĮnter_italics_mode sitm ZH Enter italic modeĮxit_italics_mode ritm ZR End italic modeĮxit_attribute_mode sgr0 me turn off all at-ġ>&2 echo "$0: echo $echo_e '' | read x fails!"ġ>&2 echo "$0: don't know how to do suppress newline with echo" And terminfo even allows one to write a terminal definition relative to another - notably referencing another to use as a base reference, and then adding/removing/changing the defined capabilities relative to that.Īnd. or even want to add a different definition to get somewhat different behavior out of the terminal, one can write the relevant (typically terminfo) entry for such terminal (emulation). So, if you've got a terminal (or emulation) that's not supported, and you want to add it. *nix even has the capability to write descriptions for new/different terminal types. regardless of what terminal type is being used. got a non-ANSI terminal? Use tput/terminfo/etc., and it'll still work - at least if it can and has the relevant capabilities. But again, don't presume the terminal is ANSI capable. Heck, you can even use tput to figure out ANSI escape codes if you want/need to. Presuming the terminal is ANSII or the like is a bad idea - it may not be at all.Īppropriate approach is to use the relevant terminfo libraries (or alternatively termcap - notably for older systems that may lack terminfo).Īnd as for CLI, that can generally be done using the tput utility. *nix uses and supports hundreds - if not thousands of types of terminal types (and emulations). Well, I see the tag "Linux" on the post, so I would say, in the land of *nix, that's NOT THE WAY TO DO IT! I only have three small features not in ctlseqs, and use XTVERSION and DECRQM to ensure they are only used when the terminal claims support. I do try to stick as close to stock xterm as I can.
Rinse and repeat for any additional options.
#Test for ansi escape sequences manual
DECSDM was flat out documented wrong in VT340, which xterm implemented wrong, we all copied, and then j4james found other terminals doing it right, plus the Thai language manual and the VT340 tests so that was a few months of the terminal emulators updating to be correct.
someone puts a mostly-transparent image up. hackerb9 recently (and I think saitoha too several years ago) bought a real VT340 and has been testing it with sequences and screenshots so that we can see what should really happen when e.g. ) there is still a lot of wiggle room as to what that means. Thing is even we had terminfo's for "yes, this terminal has sixel" (or iTerm2, or Kitty, or synchronized output, or proper DECSDM. I'm quite far outside robust solutions these days.
0 kommentar(er)
