OddThinking

A blog for odd things and odd thoughts.

Abandoning screen

I am filing this under “I am doing Linux wrong, but I don’t know where.”

I am connecting to Linux boxen via Windows.

Rather than running an X environment, I am using ssh to get a command line. I am using PuTTY on Windows.

Originally, I was getting disconnected by one of the Linux machines if I walked away for an hour. Eventually, I taught PuTTY to send keepalive messages, and that problem stopped.

I’m not sure why some Linux versions timeout on this. Shouldn’t the living TCP session be enough to hold open the session?

All was good for a while. Then I finished running batch processing jobs all night on the Windows box, and the Windows automatic hibernation started cutting in, to save power.

The rules of when Windows decides to run the screen-saver and when it decides to hibernate are a blackbox mystery to me.

Now, when the Windows machine woke up, the PuTTY application was still running, but the TCP session had expired. PuTTY tries to be helpful about continuing to show the session information, but it is still confusing to have these old windows open that look ready to take input, but beep when you type.

I was living with this need to reconnect each day, for a long time. Then I started using virtualenv, to allow me to separate the Python environments that I used for development, for the production system and for applications directly using the OS.

Now, I had a command I had to run each time I connected. If I didn’t run it, I would get random errors as slight differences in Python versions and available libraries caused problems.

I added some version checking in some of my key long-running programs, so they die immediately and loudly if I forget, but I wanted to make this simpler.

If I could avoid it, I didn’t want to put virtualenv in my start-up scripts – I’d prefer nothing too complex in there, in case they start causing login problems. virtualenv depends on a directory that gets periodically deleted and rebuilt – it might not be present and correct at login time.

I considered if I could simply turn off the need for keepalives, so the session could continue even after 18 hours of silence, but the TCP connection would be broken too, right?

Can I tell Linux to re-establish an SSH session, even if after the TCP connection is lost? I couldn’t find a way.

I came to the screen command, which had been recommended to me before, and I always shied away from as it appeared to be a whole IDE just to control a terminal-shell. The last thing I want to learn is another bloody set of keyboard shortcuts for a command line tool.

Its big advantage is that it spawns a long-running process, that you can reconnect to. If you get disconnected, simply log in and run screen -R, and you will back to exactly where you were.

Well, I actually run screen -d -RR, because it is idempotent. Otherwise, I was discovering I had many screen processes running at the same time. More precisely, I run !scr to avoid getting the options confused again.

The trouble is that it has a few disadvantages too. But the one that kills me is that it confuses PuTTY’s history buffer.

If I run my unit-tests, I get about 300 lines of output – each line includes the test suite and the word “OK” in green. That’s if they all pass. If any fail, the output is much longer, and includes some choice words in red. So when I run my tests, I come back to check the output, only to find that all but the last few lines have been forgotten by the screen command.

I can’t tell if the tests have all passed, so I have to run the tests again, this time piping through less or more – both of which handle the colour-coded text badly. (The less command converts them to visible characters, the more command double-spaces the lines.)

Apparently the screen command includes the idea of scrolling back through a “scrollback buffer”, but not by using my scroll-wheel! By learning some arcane new commands – not even emacs-like, but vi-like.

I find the whole emacs versus vi preferences argument to be tiresome and pointless. I try to avoid such religious wars. But you need to understand my reasons for keeping above the fray. It is because the users of modal editors, like vi, are just too stupid to understand the truth! You can have my modeless editing when you pry it from my cold, dead, and twisted-into-a-weird-shape-to-reach-the-shortcut hands.

Today, I lost the results of my tests, again, and wasted about 10 minutes with a looming deadline.

I have decided to abandon screen, and am returning to having to re-login each day, with any long running processes killed unless I thought to nohup them.

My requirements are not unusual. I am a developer with a need, and if Linux is good at anything, it is good at having met those sorts of needs. I wonder where I am going wrong.

5 CommentsCategories: Insufficiently Advanced Technology,S/W Dev
Tags: editors, Linux

Comments

  1. Try dtach instead. It does far less than screen, in particular, it has no terminal emulation. If you lose the connection, whatever was previously on screen is lost – if you need it, you have to arrange to save it. To me that is a feature. What it does do is keep a process alive and allow you to reattach to its output – which is all I need. This specifically ensures that there is no difference to terminal behaviour with or without dtach – whether that concerns scrollback, charsets/encodings, or anything else.

    You can also ask less to pass terminal escapes through using the -R switch. (There are also other switches to change its exact behaviour. Try using man on it sometime, that’s a pretty cool command. 😉 (Not always. I know too well.))

  2. reptyr might also fit your needs.

    Haven’t tried it myself, though. I persist with screen. I found it (screen) a lot easier to use after rebinding the meta key to backtick. But yes the scrollback buffer is still weird.

  3. Use a mac I hear there really user friendly.

  4. Have you tried using http://www.bitvise.com/tunnelier ?

  5. This might be worth a look, if you’re still having this issue – http://mosh.mit.edu/

    “Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes.

    Mosh is a replacement for SSH. It’s more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.”

Leave a comment

You must be logged in to post a comment.