Geek Answers Handbook

Unclear: VT100 "soft-wrap" documented escape sequence?

When connecting to a remote BASH session via SSH (with the terminal type set to vt100), the console console console will gently wrap when the cursor enters column 80.

What I'm trying to detect is if the sequence <space><carriage return>that is being sent at that moment is documented anywhere?

For example, sending the following line

    std::string str = "0123456789"  // 1
                        "0123456789"
                        "0123456789"    // 3
                        "0123456789"
                        "0123456789"    // 5
                        "012345678 9"
                        "0123456789_"   // 7
                        "0123456789"
                        "0";

receives the following response from the host (Linux Mint, as it happens)

01234567890123456789012345678901234567890123456789012345678<WS><WS><CR>90123456789_01234567890
+4
source share
2 answers

bash; , readline. , echo ( bash) , , bash , , , (, , . 80 , .)

, "" " - . , , .

:

  • , .

  • .

. ( 1 ), . ( 2) "".

2, DEC VT-100. terminfo xenl: "eat-newline-glitch".

2. , VT-100 ( xterm), ; , , . "" , , . ( bw.)

, , -. (, - - , , .) , , , . backspace-delete, cub1 (move left 1), el ( ). ( , , .)

, , . , , , , el, , .

, , . ( terminfo.src, ncurses. , ):

# Note that the <xenl> glitch in vt100 is not quite the same as on the Concept,
# since the cursor is left in a different position while in the
# weird state (concept at beginning of next line, vt100 at end
# of this line) so all versions of vi before 3.7 don't handle
# <xenl> right on vt100. The correct way to handle <xenl> is when
# you output the char in column 80, immediately output CR LF
# and then assume you are in column 1 of the next line. If <xenl>
# is on, am should be on too.

, , , "" xenl : , , , , .

, , xterm (, , ), "", . , , , . terminfo , xterm ( ) , . , xterm . ( , , .)

, SP CR VT100. , ( ) . , , , - , , , [ 2].

readline , , : [ 1]

  /* If we're at the right edge of a terminal that supports xn, we're
     ready to wrap around, so do so.  This fixes problems with knowing
     the exact cursor position and cut-and-paste with certain terminal
     emulators.  In this calculation, TEMP is the physical screen
     position of the cursor. */

(xn - xenl.)

+8

, ( "folklore" ):

  • xterm FAQ , ? , vt100.

  • vim screen -, , xterm. ( , , , bash ), , , xterm. xterm :

    , , , xterm , .

  • " ", , , , . Sven Mascheck XTerm :

    ! Wether this works also with _wrapped_ selections, depends on ! - the terminal emulator: Neither MIT X11R5/6 nor Suns openwin xterm ! know about that. Use the 'xfree xterm' or 'rxvt'. Both compile on ! all major platforms. ! - It only works if xterm is wrapping the line itself ! (not always really obvious for the user, though). ! - Among the different vi's, vim actually supports this with a ! clever and little hackish trick (see screen.c): ! ! But before: vim inspects the _name_ of the value of TERM. ! This must be similar to "xterm" (like "xterm-xfree86", which is ! better than "xterm-color", btw, see his FAQ). ! The terminfo entry _itself_ doesn't matter here ! (e.g.: 'xterm' and 'vs100' are the same entry, but with ! the latter it doesn't work). ! ! If vim has to wrap a word, it appends a space at the first part, ! this space will be wrapped by xterm. Going on with writing, vim ! in turn then positions the cursor again at the _beginning_ of this ! next line. Thus, the space is not visible. But xterm now believes ! that the two lines are actually a single one--as xterm _has_ done ! some wrapping also...

, @rici, terminfo, SCO 1995 . terminfo . termcap BSD, , BSD termcap ncurses. , " ", ( ) SCO. / :

# # --------------------------------
#
# dec: DEC (DIGITAL EQUIPMENT CORPORATION)
#
# Manufacturer: DEC (DIGITAL EQUIPTMENT CORP.)
# Class:    II
# 
# Info:
#   Note that xenl glitch in vt100 is not quite the same as concept,
#   since the cursor is left in a different position while in the
#   weird state (concept at beginning of next line, vt100 at end
#   of this line) so all versions of vi before 3.7 don't handle
#   xenl right on vt100. The correct way to handle xenl is when
#   you output the char in column 80, immediately output CR LF
#   and then assume you are in column 1 of the next line. If xenl
#   is on, am should be on too.
#   
#   I assume you have smooth scroll off or are at a slow enough baud
#   rate that it doesn't matter (1200? or less). Also this assumes
#   that you set auto-nl to "on", if you set it off use vt100-nam 
#   below.
#   
#   The padding requirements listed here are guesses. It is strongly
#   recommended that xon/xoff be enabled, as this is assumed here.
#   
#   The vt100 uses rs2 and rf rather than is2/tbc/hts because the 
#   tab settings are in non-volatile memory and don't need to be 
#   reset upon login. Also setting the number of columns glitches 
#   the screen annoyingly. You can type "reset" to get them set.
#
# smkx and rmkx, given below, were removed. 
# smkx=\E[?1h\E=, rmkx=\E[?1l\E>,
# Somtimes smkx and rmkx are included.  This will put the auxilliary keypad in
# dec application mode, which is not appropriate for SCO applications.
vt100|vt100-am|dec vt100 (w/advanced video),

, ncurses , terminfo, . .

+2

More articles:


All Articles