This question is purely out of curiosity; there's no problem to be resolved.
Note: I'm using Konsole on CentOS 7.
When I SSH to a remote box and leave the session inactive for a while, it times out. As a workaround, I use less [some-file] to keep the session active.
Obviously the sessions still break when I suspend the VM at the end of the day.
The next day when I start a new SSH session, everything is normal except that some Konsole functionality doesn't work (namely, clearing scrollback, which I use a lot) for the same terminal window used for the SSH session.
However, after I less a file and quit, two things happen:
Konsole resumes working normally.
Whatever output was in the terminal before I used less is replaced with whatever output was there the previous day, before the session was broken by shutting down the VM I'm SSHing from.
Curiously, this happens for all ~4 concurrent terminals/sessions (each one having its output from the previous day restored). [edit: clarification: each of the ~4 terminals exhibits this behavior when I SSH/less in that particular terminal. Each one resumes its output from the day before. Doing this in one terminal/session is not affecting the other terminals/sessions]
I assume this would happen with any terminal app (e.g. vi, nano, etc.) with its own "gui" and isn't specific to less.
Seems like there's some caching going on. I assume quitting less (or vi, nano, etc.) triggers some sort of shell output restoration in general, but this particular manifestation seems somewhat odd.
Any idea what's going on?
The terminal feature described in the question the alternate screen feature (originally xterm, but copied/imitated by several other terminals including konsole). Depending on the terminal description, you may/may not use this feature.
less and most full-screen terminal programs such as vi send the escape sequences to switch to/from alternate screen if they're defined in the terminal description (i.e., TERM=xterm).
From the description, it sounds as if you're using different tabs in the same instance of konsole, and that it's remembering that your terminal was set to the alternate screen. konsole and some other programs attempt to save/restore "session" information when halted, so that probably seemed like a good thing to save/restore.
While in the alternate screen, terminal programs typically have little or no access to the scrollback region.
You can use tput to send the same escape sequence (without running less):
tput rmcup
(If the terminal description doesn't have a definition for that, it'll do nothing).
Further reading:
Why doesn't the screen clear when running vi?
Related
Good day everyone,
I am working on a project that requires me to have 7+ programs (no GUI, runs on shell) open, all interacting with each other. For example, Program 1 asks a question to Program 2, and it uses Program 3 and 4 to solve that etc.
So what I do is, I open many terminals and run each one on a different terminal, then I place them on my screen and go ahead. But this is a troublesome process, as every time I need to recompile I need to run them all one by one again, even worse, if I ever turn my computer off, I need to open many shells, go to the directories, run them all so and so.
What I want is a file that would open the necessary terminal windows for me and go to the correct directory on each, then run the programs. I don't know much about shell-scripts, but I assumed this must have been possible. Can you give me any directions? Note that the programs should not run in background or in different tabs. I need to be constantly observing the displays.
I have read this post about a similar issue but that does not work for me, because I need them on different terminals.
Thank you.
We suppose you are using gnome terminale, so the command would be:
gnome-terminal --working-directory "{{APP_FOLDER}}" --command "{{APP_EXCUTABLE}}"
That approach can be traslated to any other terminal emulator.
I spent several decades using Digital Equipment Corporation's VMS operating system, and one of the things I really miss is the terminal driver's 'read-with-prompt' functionality.
It would display the prompt and position the cursor for input, as you'd expect, but the prompt was immune to things like CTRL/U, CTRL/R, and CTRL/W. It was an attribute of the read operation, and every time the terminal driver was ready to read from the terminal with this option, it would show the prompt. The user couldn't erase it, so if it went off the screen he'd still know what was being requested.
This is one of the few things that I think VMS did better than U*X -- unless there's a Linuxish way of doing this.
So far I've never found it, but maybe I'm just not looking in the right place.
Is there a way on Linux to read from a tty with a persistent prompt?
Thanks!
I used to create a screen and use vim to trace source code.
I usually use the commands to create, detach and attach a screen to keep my vim status.
$ screen -S vim_src1
[CTRL+a] d to detach the screen
$ screen -r vim_src1
However, screen status will be killed after system restart.
Can I attach screen after system restart?
After a system restart there is no screen session to attach. You can certainly create a new session.
A screen session that you could attach has been running since you detached it. A system restart kills all of the processes (including those running in screen).
In desktop environments, you may see occasional support for saving "session" state. Doing that relies upon each application to save its state when asked, e.g., on system shutdown. That can be workable for large GUI applications (which are designed to handle events). But in contrast, screen is mostly used for shell applications where this is done rarely.
Rather than require each application to save/restore itself, it is conceivable that the operating system could be designed to do this. But that does not appear to be the case for the systems we are using.
Further reading:
How to Automatically Remember Running Applications from Your Last Session in Ubuntu 14.04
How can I keep restore for apps in Lion without having session restore when I log in?
I can interpret your answer in a few ways, because I'm not 100% certain what your objective is. I'll try to give the two most obvious options I'm aware of.
You can configure your screen session with ~/.screenrc so it always launches the same with, with labels and for screens, and it will even launch applications for you. For example:
defutf8 on
caption always "%{= kK} %{K}%-w%{+b w}%51>%n %t%{= K}%+w%<%-=%{= kK} me#localhost | %{w}20%y-%m-%d %{w}%0c:%s %{-}"
shelltitle '$|$'
defscrollback 10000
termcap xterm|xterms|xs ti=\E7\E[?47l
terminfo xterm|xterms|xs ti=\E7\E[?47l
startup_message off
screen -t vim 0 vim $HOME/todo.txt
screen -t ipython 1 ipython
screen -t finch 2 finch
screen -t mutt 3 mutt
screen -t top 4 top
chdir $HOME/Repos/git
screen -t CL 5
screen -t git 6
If you actually want to be able to save a session that you're in you might consider using screen-session.
https://github.com/skoneka/screen-session
Session saver currently supports saving of: layouts, scrollbacks,
titles, filters and is able to restart programs run in windows. It
recognizes regular, group and zombie windows. Currently there is no
support for serial and telnet window types. By default, session saver
also tries to save Vim sessions using ":mksession" and ":wviminfo".
Session saver accesses important data by directly reading /proc
filesystem and sorts processes by parent pid. There is almost no
"stuffing" of commands into windows (except when saving Vim sessions)
so there is no interaction with programs itself.
During session loading, every new window starts with
screen-session-primer (a small C program) which displays a list of
processes and asks user what to do: whether to start none, some or all
of window's processes or directly starts programs provided
"--force-start [win_num]" option was used.
When I press and hold a key, a first symbol is typed, then there is a little delay, and then other symbols are typed fast. Something like this:
Same happens in Terminal. Same happens in linux console (tty), even though this delay is smaller there.
I'm working on a console app in Python that uses curses, and it processes the presses of arrow keys and this delay is present there as well.
I want to get rid of this delay, so that when I press and hold a key - it would send signals with uniformly, without any specific delays after first (or whichever) symbol.
How can I do it? Should I use something from the arsenal of curses? Or tinker with some system-wide settings?
EDIT1: I think I've found one way. I can go to keyboard settings and set delay of autorepeat. But it changes it globally and only for my graphical interface. It doesn't change anything in linux console. So, I'm looking fo a way to do it in console as well, and also so it would affect only my app, not the whole system.
and a way for linux console: https://unix.stackexchange.com/questions/58651/adjusting-keyboard-sensitivity-in-a-command-line-terminal
but still looking for an app-only way.
Why does it take significantly more time to print multiple lines to the terminal rather than redirecting it to a file which seems to be almost instant ?
Primarily, terminals are just plain slow. For every update, they have to:
Parse and interpret any control codes.
Parse, interpret and render any escape codes.
Interpret and account for any multibyte and composed characters.
Update appropriate screen and scroll buffers.
Render this with appropriate fonts.
and possibly do all of the above over again if you use screen or tmux.
Meanwhile, for redirecting to a file, you just have to:
Dump data into RAM (for later writeback to storage).
This step is so minor that it doesn't even register on the terminal's checklist.
This is not something people optimize for, because the speed of your terminal is rarely an issue. The difference between terminals can be 50x (VGA vs fbcon back in the day), and you can time it with a simple time cat somebigfile.txt.