I am writing automation scripts (perl/bash). Many of them benefit from some basic terminal GUI. I figured I'd use standard ANSI sequences for basic drawing. Before drawing in terminal I do clear but doing that I lose some terminal command history. I want to be able to restore terminal command history when my program exists. Many terminal programs (e.g. less, man, vim, htop, nmon, whiptail, dialog etc) do exactly that. All of them restore terminal window bringing the user back to where he was prior to calling the program with all the history of commands previously executed.
To be honest I don't even know where to start searching. Is it a command from curses library? Is it an ANSI escape sequence? Should I mess with tty? I am stuck and any pointers would be really helpful.
EDIT: I'd like to clarify that I am not really asking "how to use the alternative screen". I am looking for a way to preserve terminal command history. One possible answer to my question could be "use alternative screen". The question "what is alternative screen and how to use it" is a different question which in turn already has answers posted elsewhere. Thanks :)
You should use the alternate screen terminal capability. See
Using the "alternate screen" in a bash script
An answer to "how to use the alternate screen":
This example should illustrate:
#!/bin/sh
: <<desc
Shows the top of /etc/passwd on the terminal for 1 second
and then restores the terminal to exactly how it was
desc
tput smcup #save previous state
head -n$(tput lines) /etc/passwd #get a screenful of lines
sleep 1
tput rmcup #restore previous state
This'll only work on a terminal has the smcup and rmcup capabilities (e.g., not on Linux console (=a virtual console)).
Terminal capabilities can be inspected with infocmp.
On a terminal that doesn't support it, my tput smcup simply return an exit status of 1 without outputting the escape sequence.
Note:
If you intend to redirect the output, you might want to write the escape sequences directly to /dev/tty so as to not dirty your stdout with them:
exec 3>&1 #save old stdout
exec 1>/dev/tty #write directly to terminal by default
#...
cat /etc/passwd >&3 #write actual intended output to the original stdout
#...
Related
Often when I run a command that writes to stdout, and that command fails, I have to scroll up (using uncomfortable key-bindings) looking for the place where I pressed Enter, to see what the first error was (out of hundreds others, across many screens of text). This is both annoying and time-consuming. I wish there was a feature which allowed me to pin my current terminal to the place where I am now, then start the command, see only the first lines of the output (as many as fits below my cursor) and let the rest of the output be written but not displayed. In other words I would like a feature to allow me automatically scroll up to the place where I gave the command, to see the first lines of the output (where usually the origin of the failure is displayed).
I searched for it but I didn't find it. Do you know if such feature exists? Or have an idea how to implement it with some tricks or workarounds?
If you have a unique shell prompt you could bind a key to jump between shell prompts, for example something like this will make C-b S jump to the previous shell prompt then S subsequent ones:
bind S copy-mode \; send -X search-backward 'nicholas#myhost:'
bind -Tcopy-mode S send -X search-backward 'nicholas#myhost:'
Or similarly you could search for error strings if they have a recognisable prefix. If you install the tmux 3.1 release candidate, you can search for regular expressions.
Alternatively, you could use capture-pane to load the entire history into an editor with key bindings you prefer, for example:
$ tmux capturep -S- -E- -p|vim -
Or pipe to grep or whatever. Note you will need to use a temporary file for this to work with emacs.
Or try to get into the habit of teeing commands with lots of output to a file to start with.
I'd like to write a shell script that can suggest a command by printing it after the command line prompt.
Then, after the scrip exit, the user would only have to press the [enter] key to run this suggested command.
Given that I'm new to bash, I don't even know if it is possible to do this. I thought about using a copy-past command, moving the cursor, use the $PS1 variable, without finding a suitable way..
Does anyone have any clues on how such feature could be implemented ?
Following the suggestion of Landen in the comments (thanks a lot!), I've been able to produce a workaround for my problem.
This workaround needs the xautomation package (xte command, emulating key pressed), is not very robust, and may depends on the keyboard layout handling of xautomation, and system shortcuts. For example, I had to change the shortcut for the unity HUD.
But given that my command is very fast, and that is is mostly for personal use, this solution fits perfeclty my needs:
COMMAND_PASSED='sudo apt-get update'
# Displays the content of $COMMAND_PASSED on the next prompt
xte "str $COMMAND_PASSED"
sleep 0.1
tput cub ${#COMMAND_PASSED}
sleep 0.1 and tput cub ${#COMMAND_PASSED} commands are needed to prevent the keys from being also displayed before the command prompt.
sleep 0.1 makes the whole command to be printed before the prompt.
tput cub ${#COMMAND_PASSED} move the cursor backward to make sure that all unnecessary prints are erased.
Thanks everyone!
Edit: This question was originally bash specific. I'd still rather have a bash solution, but if there's a good way to do this in another shell then that would be useful to know as well!
Okay, top level description of the problem. I would like to be able to add a hook to bash such that, when a user enters, for example $cat foo | sort -n | less, this is intercepted and translated into wrapper 'cat foo | sort -n | less'. I've seen ways to run commands before and after each command (using DEBUG traps or PROMPT_COMMAND or similar), but nothing about how to intercept each command and allow it to be handled by another process. Is there a way to do this?
For an explanation of why I'd like to do this, in case people have other suggestions of ways to approach it:
Tools like script let you log everything you do in a terminal to a log (as, to an extent, does bash history). However, they don't do it very well - script mixes input with output into one big string and gets confused with applications such as vi which take over the screen, history only gives you the raw commands being typed in, and neither of them work well if you have commands being entered into multiple terminals at the same time. What I would like to do is capture much richer information - as an example, the command, the time it executed, the time it completed, the exit status, the first few lines of stdin and stdout. I'd also prefer to send this to a listening daemon somewhere which could happily multiplex multiple terminals. The easy way to do this is to pass the command to another program which can exec a shell to handle the command as a subprocess whilst getting handles to stdin, stdout, exit status etc. One could write a shell to do this, but you'd lose much of the functionality already in bash, which would be annoying.
The motivation for this comes from trying to make sense of exploratory data analysis like procedures after the fact. With richer information like this, it would be possible to generate decent reporting on what happened, squashing multiple invocations of one command into one where the first few gave non-zero exits, asking where files came from by searching for everything that touched the file, etc etc.
Run this bash script:
#!/bin/bash
while read -e line
do
wrapper "$line"
done
In its simplest form, wrapper could consist of eval "$LINE". You mentioned wanting to have timings, so maybe instead have time eval "$line". You wanted to capture exit status, so this should be followed by the line save=$?. And, you wanted to capture the first few lines of stdout, so some redirecting is in order. And so on.
MORE: Jo So suggests that handling for multiple-line bash commands be included. In its simplest form, if eval returns with "syntax error: unexpected end of file", then you want to prompt for another line of input before proceeding. Better yet, to check for proper bash commands, run bash -n <<<"$line" before you do the eval. If bash -n reports the end-of-line error, then prompt for more input to add to `$line'. And so on.
Binfmt_misc comes to mind. The Linux kernel has a capability to allow arbitrary executable file formats to be recognized and passed to user application.
You could use this capability to register your wrapper but instead of handling arbitrary executable, it should handle all executable.
I've been using screen for quite some time now and I agree, it improves my productivity.But one thing that I really miss is the command history. Anything I type in a screen session doesn't get logged in command history. When I googled for the same I found something related to this issue:
http://www.linuxquestions.org/questions/slackware-14/aliases-lost-when-using-screen-723624/
But surprisingly in my case all the aliases are intact and I'm able to use them without any issues. As far as I know opening a new screen session actually opens a new sub-shell. If this is true, could someone help me how to get the commands typed in screen session to be logged in the command history so that if I open a new terminal/screen later on I'll be able to access the commands from command history using CTRL+R . Any solution that helps me make screen log commands in command history would be very much helpful. Appreciate your time. Thank you.
Assuming a bash shell is being used within the screen.
Insert the 2 statements into ~/.bashrc:
shopt -s histappend
PROMPT_COMMAND="$PROMPT_COMMAND;history -a"
The first command appends the commands to the history file, rather than overwrite it while the second command saves each command right after it has been executed, not at the end of the session.
To expand on my answer.. the history for each bash session that you have open is stored in memory until you logout/close the session. Then it will overwrite the bash history file.
These commands will append to the history file, and then flush to the file after every command.
It's easy to use shared history between sessions in Zsh, and this blog post by Derek Reeve explains how to do it. In short, add this to your ~/.zshrc:
setopt share_history
HISTSIZE=1000
SAVEHIST=1000
HISTFILE=~/.history
setopt APPEND_HISTORY
I also found instructions for doing the same thing on Bash, but I've only tried this on Zsh.
How do some programs edit whats being displayed on the terminal (to pick a random example, the program 'sl')? I'm thinking of the Linux terminal here, it may happen in other OS's too, I don't know. I've always thought once some text was displayed, it stayed there. How do you change it without redrawing the entire screen?
Depending on the terminal you send control seuqences. Common sequences are for example esc[;H to send the cursor to a specific position (e.g. on Ansi, Xterm, Linux, VT100). However, this will vary with the type or terminal the user has ... curses (in conjunction with the terminfo files) will wrap that information for you.
Many applications make use of the curses library, or some language binding to it.
For rewriting on a single line, such as updating progress information, the special character "carriage return", often specified by the escape sequence "\r", can return the cursor to the start of the current line allowing subsequent output to overwrite what was previously written there.
try this shellscript
#!/bin/bash
i=1
while [ true ]
do
echo -e -n "\r $i"
i=$((i+1))
done
the -n options prevents the newline ... and the \r does the carriage return ... you write again and again into the same line - no scroling or what so ever
If you terminate a line sent to the terminal with a carriage return ('\r') instead of a linefeed ('\n'), it will move the cursor to the beginning of the current line, allowing the program to print more text over top of what it printed before. I use this occasionally for progress messages for long tasks.
If you ever need to do more terminal editing than that, use ncurses or a variant thereof.
There are characters that can be sent to the terminal that move the cursor back. Then text can be overwritten.
There is a list here. Note the "move cursor something" lines.
NCurses is a cross-platform library that lets you draw user interfaces on smart terminals.
Corporal Touchy has answered how this is done at the lowest level. For easier development the curses library gives a higher level of control than simply sending characters to the terminal.
To build on #Corporal Touchy's answer, there are libraries available that will handle some of this functionality for you such as curses/ncurses
I agree with danio, ncurses is the way to go. Here's a good tutorial:
http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/