Tools for CLI Road Warriors: Remote Shells //at 19:44 //by abe

Most of my private online life happens on netbooks and besides the web browser, SSH is my most used program — especially on netbooks. Accordingly I also have hosts on the net to which I connect via SSH. My most used program there is GNU Screen.

So yes, for things like e-mail, IRC, and Jabber I connect to a running screen session on some host with a permanent internet connection. On those hosts there is usually one GNU Screen instance running permanently with either mutt or irssi (which is also my Jabber client via a Bitlbee gateway).

But there are some other less well-known tools which I regard as useful in such a setup. The following two tools can both be seen as SSH for special occassions.

autossh

I already blogged about autossh, even twice, so I’ll just recap the most important features here:

autossh is a wrapper around SSH which regularily checks via two tunnels connect to each other on the remote side if the connection is still alive, and if not, it kills the ssh and starts a new one with the same parameters (i.e. tunnels, port forwardings, commands to call, etc.).

It’s quite obvious that this is perfect to be combined with screen’s -R and -d options.

I use autossh so often that I even adopted its Debian package.

mosh

Since last week there’s a new kid in town^WDebian Unstable: mosh targets the same problems as autossh (unreliable networks, roaming, suspending the computer, etc.) just with a completely different approach which partially even obsoletes the usage of GNU Screen or tmux:

While mosh uses plain SSH for authentication, authorization and key exchange the final connection is an AES-128 encrypted UDP connection on a random port and is independent of the client’s IP address.

This allows mosh to have the following advantages: The connection stays even if you’re switching networks or suspending your netbook. So if you’re just running a single text-mode application you don’t even need GNU Screen or tmux. (You still do if you want the terminal multiplexing feature of GNU Screen or tmux.)

Another nice feature, especially on unreliable WLAN connections or laggy GSM or UMTS connections is mosh’s output prediction based on its input (i.e. what is typed). Per line it tries to guess which server reaction a key press would cause and if it detects a lagging connection, it shows the predicted result underlined until it gets the real result from the server. This eases writing mails in a remote mutt or chatting in a remote irssi, especially if you noticed that you made a typo, but can’t remember how many backspaces you would have to type to fix it.

Mosh needs to be installed on both, client and server, but the server is only activated via SSH, so it has no port open unless a connection is started. And despite that (in Debian) mosh is currently just available in Unstable, the package builds fine on Squeeze, too. There’s also an PPA for Ubuntu and of course you can also get the source code, e.g. as git checkout from GitHub.

mosh is still under heavy development and new features and bug fixes get added nearly every day.

Thanks to Christine Spang for sponsoring and mentoring Keith’s mosh package in Debian.

Update: I gave a lightning talk about Mosh and AutoSSH in German at Easterhegg 2012. The slides are available online.

Happy Birthday GNU Screen! //at 23:46 //by abe

According to this Usenet posting, GNU Screen became 25 years old today. (Found via Fefe.)

And no, it’s not dead. In contrary, the reaction on the mailing list to bug fixes with patches is usually impressingly prompt. :-)

I took this occassion and uploaded a current git snapshot of GNU Screen to Debian Experimental.

Bug #644788 (screen 4.1.0 can’t attach to a running or detached screen 4.0.3 session) is still an issue with that snapshot, but gladly upstream seems to work on a solution for it. There’s even talk about a 4.1.0 beta release soon — although that hasn’t happened yet.

Have fun!

Git Snapshot of GNU Screen in Debian Experimental //at 01:09 //by abe

I just uploaded a snapshot of GNU Screen to Debian Experimental. The package (4.1.0~20110819git450e8f3-1) is based on upstream’s HEAD whose most recent commit currently dates to the 19th of August 2011.

While the upload fixes tons of bugs which accumulated over the past two years in Debian’s, Ubuntu’s and upstream’s bug tracker, I don’t yet regard it as suitable for the next stable release (and hence for Debian Unstable) since there’s one not so nice issue about it:

• #644788: screen 4.1.0 can’t attach to a running/detached screen 4.0.3 session

Nevertheless it fixes a lot of open issues (of which the oldest is a wishlist bug report dating back to 1998 :-) and I didn’t want to withhold it from the rest of the Debian community so I uploaded it to Debian Experimental.

Issues closed in Debian Experimental

• #25096: digraph table should be run-time configurable
• #152961: lacks tsl/fsl/dsl caps
• #176626: mini-curses type of interface for screen -r w/ multiple screens? (Fixed by suggesting iselect, screenie or byobu)
• #223320: does not switch mouse mode
• #344759: mishandles xterm control string to set window title
• #353090: please enable the built-in telnet
• #361274: cannot reattach to sessionname if there is another session with similar sessionname
• #450421: please raise MAXWIN to at least 100 (merged with #499273)
• #461107: Requires test -t 0 even when opening a new window on existing screen
• #481411: window created with ‘-d -m’ silently ignores ‘-X exec’
• #488619: Session name string escape
• #496750: screen -d -m and -D -m segfault if setenv given with no value in a configuration file
• #532240: screen with caption SEGVs when resized to 1 line tall
• #541793: “C-a h” (mis)documented twice
• #558724: breaks altscreen
• #560231: Please remove restriction on user/login name length
• #578729: outputs spaces when refreshing/attaching a window with “defbce on”
• #591624: segfault when running “screen -d -m” with “layout save default” in .screenrc
• #603009: Updating the screen Uploaders list
• #612990: /etc/init.d/screen-cleanup: should check for existence of screen binary
• #621704: Fix slow scrolling in vertical splits
• #630535: manpage typo
• #641867: version bump (this bug report sparked the upload :-)

Update: Issues also closed in Debian Experimental, but not (yet) mentioned in the Debian changelog

• #238535: screen lock can no more be bypassed by reattaching.
• #446082: Shows cursor in front of the selected window in “windowlist -b”.
• #522689: Passes signals to programs running inside screen on kfreebsd.
• #526002: Adds focus left/right commands.
• #611453: Documents vertical split in man-page.
• #621804 and #630976: Allows longer $TERM than 20 characters

Issues which will be closed in Ubuntu

• #183849: update to git version of screen
• #315237: crashes with certain options and terminal sizes
• #582153: doesn’t accept login names longer than 20 chars
• #588846: slow when using vertical split
• #702094: Copying and pasting from mutt includes many trailing spaces
• #786292: segfaults if using layout saving with “-D -m”
• #788670: segfault in screen/byobu in natty

Please test the version from Experimental

If you are affected by one of the issues mentioned above, please try the version from Debian Experimental and check if they’re resolved for you, too.

Thanks to all who contributed!

A lot of the fixes have been made or applied upstream by Sadrul Habib Chowdhury who also industriously tagged Debian bug reports as “fixed-upstream”. Thanks!

Thanks also to Brian P Kroth who gave the initial spark to this upload by packaging Fedora 15’s git snapshot for Debian and filing bug although the upload is based on the current HEAD version of GNU Screen as this fixes some more important issues than the snapshot Fedora 15 includes. That way also two patches from Fedora/RedHat’s screen package are included in this upload.

(Co-) Maintainer wanted!

Oh, and if you care about the state of GNU Screen in Debian, I’d really appreciate if you’d join in and contribute to our collab-maint git repository – there are still a lot of issues unresolved and I know that I won’t be able to fix all of them myself. And since Hessophanes unfortunately currently has not enough time for the package, we definitely need more people maintaining this package.

P.S.

Yes, I know about tmux and tried to get some of my setups working with it, too. But I still prefer screen over tmux. :-)

Useful but Unknown Unix Tools: watch //at 22:18 //by abe

Yet another useful tool of which at least I heard quite late in my Unix career is “watch”. For a long time I wrote one-liners like this to monitor the output of a command:

while :; do echo -n "`date` "; host bla nameserver; sleep 2; done

But it’s way shorter and less error-prone to use “watch” from Debian’s procps package and just write

watch host bla nameserver

The only relevant difference is that I don’t have some kind of history when the output of the command changed, e.g. to calculate the rate with which a file grows.

You can even track the output of more than one command:

watch 'ps aux | grep resize2fs; df -hl'

Also a nice way to use watch is to run it inside GNU Screen (or tmux or splitvt) and split up the terminal horizontally, i.e. show the output of watch in one window and the process you’re tracking with the commands run by watch in the other window and see both running at the same time.

Update, Sunday, 28th of August 2011, 17:13h

I never found a useful case for watch’s -d option which highlights changes to the previous run (by inverting the changed bytes), but until now three people pointed out the -d option in response to this blog-posting and weasel also had some nice examples, so here are they:

Keep an eye on the current network routes (once per second) of a host and quickly notice when they change:

watch -n1 -d ip r

Watch the current directory for size or time stamp changes of its files:

watch -d ls -l

The option -d only highlights changes from the previous run to the next run. If you want to see all bytes which ever changed since the first run, use --differences=cumulative.

Thanks to Klaus “Mowgli” Ethgen, Ulrich “mru” Dangel, Uli “youam” Martens and Peter “weasel” Palfrader for comments and suggestions.

Useful but Unknown Unix Tools: colored cal(endar) //at 02:09 //by abe

Another thing I regard as useful on the commandline are colors. (Others commonly refer to my color preferences as eye cancer, but that’s not relevant here. ;-) Colors help to easily distinguish between relevant and non-relevant things or to separate different things.

One colored command line program I use nearly everyday is the colored fork of bsdmainutils’s well know (or at least better known) “cal” program whose output looks like this:

$ cal
    November 2010    
Su Mo Tu We Th Fr Sa
    1  2  3  4  5  6
 7  8  9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
$ 

Since the colored fork calls itself still “cal” (as the Debian source package is called), to avoid conflicts with bsdmainutils’s cal, the binary package and the binary itself are called ccal (short for colored cal) and its output looks like this:

$ ccal
    November 2010     
 Mo Tu We Th Fr Sa Su 
  1  2  3  4  5  6  7 
  8  9 10 11 12 13 14 
 15 16 17 18 19 20 21 
 22 23 24 25 26 27 28 
 29<30>               
                      
$ 

ccal also use the locale definitions (LC_TIME), if available, that’s why the one “screenshot” is Sun-Sat and the other one is Mon-Sun.

According to the man page, ccal has some more improvements over the classic cal:

But I must admit, I don’t use that feature. I just use it as on-demand calendar sheet.

The colored “screenshot” above is btw. generated with Adam Borowski’s ansi2html which popped up after I published my Intent to package “aha” (for Ansi HTML Adapter), the first ANSI colors to HTML converter I found on the net. (And yes I searched for it because of this and some yet to come blog postings. No spoilers here though. ;-)

While capturing colored output of “ls” and some other tools was easy, it needed a little hack to capture ccal’s output, because if you pipe ccal output to anything, it drops its colors. Always. The solution was to run it in GNU Screen, log the output and then pipe the log file through “aha” or “ansi2html”:

$ screen -c /dev/null -L ccal; cat screenlog.0 | ansi2html > ccal.html

Probably the output of every program which drops colors when writing to a pipe instead of a terminal can be fetched that way.

Update, 2:04 CET: As Adam Borowski points out in message 62 of #605380, “script” is the better tool for making tools believe they talk to a terminal:

$ script -q /dev/null -c "ccal" | ansi2html

Catching the output of a whole year’s calender (“ccal 2011”) failed with GNU screen though, as it was truncated on the 24th of September by GNU screen (as it was already truncated in the screenlog.0), so no “screenshot” of that for the moment. And with script, I’d get the whole output, but would have to manually fix the styles so they don’t get posted literally to Planet Debian. So look for yourself how the output of “ccal 2011” looks like by installing ccal. ;-)

Screen and Emacsclient: Automatically switching to the Emacs window //at 10:38 //by abe

For a very long time, I use mutt with emacsclient as configured editor and a single GNU Emacs instance started from either .screenrc or .Xsession, depending on the system. And I’m very used to switching the virtual desktop or the screen window after starting a mail in mutt.

Since Debian 5.0 Lenny and Emacs 22, Emacs automatically grabs the focus and switches to the right virtual desktop. So after telling mutt recipient and subject of a new e-mail, it invokes emacsclient and immediately the focus has moved to the running Emacs instance. Because I was used to switch one virtual desktop to the right at that point, I often found my self two desktops to the right until I got used to it. :-)

I usually hate applications which grab the focus without being asked. But in this case I basically asked for it. And there’s no delay like with starting up an application which has to read in some database first – think of Liferea or Rhythmbox which take many seconds to minutes to start up, even on my 2.2 GHz dual core ThinkPad.

In the meantime I got so used to that automatic desktop switch that I forget to switch the screen window in the second scenario where I use this combination: My screen doesn’t automatically switch to the Emacs window (window 1) after I told mutt recepient and subject in window 2.

Knowing that screen is quite scriptable, I found out that only a very small change is needed to my mutt configuration to get that desktop feature to my everyday screen session. I simply replaced the editor setting in my .muttrc with the following line:

set editor="screen -X select 1;emacsclient"

Now mutt tells screen to switch to window 1 (where Emacs is running) and then tells Emacs to open the appropriate file to edit my new mail.

Update Friday, 2009-04-24, 18:22

Even though Zack surely is right with his comment about the multi-terminal feature of the upcoming GNU Emacs 23, I still have Etch (and therefore GNU Emacs 21) on the server where I have my screen session.

So the next step was to switch back to the mutt window (window 2) after I’m finished with editing the mail. Since mutt gives the the file to edit as argument to the contents of $editor, simply adding ;screen -X select 2 at the end of $editor doesn’t suffice.

So I wrote a small shell script (named ~/.mutt/editor.sh) as wrapper which calls all the commands and passes the parameters to the right command:

#!/bin/sh

screen -X select 1
emacsclient -a ~/.mutt/alteditor.sh "$@"
screen -X select 2

Of course, $editor is now set to that script:

set editor="/home/abe/.mutt/editor.sh"

Emacsclient of GNU Emacs 21 already supports the -a option to call another editor in case of not being able to connect to a running Emacs instance. Since I don’t want to switch to another screen window in that case, I wrote a second shell script (named ~/.mutt/alteditor.sh) which switches back to the mutt window and then calls GNU Zile, my preferred low-end emacs clone:

#!/bin/sh

screen -X select 2
zile "$@"
screen -X select 1

I love it!