Dead Ink Vinyl » linux

Screen and my .screenrc file [UPDATED]

dlkinney — Fri, 10 Apr 2009 18:17:36 +0000

I was introduced to Screen — a terminal multiplexer — a couple of weeks ago. When I first tried it, I was mostly annoyed and set it aside. However, it came so highly recommended that I picked it up again and forced myself to learn enough that I could use it on a daily basis:

screen -ls (list screens)
screen -r (reattach)
Ctl-A c (new screen)
Ctl-A A (rename screen)
Ctl-A <num> (switch to screen)
Ctl-A d (detach)
Ctl-A M (monitor for activity)
Ctl-A _ (monitor for silence)

After getting those commands under my belt, I was very impressed and I use screen all the time now. However, a lot of Screen’s power comes from the customization of Screen through its startup files. Good information about startup files is scattered across the web, so I’ll share what I’ve put together.

Below is my ~/.screenrc file, compiled from the information at softpanorama, from Matt Cutts, from the Screen FAQ, and from the Screen manual’s command list. I’m using this on Ubuntu 8.10 servers over at Slicehost and on my MacOSX 10.5 laptop.

UPDATE: Added more comments around the termcapinfo setting that enables scrollbars to work as expected.

# For a complete list of available commands, see http://bit.ly/jLtj

# Message to display in the status line when activity is detected in a
# monitored window.
activity              "activity in %n (%t) [%w:%s]~"

# Detach session on hangup instead of terminating screen completely.
autodetach            on              # default: on

# When a bell character is sent to a background window, screen displays a
# notification in the message line. The notification message can be re-defined
# by this command.
bell_msg              "bell     in %n (%t) [%w:%s]~"

# This command controls the display of the window captions. Normally a caption
# is only used if more than one window is shown on the display.
caption               always          "%{= kw}%?%-Lw%?%{+b kw}%n*%t%f %?(%u)%?%{= kw}%?%+Lw%?"

# Select line break behavior for copying.
crlf                  off             # default: off

# Select default utmp logging behavior.
#deflogin              off             # default: on

# Set default lines of scrollback.
defscrollback         3000            # default: 100

# If set to 'on', screen will append to the 'hardcopy.n' files created by the
# command hardcopy; otherwise, these files are overwritten each time.
hardcopy_append       on              # default: off

# This command configures the use and emulation of the terminal's hardstatus
# line. The type 'lastline' will reserve the last line of the display for the
# hardstatus. Prepending the word 'always' will force screen to use the type
# even if the terminal supports a hardstatus line.
hardstatus            alwayslastline  "%{+b kr}[ %H ] %{ky} Load: %l %-=%{kb} %c  %Y.%m.%d"
msgwait               15

# Set message displayed on pow_detach (when HUP is sent to screen's parent
# process).
pow_detach_msg        "BYE"

# Set the default program for new windows.
shell                 bash

# Default timeout to trigger an inactivity notify.
silencewait           30              # default: 30

# Change text highlighting. See http://bit.ly/11RDGZ
sorendition           gK

# Do NOT display copyright notice on startup.
startup_message       off             # default: on

# Set $TERM for new windows. I have more luck with 'linux' than Terminal's
# default 'xterm-color' (^H problems). Comment out to use the default.
term                  linux

# Tweak termcap, terminfo, and termcapinfo  entries for best performance.
termcap               linux           'AF=\E[3%dm:AB=\E[4%dm'
termcap               xterm-color     'AF=\E[3%dm:AB=\E[4%dm'
terminfo              linux           'AF=\E[3%p1%dm:AB=\E[4%p1%dm'
terminfo              xterm-color     'AF=\E[3%p1%dm:AB=\E[4%p1%dm'

# Allow xterm / Terminal scrollbars to access the scrollback buffer. This
# enables the behavior you'd expect, instead of losing the content that scrolls
# out of the window.
termcapinfo           linux           ti@:te@
termcapinfo           xterm-color     ti@:te@

# Use visual bell instead of audio bell.
vbell                 on              # default: ???

# Message to be displayed when the visual bell is triggered.
vbell_msg             " *beep* "

Posted in Community, Development, Training Tagged: gnu, linux, macosx, screen, screenrc, sysadmin, terminal, unix

Opinionated – Part 1 of 3

dlkinney — Sun, 16 Mar 2008 17:45:20 +0000

It is important that you understand that I strongly believe in opinionated software. I view this as a logical extension of the UNIX philosophy. The best software I’ve used has been produced by someone having strong vision and a confidence to so “no” to distracting features. Software agnosticism—trying to be all things to all users—is the long slide to gone.

But, don’t mistake my belief in opinionated software to mean that I like the opinions of all opinionated software.

For example, Git is very opinionated software, but I don’t care much for it. Git was created to solve a specific problem, and consequently Git values strong support for non-linear development, distributed development, efficient handling of large projects, and fast merging of patches from email. As it turns out, my source code management needs have almost zero overlap with those features so Git is not a good fit for my development workflow. I recognize that those features are important to many projects, but they aren’t for me. Git can be exception at what it does because it doesn’t compromise to try to meet my needs, too.

And here’s the best part: I don’t have to use Git. If it’s opinions don’t mesh with mine, we can agree to disagree and I can choose a tool better suited for my needs. Some commentators seem to miss this point. Opinionated software doesn’t preach “one true way”, it says “my way or the highway”—if my software doesn’t work for you, you’re free to find another solution that does work for you. (In the open source forums, this sentiment is echoed as “if you don’t like it, then fork it or build your own”.)

Java on Leopard The Final Word

dlkinney — Fri, 02 Nov 2007 02:28:32 +0000

I was going to stick my nose into the “Java on Leopard” rant fest just to point out to hardcore Mac users that the platform received a lot of help and validation from Java developers who migrated from Linux. I was going to say other really insightful and inspiring stuff, but Ted Leung beat me to it and made all the right points just perfectly. I have nothing to add — just go read Ted’s article.

NSLU2 as Linux Servlet Server

dlkinney — Mon, 21 Mar 2005 06:00:00 +0000

With my new, static IP addresses, I’ve started kicking around the possibility of running a public server. I don’t know for what exactly I’d run the server. Possibilties include running Subversion, an OpenLaszlo project gallery, an Echo2 project gallery, or a Confluence knowledgebase for the Echo community. Since I don’t need to run a server — I just want a server — I don’t want to spend a lot of money. In fact, I want to spend as little money as possible.

I donated all of my old computer equipment to a local school system last year, so a new server means new kit. Thinking of a Linux server, I looked up Dell‘s offerings, since I get an employee discount with them. It would be $420 + shipping for the lowest-end box they offer. That’s close enough to the price of a Mac mini (with my employee discount) that I seriously contemplated that angle. Still, the $400+ price range is more than I want to invest in this project at this time.

Then I recalled that the Linksys NSLU2 can be hacked to upgrade its Linux kernel and services. I want to keep my current NSLU2 as a file server for my home network, so I would need a new NSLU2 ($80) and a small, external USB2 hard drive ($80). That’s more in line with my price range. Looking over the NSLU2-Linux sites, it certainly runs Web servers serving static content just fine. But does it run Java?

The NSLU2 runs on an Intel IXP425 Xscale CPU. I was unaware of any Java runtimes for the processor until I came across Kaffe. This is not the first time I’ve heard of Kaffe, but it is the first time I’ve seriously considered it. This thread indicates that the newest versions (1.1.4) should build on NSLU2-Linux. Kaffe’s compatability reports indicate that it should be suitable for server-side applications. Intrigued, I dug further and found some hope that Tomcat will run on Kaffe with minimal tweaking.

So I’ll sleep on it a while and revisit the idea of setting up a Servlet server on an NSLU2 “soon”.

No Luck With ext2fsx

dlkinney — Mon, 21 Mar 2005 03:15:00 +0000

I should share that I did not have luck using ext2fsx (ext2 support for MacOSX) to read my drive formatted (as ext3) by my Linksys NSLU2. However, other people report success using this utility for this purpose (see batbox.org on 10-Jul-2004), so I may have been hasty. In the “I just want it to work” mentality into which I’m growing, I gave up and plugged the old drive and new drive into the NSLU2 and let it do the synchronization. The old drive lasted long enough to get its contents copied off, but the noise was teeth grating.

I have left the extension installed on my laptop and have not suffered any instability or problems as a result. And I like the idea of being able to read Linux partitions from my laptop in a crunch.

KNOPPIX, MacOSX, NSLU2

dlkinney — Sat, 05 Feb 2005 23:05:00 +0000

Let me get right to it: do not purchase ACOM Data hard drives! I picked up two USB2/Firewire 80GB 7200RPM drives very inexpensively at CompUSA about a year ago and I can say that the fans used are incredibly shoddy.

I had the drives hooked up to my LinkSys NSLU2 NAS controller. I love the NSLU2. It’s a sub-$100 NAS device that provides permission-based SMB (Windows file sharing) access to two USB2.0 hard drives. It is very small, runs Linux, and is very easy to control.

Anyway, I had the two ACOM Data drives attached to the NSLU2. I didn’t trust the drives, so I setup the NSLU2 to use one as a backup drive for the other. I dumped all kinds of content onto the NAS to be shared between my Dell (WinXP) and PowerBook (MacOSX) computers. Since both computers are locked-down and running their own firewalls, it’s next to impossible to get them to share files directly. Thus, the NAS filer is a very nice solution.

The fan died on the first ACOM Data drive several months ago. Cracking the hard drive’s case is next to impossible without breaking everything (it’s all plastic without screws), so left the drive for dead. A month ago the other drive’s fan gave out. I picked up a nice LaCie drive to replace the two ACOM duds. Now I attempting to get the data off the old drive and onto the new one.

Here is where the Linux under-pinnings of the NSLU2 became a liability. The NSLU2 uses the EXT3 filesystem common to Linux. It’s a great filesystem, but I happen to no longer have a Linux workstation or server in my residence. I could plug both drives into the NSLU2 and use its interface to copy over the contents, but I would like more fine-grain control over the process to copy the most important content first. That’s the degree to which I distrust the ACOM Data drive lasting through the operation.

I thought I was in good shape because I have a KNOPPIX 3.7 CD. I’d never used it, but I’d read such good things about it… Well, it doesn’t boot on my Dell box. It gets past the LILO prompt and starts recognizing hardware, but it quickly kernel panics that it cannot read init. Hmph. I’m grabbing build 02 of 3.7, which may work better. In the mean time, I am fanning the flame of hope that I’ll find a way to read EXT3 under MacOSX. I’m giving Mac OS X Ext2 Filesystem a shot.