{"id":1585,"date":"2011-11-02T00:42:35","date_gmt":"2011-11-01T14:42:35","guid":{"rendered":"http:\/\/www.somethinkodd.com\/oddthinking\/?p=1585"},"modified":"2011-11-02T00:42:35","modified_gmt":"2011-11-01T14:42:35","slug":"abandoning-screen","status":"publish","type":"post","link":"https:\/\/www.somethinkodd.com\/oddthinking\/2011\/11\/02\/abandoning-screen\/","title":{"rendered":"Abandoning screen<\/code>"},"content":{"rendered":"

I am filing this under “I am doing Linux wrong, but I don’t know where.”<\/p>\n

I am connecting to Linux boxen via Windows.<\/p>\n

Rather than running an X environment, I am using ssh<\/code> to get a command line. I am using PuTTY on Windows.<\/p>\n

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.<\/p>\n

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

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.<\/p>\n

The rules of when Windows decides to run the screen-saver and when it decides to hibernate are a blackbox mystery to me.<\/div>\n

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.<\/p>\n

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

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.<\/p>\n

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.<\/p>\n

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

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?<\/p>\n

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

I came to the screen<\/code> 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<\/a>.<\/p>\n

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<\/code>, and you will back to exactly where you were. <\/p>\n

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

The trouble is that it has a few disadvantages too. But the one that kills me is that it confuses PuTTY’s history buffer.<\/p>\n

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.<\/p>\n

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

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. <\/p>\n

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.<\/div>\n

Today, I lost the results of my tests, again, and wasted about 10 minutes with a looming deadline. <\/p>\n

I have decided to abandon screen<\/code>, and am returning to having to re-login each day, with any long running processes killed unless I thought to nohup<\/code> them.<\/p>\n

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.<\/p>\n","protected":false},"excerpt":{"rendered":"

I have decided to abandon screen<\/code>, and am returning to having to re-login each day.<\/p>\n

I am filing this under “I am doing Linux wrong, but I don’t know where.”<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_s2mail":"yes","footnotes":""},"categories":[25,34],"tags":[366,365],"class_list":["post-1585","post","type-post","status-publish","format-standard","hentry","category-insufficiently-advanced-technology","category-software-development","tag-editors","tag-linux"],"_links":{"self":[{"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/posts\/1585","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/comments?post=1585"}],"version-history":[{"count":6,"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/posts\/1585\/revisions"}],"predecessor-version":[{"id":1591,"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/posts\/1585\/revisions\/1591"}],"wp:attachment":[{"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/media?parent=1585"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/categories?post=1585"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/tags?post=1585"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}