tput sequence that results in no apparent change? - curses

I frequently have to ssh to a remote system that, if faced with N minutes of inactivity (where N is rather small), will terminate my connection. I'm getting tired of being kicked off and losing my work/context just because, e.g., I went to look something up on the web and it took a little long.
I've been trying to come up with a simple script that I can run in the background that merely sends a small amount of output to the terminal now and then, so I will not be logged off.
Of course, ideally, I'd like the output not to interfere with whatever I'm doing, regardless of what I'm doing -- plain text, curses, whatever.
So I'm looking for some tput capability(s) that will reset the I/O timer, but result in a noop regarding screen appearance. I've found a lot of things that come close, but so far, all of them could conceivably result in a glitch if the timing is wrong.
What I'm currently doing is
echo -e "$(tput sc)$(tput rc)\c"
(save cursor, restore cursor). This has served me well so far, but I'm sure it's just a matter of time before it happens between some curses program doing it's own save/restore and getting messed up.
cub and/or cuf (cursor back, cursor forward) look like they could almost work. If either of them moved the cursor not-at-all when given a 0 parameter, that would be exactly what I'm looking for. But, unfortunately for me, 0 behaves exactly like 1 (cursor moves one position in whatever direction). At least, for the terminal I'm using, it does.
echo -e "$(tput cub1)$(tput cuf1)"
works great, except if it happens when the cursor is at the left edge of the screen. The cub1, in that case, does nothing, but then the cuf1 moves the cursor.
If I reversed them:
echo -e "$(tput cuf1)$(tput cub1)"
then I'd only have trouble if it happened while the cursor was sitting at the right edge of the screen, and I suppose that probably happens less often. Still...
If I could figure out how to get the cursor's current position, I'd get it, and then use it to cup to where it already is. But there doesn't seem to be a way to get the cursor's current position. (Or did I just miss it?)
mrcup with 0's for parameters might work if my terminal supported mrcup, but it doesn't.
Things like
echo -e '\c'
and
cat /dev/null
result in nothing at all going to the terminal, and so don't reset the inactivity timer.
Seems like there should be some simple way.
Any ideas?

I think I have it:
echo -e '\000\c'

Related

Listen and react to keypresses while another process is running?

I have this nifty couple of lines in my .bashrc that clears my unix terminal when I press shift+alt+c:
alias cls='printf "\033c"'
bind -x '"\eC":"cls"'
However, as you could probably guess, it only works when I'm actually at the prompt. If I'm in the middle of a program such as, let's say, tail -f, then I have to get back to the prompt, press shift+alt+c, then go back to the program (or ctrl+z, shift+alt+c, then fg).
I'm thinking it would be cool if I could somehow listen for keys while this other program is running. It's probably impossible, but I figured I'd ask here before I gave up. Any ideas?
Thanks!
Not going to work. That's your shell doing that.
Your shell isn't active when something else is.
You could do this sort of thing with your terminal if you really wanted to though (assuming it allows you to control it sufficiently) since your terminal sees the keys first.

Bash shell turns to symbols when using VIM Ack Plugin

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.

Printing on screen the percentage completed while my tcl script is running?

I have a tcl script which takes a few minutes to run (the execution time varies based on different configurations).
I want the users to have some kind of an idea of whether it's still executing and how long it would take to complete while the script executes.
Some of the ideas I've had so far:
1) Indicate it using ... which keep increasing with each internal command run or so. But again it doesn't really give a sense of how much more to go for a first time user.
2) Use the revolving slash which I've seen used many places.
3) Have an actual percentage completed output on screen. No idea if this is viable or how to go about it.
Does anyone have any ideas on what could be done so that users of the script understand what's going on and how to do this?
Also if I'm implementing it using ... , how do I get them to print the . on the same line each time. If I use puts to do this in the tcl script the . just gets printed on the next line.
And for the revolving slash, I would need to replace something which was already printed on screen. How can I do this with tcl?
First off, the reason you were having problems printing dots was that Tcl was buffering its output, waiting for a new line. That's often a useful behavior (often enough that it's the default) but it isn't wanted in this case so you turn it off with:
fconfigure stdout -buffering none
(The other buffering options are line and full, which offer progressively higher levels of buffering for improved performance but reduced responsiveness.)
Alternatively, do flush stdout after printing a dot. (Or print the dots to stderr, which is unbuffered by default due to mainly being for error messages.)
Doing a spinner isn't much harder than printing dots. The key trick is to use a carriage return (a non-printable character sometimes visualized as ^M) to move the cursor position back to the start of the line. It's nice to factor the spinner code out into a little procedure:
proc spinner {} {
global spinnerIdx
if {[incr spinnerIdx] > 3} {
set spinnerIdx 0
}
set spinnerChars {/ - \\ |}
puts -nonewline "\r[lindex $spinnerChars $spinnerIdx]"
flush stdout
}
Then all you need to do is call spinner regularly. Easy! (Also, print something over the spinner once you've finished; just do puts "\r$theOrdinaryMessage".)
Going all the way to an actual progress meter is nice, and it builds on these techniques, but it requires that you work out how much processing there is to do and so on. A spinner is much easier to implement! (Especially if you've not yet nailed down how much work there is to do.)
The standard output stream is initially line buffered, so you won't see new output until you write a newline character, call flush or close it (which is automatically done when your script exits). You could turn this buffering off with...
fconfigure stdout -buffering none
...but diagnostics, errors, messages, progress etc should really be written to the stderr stream instead. It has buffering set to none by default so you won't need fconfigure.

Elegant and efficient way to start GUI programs from terminal without spamming it (Bash or any Posix shell)

Every once in a while I have to fire up a GUI program from my terminal session to do something. It usually is Chrome to display some HTML file are some task alike.
These programs however throw warnings all over the place and it can actually become ridiculous to write anything so I always wanted to redirect stderr/stdout to /dev/null.
While ($PROGRAM &) &>/dev/null seems okay I decided to create a simple Bash function for it so I don't have to repeat myself everytime.
So for now my solution is something like this:
#
# silly little function
#
gui ()
{
if [ $# -gt 0 ] ; then
($# &) &>/dev/null
else
echo "missing argument"
fi
}
#
# silly little example
#
alias google-chrome='gui google-chrome'
So what I'm wondering about is:
Is there a way without an endless list of aliases that's still snappy?
Are there different strategies to accomplish this?
Do other shells offer different solutions?
In asking these questions I want to point out that your strategies and solutions might deviate substantially form mine. Redirecting output to /dev/null and aliasing it was the only way I know but there might be entirely different ways that are more efficient.
Hence this question :-)
As others have pointed in the comments, I think the real problem is a way to distinguish between gui vs. non-gui apps on the commandline. As such, the cleanest way I could think of is to put this part of your script:
#!/bin/bash
if [ $# -gt 0 ] ; then
($# &) &>/dev/null
else
echo "missing argument"
fi
into a file called gui, then chmod +x it and put it in your ~/bin/ (make sure ~/bin is in your $PATH). Now you can launch gui apps with:
`gui google-chrome`
on the prompt.
Alternatively, you can do the above, then make use of bind:
bind 'RETURN: "\e[1~gui \e[4~\n"'
This will allow you to just do:
google-chrome
on the prompt and it would automatically append gui before google-chrome
Or, you can bind the above action to F12 instead of RETURN with
bind '"\e[24~": "\e[1~gui \e[4~\n"'
To separate what you want launched with gui vs. non-gui.
More discussion on binding here and here.
These alternatives offer you a way out of endless aliases; a mix of:
Putting gui in your ~/bin/, and
Binding use of gui to F12 as shown above
seems the most ideal (albeit hacky) solution.
Update - #Enno Weichert's Resultant Solution:
Rounding this solution out ...
This would take care of aliases (in a somewhat whacky way though) and different escape encodings (in a more pragmatic rather than exhaustive way).
Put this in $(HOME)/bin/quiet
#!/bin/bash -i
if [ $# -gt 0 ] ; then
# Expand if $1 is an alias
if [ $(alias -p | awk -F "[ =]" '{print $2}' | grep -x $1) > 0 ] ; then
set -- $(alias $1 | awk -F "['']" '{print $2}') "${#:2}"
fi
($# &) &>/dev/null
else
echo "missing argument"
fi
And this in $(HOME)/.inputrc
#
# Bind prepend `quiet ` to [ALT][RETURN]
#
# The condition is of limited use actually but serves to seperate
# TTY instances from Gnome Terminal instances for me.
# There might very well be other VT emulators that ID as `xterm`
# but use totally different escape codes!
#
$if $term=xterm
"\e\C-j": "\eOHquiet \eOF\n"
$else
"\e\C-m": "\e[1~quiet \e[4~\n"
$endif
Although it is an ugly hack, I sometimes use nohup for a similar needs. It has the side effect of redirecting the command's output, and it makes the program independent of the terminal session.
For the case of running GUI programs in a desktop envinroment it has only little risk for resource leaks as the program will anyway end with window manager session. Nevertheless it should be taken into account.
There is also the option of opening another terminal session. In Gnome for instance, you can use gnome-terminal --comand 'yourapp'.
But this will result in opening many useless terminal windows.
First, it's a great idea to launch GUI applications from the terminal, as this reduces mouse usage. It's faster, and more convenient in terms of options and arguments. For example, take the browser. Say you have the URL in the clipboard, ready to paste. Just type, say, ice (for Iceweasel) and hit Shift-Insert (to paste) and Enter. Compare this to clicking an icon (possibly in a menu), wait for the window to load (even worse if there is a start up page), then click the URL bar (or hit Ctrl-L), then Ctrl-V... So I understand you desire for this to work.
But, I don't see how this would require an "infinite" list of aliases and functions. Are you really using that many GUI applications? And even so, aliases are one line - functions, which may be more practical for handling arguments, are perhaps 1-5 lines of (sparse) code. And, don't feel you need to set them up once and for all - set them up one by one as you go along, when the need arises. Before long, you'll have them all.
Also, if you have a tabbed terminal, like urxvt (there is a Perl extension), you'd benefit from moving from "GUI:s" to "CLI:s": for downloading, there's rtorrent; for IRC, irssi; instead of XEmacs (or emacs), emacs -nw; there is a CLI interface to vlc for streaming music; for mail, Emacs' rmail; etc. etc.! Go hunt :)
(The only sad exception I've run across that I think is a lost cause is the browser. Lynx, W3M, etc., may be great from a technical perspective, but that won't always even matter, as modern web pages are simply not designed with those, text-only browsers in mind. In all honesty, a lot of those pages look a lot less clear in those browsers.)
Hint: To get the most out of a tabbed terminal, you'd like the "change tab" shortcuts "close" (e.g., Alt-J for previous tab and Alt-K for next tab, not the arrow keys that'll make you reach).
Last, one solution that'll circumvent this problem, and that is to launch the "GUI:s" as background processes (with &) in your ~/.xinitrc (including your terminal emulator). Not very flexible, but great for the stuff you always use, every time you use your computer.
Ok, so I kept thinking that the one function should be enough. No aliases, no bashisms, no nonsense. But it seemed to me that the only the way to do that without possibly affecting regular use, such as expansions and completions, was to put the function at the end of the command. This is not as easy as one might first assume.
First I considered a function tacked onto the end in which I would call, say, printf "%b" "\u" in order to cut the current line, plug in another printf, paste it back in, and a quote or two at the beginning, then do what little is needed at the end. I don't know how to make this work though, I'm sorry to say. And even if I did, I couldn't hope for any real reliability/portability with this method due to the varying ways shells interpret escape sequences, not to mention the terminal emulators they run in. Perhaps stty could offer a way forward along these lines, but if so, you won't find it here... now, anyway.
I eventually instead resorted to actually copying the current command's /proc/{PID}/cmdline to a variable, then (shamefully) killing it entirely, and finally wrapping it as I pleased. On the plus side, this is very easily done, very quickly done (though I can imagine arguing its 'efficiency' either way), and seems mostly to work, regardless of the original input, whether that be an alias, a variable, a function, etc. I believe it is also POSIX portable (though I can't remember if I need to specify the kill SIGNALS by name for POSIX or not), and is definitely no nonsense.
On the other hand, its elegance certainly leaves much to be desired, and, though it's probably not worth worrying about, it does waste entirely a single PID. And it doesn't stop completely the shell spam; that is, in my shell I have enabled background jobs reporting with set and so, when first run, the shell kindly informs me that I've just opened and wasted a PID in two lines. Also, because I copy the ../cmdline instead of interfacing directly with the 0 file descriptor, I expect pipes and ; and etc to be problematic. This I can, and likely will, fix myself very soon.
I will fix that, that is, if I cannot find a way to instead make use of, as I suspect can be done,SIGTSTP + SIGCONT by first suspending the process outside a subshell then within one continuing it after redirecting the subshell's output. It seems that this works unreliably for reasons I haven't yet discovered, but I think it's promising. Perhaps nohup and a trap (to effectively rehup it, as it were) is what is needed, but I'm not really sure how to put those together either...
Amyway, without further ado, my semi-aborted, backwards gui launcher:
% _G() { (
_gui_cmd="$(tr '\0' ' ' </proc/"$\!"/cmdline )" ;
kill -9 "$\!" ;
exec eval "${_gui_cmd} &" )
&>/dev/null 2&>1
}
% google-chrome-beta --disk-cache-dir="/tmp/cache" --disk-cache-size=100000000 &_G
[1] 2674
[1] + 2674 killed google-chrome-beta --disk-cache-dir="/tmp/cache" --disk-cache-
%
So another problem one might encounter if attempting to do similar is the order of expansion the shell assumes. Without some trick such as mine you're sure to have some serious difficulty expanding your function before the prior command snags it as an argument. I believe I have guarded against this without unnecessary redundancy by simply tacking my _G function call onto the original command's & background intstruction. Simply add &_Gto the tail-end of the command you wish to run and, well, good luck.
-Mike
P.S. Ok, so writing that last sentence makes me think of what might be done with tee.

Emacs: some programs only work in ansi-term, some programs only work in shell

Relative Emacs newbie here, just trying to adapt my programming workflow to fit with emacs. So far I've discovered shell-pop and I'm quite enjoying on-demand terminals that pop up when needed for banging out the odd commands.
What I understand so far about Emacs is that shell is a "dumb" terminal that doesn't support any ansi control codes, and that makes it incompatible with things like ncurses that attempt to draw complex UI's on a terminal emulator. This is why you can't use less or top or similar in shell-mode.
However, I seem to be having trouble with ansi-term, it's not the be-all, end-all that it's cracked up to be. Sure, it has no problems running less or git log or even nano, but there are a few things that can't quite seem to display properly when they're running in an ansi-term, such as apt-get and nosetests. I'm not sure quite what the name is for it, but apt-get's output is characterised by live-updating what is displayed on the very last line, and then having unchanging lines of text scroll out above that line. It seems to be halfway between something like less and something dumber, like cat. Somehow ansi-term doesn't like this at all, and I get very garbled output, where it seems to output everything on one line only or just generally lose it's place and output things all over, randomly. In the case of nosetests, it starts off ok, but if any libraries spew out any STDERR, the output all goes to hell in a similar way.
With some fiddling it seems possible to fix this by mashing C-l and RET, but it's not always reliable.
Does anybody know what's going on here? Is there some way to fix ansi-term so that it can display everything properly? Or is there perhaps some other mode that I don't know about that is way better? Ideally I'd like something that "just works" as effortlessly as, eg, Gnome Terminal, which can run all of the above mentioned programs without a single hiccup.
Thanks!
I resolved this issue by commenting out my entire .emacs.el and then uncommenting and restarting emacs for every single line in the file. I discovered that the following line alone was responsible for the issue:
'(fringe-mode 0 nil (fringe))
(this line disables the fringes from inside custom-set-variables).
I guess this is a bug in Emacs, that disabling the fringe causes term-mode to garble it's output really badly whenever any output line exceeds $COLUMN columns.
Anyway, I don't really like the fringes much at all, and it seems I was able to at least disable the left fringe without triggering this issue:
(set-fringe-mode (cons 0 8))
Maybe apt-get does different things based on the $TERM environment variable. What happens if you set TERM=dumb? If that makes things work, then you can experiment with different values until you find one that supports enough features but still works.
Note that git 2.0.1 (June 25th, 2014) now better detects dumb terminal when displaying verbose messages.
That might help Emacs better display some of the messages received from git, but the fringe-mode bug reported above is certainly the main cause.
See commit 38de156 by Michael Naumov (mnaoumov)
sideband.c: do not use ANSI control sequence on non-terminal
Diagnostic messages received on the sideband #2 from the server side are sent to the standard error with ANSI terminal control sequence "\033[K" that erases to the end of line appended at the end of each line.
However, some programs (e.g. GitExtensions for Windows) read and interpret and/or show the message without understanding the terminal control sequences, resulting them to be shown to their end users.
To help these programs, squelch the control sequence when the standard error stream is not being sent to a tty.

Resources