Stupid terminal tricks

Posted by Michael Giarlo on June 08, 2008

Sometimes I find it useful to keep long-running processes in a session of screen.  And sometimes I launch one of said processes outside of screen, and then I yell something like "doh!" or an expletive, because, as I said, I do find screen useful.  Depending on how far the process has gotten, whether it was the sort of operation that would not run happily again, or how much cleanup a second run would require, I either kill the process and restart it or I suspend it with Ctrl+z and send it to the background with bg % so that it doesn't die when I log off.  The latter is a decent option.  But, darn it, I like screen.

Well, perhaps I'm the last to know, but there's this neat little tool called retty that allows you to attach running processes to your terminal.  I installed it in Ubuntu Hardy the typical way (sudo apt-get install retty).  So, the next time I screw up, I'll Ctrl+z, bg it, and then screen retty {PID}.  Voila!

Hiccup-y Hardy Heron

Posted by Michael Giarlo on April 29, 2008

In spite of how irksome I find "oh hai i upgrayded!" posts, I'm about to be guilty of same.

I upgraded my Optiplex GX620 from Gutsy to Hardy yesterday afternoon and it seemed to go as smoothly as it did on my HP box at home.  All looked a-okay this morning until, upon returning from a meeting, my display was all funky and jerky and laggy.  The right edges of my windows were uniformly screwy — I would have to click about an inch to the left of whatever I wanted to click on — and the right and left edges of the screen caused visual trails when I dragged windows around.  (And this has nothing to do with my usual breakfast of bacon and psychedelics.)  This wasn't the first time I've run into problems with compiz/beryl and Ubuntu and so I was hopeful that things could be easily remedied.

I was still able to get around a bit and I found a Hardy installation guide that fixed me all up (I hope).

I should probably note that the Optiplex in question has an ATI Radeon X600 series video card.

Pining for the visual trails,

Mike from Arlington

P.S. Ubuntu, I still ♥ you.

Using Linux to fix Windows

Posted by Michael Giarlo on October 13, 2007

The hard drive on my laptop is slowly failing and a combination of being busy, lazy, and cheap is preventing me from replacing it. About once every two weeks over the past couple months, one of the Windows registry files becomes corrupted and the XP disk is unable to repair it. And the HD fails basic manufacturer-provided diagnostics. But I'm stubborn. So I've been routinely resuscitating this box and I decided to post the process I use.

If you boot and see a message like

Windows could not start because the following file is missing or corrupt
C:\windows\system32\config\system

then you may be interested in this.
Continue reading…

Managing Services: From Red Hat to Debian

Posted by Michael Giarlo on April 19, 2006

A note for Linux sysadmins who're scouring Google for answers to this issue: 

Having administered Red Hat servers for years at prior places of work, I'd gotten quite used to doing things the Red Hat Way™, e.g., using the chkconfig and setup tools to manage services and the runlevels at which they are enabled.  These tools apparently aren't used in Debian, which is the preferred distro at MPOW.  Instead, I've used update-rc.d and rcconf, respectively, to manage services on Debian.  They work similar to the aforementioned Red Hat tools, but I'm not yet that familiar with them; I'm inclined to say that the RH tools are more intuitive to use, but I may have some recall bias.

 

Home and End keys – PuTTY – bash – Linux

Posted by Michael Giarlo on November 30, 2005

Here's a simple one. But first, some backstory.

I'd been using the tcsh shell on my Linux servers for years, but I am now working in an environment where bash is the preferred shell. I view it as an opportunity to poke around in a shell that's relatively unfamiliar to me as a dyed-in-the-wool tcsh user[1]. I'd also been used to connecting to my Linux servers with the SSH Communications Security version of the Secure Shell client. Unfortunately, the newest version of this client, which is available to me, will not connect to our department's boxes due to the version (or configuration) of the OpenSSH libraries that have been installed. I'm new to this job, so I'm accepting this more or less on the authority of comments made by coworkers; I haven't independently verified this, though I can confirm that I can't connect with the SSH client. I switched to the PuTTY SSH client, since it's free, widely used, and supported by my colleagues. And, oh yeah, it connects to our Linux boxes.

One of the neat features of the SSH Communications Security client is the ability map keys to certain other keys. For instance, I used to map the Home and End keys to <Ctrl-a> and <Ctrl-e> for ease of navigation on the command-line; sometimes the command strings I have to type are, to put it technically, really frickin' long and it's nice to be able to make edits to the beginning and end of these command strings without holding down the left and right arrow keys for an hour. PuTTY does not have a key-mapping feature, so I was wondering how to get my Home and End keys to do more than just generate the '~' character. (Though such a feature is on PuTTY's wish-list.)

It turns out there's a simple fix: just set the environment variable, TERM, to the value of "linux" in ~/.bash_profile (or .bashrc).

export TERM=linux

should do the trick. Make sure you logout and login again, or just source your bash config files. It's possible that other TERM values do the trick as well, but "linux" has worked for me. Prior to that, the TERM variable was set to the value "xterm".

For some more shell-based key mapping geared toward the Backspace and Delete keys, see the Consistent BackSpace and Delete Configuration page.

1. While I've used tcsh as my default shell for years, I do acknowledge the argument that csh programming is considered harmful. I use the Bourne shell and Perl for scripting, though primarily the latter.