i don't understand why sometimes the CUB sequence is allowed to continue through the previous line and sometimes not. the documentation tells it's not but in real situation...
http://vt100.net/docs/vt100-ug/chapter3.html#CUB
for exemple i have a screen filled with spaces on 80 columns and 24 lines.
i am at position line 3, column 4 which can be set with escape sequence : \033[3;4H
i move the cursor on the left 10 times with sequence \033[10D
wich will put me at position : line 2 column 76
so it worked ?!!
and sometimes it doesn't
please save me ! :)
I can reduce the situation but this is where i saw it :
I'm writing a vt* emulator and everithing works fine. i can launch emacs/vim and others but then i launched vttest in putty with the "script" command to record every typed characters and sequences. like so :
# script test
Script started, file is test
# vttest
...
when i do "cat test" in putty for exemple, it replays everythings like i did. when i play it with my emulator i am able to parse and to analyse every escape sequence they provide, but the display is not the same.
The wording on VT100.net is fairly clear:
If an attempt is made to move the cursor to the left of the left margin,
the cursor stops at the left margin.
In a recent discussion, someone pointed out that PuTTY honors a (non-VT100) capability bw, which quoting from ncurses' terminfo manual:
auto_left_margin bw bw cub1 wraps from col‐
umn 0 to last column
PuTTY's behavior for wrapping at the margins differs from VT100s, as you have seen. ncurses has a terminal entry named "putty", simply because PuTTY differs from all of the other terminals enough to make using a nuisance otherwise.
Related
I'm trying to write a command that writes many lines of output, then rewinds to the beginning to overwrite them in sequence with more information. To do this, I count the number of lines, then move that many lines up with ANSI escape codes, then start outputting again. This works great if the many lines of output fit in the window I have open, but if there are too many lines, the cursor only ends up moving to the top visible line. How can I always go back to the beginning of the output, regardless of the window size?
One simpler option may be to use a library to do it instead of doing all the heavy lifting and calculations yourself have a look at something like BashSimpleCurses this would allow you to use the update function easily.
I'm writing a terminal, and was trying to use steam locomotive as a test bed, and ran into an unusual problem. Even in a regular terminal like xterm or mate-terminal, the output is different if you run the application, i.e. sl verses if you log it to a file i.e. sl > sl.txt then cat it cat sl.txt
This is particularly pronounced on sl-h where in the first few seconds, codes are output which would make the X/O for the railroad crossing which if catted show incorrectly putting the X/O at the beginning of the line.
It seems that there is an ioctl that's happening that somehow changes newline behavior to advance to the next line, but not return back to the beginning. I.e. strace sl-h 2> sllog.txt shows: ioctl(1, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon echo ...}) = 0
How would you be able to detect this as a terminal? What systems are in place? Why wouldn't ncurses just use escape sequences to convey this information? There's a lot of questions that I'm not sure how to handle in my terminal.
ncurses (like Unix curses) puts the terminal into raw mode for two reasons:
ability to read single characters (and ignore signals such as quit that might be bound to them), and
ability to manage the output, including movement around the screen with fewer characters than a simple printf.
In raw mode, the Unix-style conversion of line-feed to carriage-return and line-feed is disabled. That lets ncurses move directly down by one row (in the same column) with a single characters. Cursor addressing would typically use 6 or more characters. Even a cursor-down would use 3 characters.
Incidentally, that treatment of line-feed is the reason why the terminal descriptions often have the cursor-down capability assigned to a line-feed.
I am creating a browser-based application for interacting with my local terminal, and I'm using the script command in the terminal (actually in a Java process) to feed input and capture output to display in the browser.
I have found that the virtual terminal inside the script process has 80 columns by default, and when a line of input exceeds that number, I see unexpected behavior. When it reaches the length limit, it adds a space, then a return, then continues with the line. For example, if I input the following:
user_name ~/my/current/directory$ ls /some/really/long/path/to/some/directory/somewhere
The following is what is actually transcribed (and forwarded to my browser app):
user_name ~/my/current/directory$ ls /some/really/long/path/to/some/directory/so ^Mmewhere
Notice the so ^Mmewhere instead of somewhere.
When I hit the up arrow after that to retrieve the last input, I get something different:
user_name ~/my/current/directory$ ls /some/really/long/path/to/some/directory/som^Mmewhere
This time, instead of the extra space character, it's duplicating the m: som^Mmewhere.
What is going on here? Is it that the script command is really intended to produce text output for a human reader, and therefore favors visual formatting over executability? Is there an alternative to script that would work better for my purpose?
Edit
I should have mentioned that I'm doing this in macOS Sierra. Not sure if that makes a difference.
As far I researched, terminfo/termcap and ioctl don't allow to query character at (x,y) position on terminal's screen. This is rather unexpected, because:
one can read e.g. screen dimensions from terminal (e.g. tput co, tput li),
one can read input from terminal
– the two mean that communication with terminal is bidirectional. Is there really no way to query a character at given position, like with *inch*, *in_wch* curses functions (which work only for curses windows)?
That's expected (not "unexpected"):
tput gives values from a combination of the terminal database (fixed) and the operating system (changeable), but does not ask the terminal.
reading from the terminal is by an input stream from the device (what terminals are designed to do).
Some (not all) terminals support an escape sequence which asks the terminal where the cursor is. The resize program uses that to obtain the screensize. But keep in mind that it is known to be terminal-dependent, as mentioned in the manual page:
-s [rows columns]
This option indicates that Sun console escape sequences will be
used instead of the VT100-style xterm escape codes.
Very few terminals support an escape sequence which will simply read characters from the screen. Not everyone likes the notion of a program that can read their screen — perhaps without their knowledge.
Every now and then when using the ack-vim plugin the font in my window will change to all symbols. I've yet to see any pattern to when this happens. Any suggestions on the cause and possible remedy would be appreciated.
I've seen that happen when binary content got printed to the terminal. Do your Ack queries potentially include binary files?
A fix might be
:!echo -e '\ec\e(K\e[J'
These ANSI Escape sequences attempt to reset the terminal:
# "ESC c" - sends reset to the terminal.
# "ESC ( K" - reloads the screen output mapping table.
# "ESC [ J" - erases display.
This looks like the typical character set translation enabled by the Shift Out control character; you usually just need to send the Shift In control character to counteract it.
Basically, something is outputting a C-n character (Control-N, U+000E, named Shift Out) which tells your terminal to switch to a different display character set. You should be able to get your terminal to switch back to the normal display character set by sending a C-o (Control-O, U+000F, named Shift In) to it.
If you are in Vim, then you can probably send the C-o with a command like this:
:!printf \\017
You will have to type (or paste) this command “blindly” since (due to the alternate character set) you will probably not be able to read what you are typing. If you are typing it (not pasting), then you can also type C-v C-o (to insert a single, literal C-o) instead of the backslashed octal, if that is easier to remember.
If you find that this problem occurs only sporadically when you use the vim-ack plugin, then perhaps some bit of the text results contains the problematic Shift Out character. You might try searching for the file with a command like this:
grep -FRl $(printf \\016) .
Once you know the names of the files, then you should be able to use Vim to search for the character (start a search and type C-v C-n to insert a literal C-n). Maybe it is just some garbage that you can clean out, or maybe you can configure your ack-based searches to exclude the problematic files.
You also tagged the question with tmux. I can not tell for sure, but it looks like the top line might be a tmux status line. Since this line is also corrupted it indicates that it your external terminal emulator that has switched character sets, not just one of your tmux panes.
If you send Shift Out or Shift In directly to a tmux pane it will only affect that pane (each pane is emulated independently), so your status like could not have been munged just by a stray Shift Out hitting a single pane.
If you are running inside tmux, then the easiest way to reset the outside terminal is to suspend and resume your tmux client (or detach from and reattach to your session). tmux pretty much resets the outside terminal when it gives up control.
Depending on the situation, you may also have to reset the character set of the tmux pane by sending it a C-o, too (i.e. printf \\017 at a shell, or a :! prompt in Vim).
It is easy to see how a stray Shift Out could reconfigure a single tmux pane, but it is harder to see how it could have “leaked” out to reconfigure the external terminal (tmux is pretty good at isolating things like this). However, there is a control sequence that tmux recognizes that instructs it to pass data directly to the external terminal (thus “leaking out”), but it is much less likely that you would randomly encounter this sequence since it is much longer:
printf '\ePtmux;%s\e\\' 'stuff bound for the external terminal'
You could use it to send the restorative Shift In like this:
printf '\ePtmux;%s\e\\' $(printf \\017)
You will also want to tell tmux to redraw itself after this (by default, the refresh-client command is bound to C-b r).
It is probably easier to just suspend and resume (or detach and reattach), but this sequence is useful if that is not possible. It also provides a means toward understanding what kind of sequence might “leak” out of tmux to switch the character set of the external terminal.