GNU Screen 4.2.0 in Debian Experimental //at 20:22 //by abe

About a month ago, on 20th of March, GNU Screen had its 27th anniversary.

A few days ago, Amadeusz Sławiński, GNU Screen’s new primary upstream maintainer, released the status quo of Screen development as version 4.2.0 (probably to distinguish it from all those 4.1.0 labeled development snapshots floating around in most Linux distributions nowadays).

I did something similar and uploaded the status quo of Debian’s screen package in git as 4.1.0~20120320gitdb59704-10 to Debian Sid shortly afterwards. That upload should hit Jessie soon, too, resolving the following two issues also in Testing:

• #740301: proper systemd support – Thanks Josh Triplett for his help!
• #735554: fix for multiuser usage – Thanks Martin von Wittich for spotting this issue!

That way I could decouple these packaging fixes/features from the new upstream release which I uploaded to Debian Experimental for now. Testers for the 4.2.0-1 package are very welcome!

Oh, and by the way, that upstream comment (or ArchLinux’s according announcement) about broken backwards compatibility with attaching to running sessions started with older Screen releases doesn’t affected Debian since that has been fixed in Debian already with the package which is in Wheezy. (Thanks again Julien Cristau for the patch back then!)

While there are bigger long-term plans at upstream, Amadeusz is already working on the next 4.x release (probably named 4.2.1) which will likely incorporate some of the patches floating around in the Linux distributions’ packages. At least SuSE and Debian offered their patches explicitly for upstream inclusion.

So far already two patches found in the Debian packages have been obsoleted by upstream git commits after the 4.2.0 release. Yay!

Updates (8th of May 2014): 4.2.0 in Testing, Upstream released 4.2.1

screen 4.2.0-2 migrated to testing now.

Upstream released 4.2.1 in the meanwhile with most Debian patches applied. Despite being a minor update, it was necessary to bump it’s internal message version, so vanilla 4.2.1 clients can’t connect to vanilla 4.2.0 servers. Accordingly it may take a moment until 4.2.1 hits Debian as I need to sort out some stuff before uploading that version.

Searching in Screen’s copy mode //at 23:43 //by abe

I’m using GNU Screen daily for definitely more than a decade and I became maintainer of Debian’s screen package nearly exactly two years ago. Nevertheless it still happens occassionally that I discover features yet unknown to me. Recently I had one of these moments again:

I looked for a specific line in the long output of a command which has run inside a Screen session. For that I entered Screen’s copy mode with Ctrl-A [ and scrolled around with arrow keys and page-up and -down keys.

But didn’t find it. I thought, it would be cool if I can search for the string I’m looking for. Intuïtively I typed /, the search string and pressed enter. And it worked! It jumped to the next occurrence of that string.

Of course I immediately had to check if tmux has such a feature, too. And it indeed has, but it seems to be a less sophisticated implementation:

Being able to do incremental search like with GNU Emacs gave me yet another reason for continuing to use Screen and not to switch Tmux. ;-)

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. ;-)