Casey Brant's Blog

Posting again. New location.

2010-03-03T11:30:00.000-08:00

Hey, there are some major changes coming up in my life, and I'm gonna try to start blogging again now that I have some things to talk about. If you're subscribed to this one and want to keep following me, head over to my new one at this location.

The Math

2009-08-28T10:47:00.000-07:00

Recently, several Systems employees at my company have received stern emails berating them for their abuse of the H: drive (our personal network storage space). Thinly veiled and unverified accusations of CoC breach aside, the message is simple: you're using too much space.

OK, fair enough -- you set a quota, I went over it. It's as easy to fix as me deleting all the things I was backing up in case of hard drive failure. Problem solved. So what is the quota? According to the emails, 300MB. That doesn't sound like a lot to me, but the email did say that SAN space is "at a premium."

"At a premium?" I thought I read somewhere that the cost of storage had been falling for a while now. Hey, I know! We're geeks; let's do some math.

You can't buy a 300MB hard drive in 2009, but a quick search of NewEgg.com got me a 320GB SeaGate external drive for about $80.

It costs $9 for a 6-pack of Scott toilet paper. The average American office worker uses a roll every two weeks. If we assume a 50-week year, that's 25 rolls per employee per year. Adjusting for the fact that we're buying in bulk (and it ain't the nice stuff), that works out to something like $18 per employee per year for toilet paper.

Back to the hard drive. 320GB is a heck of a lot; we could split that up amongst, oh, let's say 32 people. And just so we're comparing apples to apples, let's say a SeaGate drive will wear down and need replacing after one year of use. So, 10GB each at a cost of $2.50 per employee per year.

So for about 1/7 the cost of toilet paper, we could afford to increase every single employee's H: drive by a factor of 30.

Or can we at least start buying nicer TP?

UPCRC Parallel Computing Seminar

2009-06-26T08:51:00.000-07:00

I'm just finishing up the last day of a week-long parallel computing class at UIUC. It's gonna take me a few days to review everything for a full writeup, but it was an awesome class! Many thanks to the excellent professors, lecturers, and organizers that made this such a great week (and extra special thanks to my good friend JoAnne, who told me about its existence in the first place and helped get me signed up).

Hack Day

2009-04-03T13:13:00.000-07:00

I think I'll write more often if I let myself post things that are shorter and less edited than I've been doing. Let's test that theory.

My company has decided to sponsor a Hack Day next week. There's been a lot of internal talk the last few years about how to start modernizing our Systems department and attracting/retaining younger talent. I think this is one good way to do it.

The idea is modeled after Yahoo!'s hack days. You form into small groups, grab some laptops, load them up with whatever stuff you want, and code a quick proof of concept for something you think would be cool for the company to have. At the end of the event, everybody gives an informal demo to a crowd of other participants and managers. There will be pizza and drinks. I think maybe some voting -- everybody likes voting.

My team's working on getting our stuff set up at the moment. The bulk of the actual coding will be done this coming Wednesday during the real event, but we're getting everything in place and doing a little design ahead of time so there's less friction to overcome once we get down to business.

I realize that Hack Days have been around for a while, but my company is pretty conservative, and this is a big step for it. It's out of character for them to be so loose with an event like this. We were given factory stock laptops to work on (no corporate restrictions), we get non-firewalled Internet access, and we can install just about anything we want on them (Legal has to approve, but they've been extremely accommodating so far), even Ubuntu!.

Like I said, nothing remarkable for the tech industry at large, but I'm really happy that we are finally willing to start moving in this direction. It makes me actually kind of believe in some of the rhetoric about modernizing our department I hear from upper management.

still alive

2009-03-29T18:07:00.000-07:00

I'm not sure how many people are following this, but I just wanted to drop a quick note to say I'm still alive, and I still plan on coming back to both 52in09 and general blogging. I've been pretty unproductive lately for a number of reasons, but I'll be back on top of things pretty soon here.

Stay tuned!

Emergency vi

2009-02-13T16:38:00.000-08:00

Text Editors

One of the most important tools of a serious Unix user is their text editor. Almost all system configuration on Unix is done with plain text files, so having a sharp tool for dealing with text is a must.

Beyond system administration, most of the computing we do on a daily basis involves plain text. Programmers edit text in the form of source code, writers spend lots of time editing and tweaking manuscripts, and anyone who works in an office knows how much time email takes up.

Because text plays such an important role in computing, it only makes sense to have powerful tools for working with it. Someone coming from a Windows environment might have never thought about their editor before -- it's a bit of a shock the first time they step away from Notepad! But incredible programs exist that can improve the way you interact with text, and it's worth your time to get familiar with one of them, regardless of your job or responsibilites.

vi

what is it

'vi' is one of the most venerable Unix programs. It has a strange interface, and its behavior will seem downright wonky to someone coming from Notepad, but this strangeness is the result of an ingenious approach to editing that many users swear is the only right way to do it. Once you get over the shock, vi is a powerful tool that can change the way you use your computer.

why you should know it

-It's Everywhere-
With so many text editors available, why did I pick vi for this article? The reason is that it's everywhere. If you're on a Unix system, you have access to vi. This matters because if you're efficient in vi, you can quickly and effectively edit text on any system, even one you aren't used to.

It's perfectly fine to focus on a different editor for daily use, but without some vi fundamentals under your belt, you're liable to end up lost and confused on an unfamiliar system.

-Common Keybindings-
Because vi has been around for so long and is so popular, lots of other programs copy some of its shortcut keys for similar functions. The next 52in09 post is actually going to be talking about one of the most common of these: less.

Modes

vi's modality is what throws off most new users. In Notepad and most other text editors, you're always able to input text. If there are shortcut keys to do anything special, they're usually activated by "chording" -- pressing a letter and CTRL or ALT (or another modifier key) at the same time.

In vi, the special functions are often just single key presses, but the current mode of the program determines the result. In INSERT mode, for example, typing on the keyboard just inserts text like you'd expect. In NORMAL mode, on the other hand, all of the keys are mapped to other functions like navigation, cut/paste, deleting, etc.

vi has several modes, but we'll only be mentioning three in this intro: NORMAL, INSERT, and VISUAL.

vi Survival Kit

vi is an advanced and powerful text editor, which means it has thousands upon thousands of features and abilities. People who have been working with vi for decades still haven't mastered the whole editor.

This shouldn't be cause for alarm, however. To be pretty handy at vi, you only need a small subset of features based on what you use the most. And to get off the ground initially, you only need a handful of commands (the ones I'm about to teach you, conveniently enough!).

When you start the editor, you'll be in NORMAL mode. You can't enter new text from here, but this is where all the most used editing commands are.

movement

To move around, use the 'h', 'j', 'k', and 'l' keys for left, down, up, and right, respectively. This is pretty awkward at first, but once you're used to it, it will feel natural.

To help remember the mappings, think of it this way: 'h' and 'l' are on the far left and right sides of the group, so that's easy. 'j' dangles _down_ below the line, and 'k' stretches _up_ to the next line.

INSERT mode

Press 'i' to enter INSERT mode. This is how you type new text. Press ESC to return to NORMAL mode for editing.

deleting

In NORMAL mode, 'x' will delete a single character under the cursor. 'de' (that is, press and release 'd', then press and release 'e') will delete from the cursor to the end of the word, and 'dd' will delete the entire line your cursor is currently on.

quitting and saving

At this point, you've got pretty much the same capabilities as Notepad. To quit vi, while in NORMAL mode type ':q' and hit 'ENTER'. If you've changed the file, vi will complain. ':wq' will save and then quit, or ':q!' will discard changes and quit.

undo / redo

'u' in NORMAL mode will undo changes. CTRL-r will redo.

copy (yank) / paste (put)

When you delete a line with 'dd', it is saved in a buffer. To insert that text somewhere else, type 'p' (vi's word for "paste" is "put"). If you want to copy some text without deleting it, you can "yank" it. 'v' will enter VISUAL mode, use the movement keys to highlight some text, then press 'y' to yank the text and return to NORMAL mode.

searching

To search for text, type '/' while in NORMAL mode. The cursor will jump to the bottom of the screen, where you enter your search term and press "ENTER". To search for the next occurance of your term, press 'n'. To search backwards press 'N'.

find/replace

If you need to make a lot of similar changes to a file all at once, use find and replace. In NORMAL mode, type ":s/old/new/g" to replace all instances of 'old' on a line with 'new'. If you'd like to do this for the whole file, type ":%s/old/new/g".

learning more about vi

At this point, you know enough vi to get by. Since I use a different editor for my day-to-day work, that's actually about all I know. If you've tried out some other editors and still feel most at home with vi, you'll want to start learning a lot more about how to use it effectively. Here are some resources:

vimtutor

If you're using Vim instead of vanilla vi (and if you aren't, you should be), running 'vimtutor' from the command line will give you a more thorough tutorial than this post, with opportunities to practice the commands as you learn them.

vim website

http://www.vim.org/docs.php
This page has links to a couple of books about Vim, as well as the official complete documentation.

Learning the vi and Vim Editors

http://oreilly.com/catalog/9780596529833/
A great dead trees book, and it includes info on classic vi as well as Vim (why are you using old vi? What did I tell you about that?)

Picking an Editor

Find one you like and master it

vi is featured here because of its importance to Unix systems. Please don't take that as an endorsement of vi as the "best" text editor. The truth of the matter is that there is no such thing as a "best" editor. Everyone thinks a little differently, and editors are like any other tool: certain brands will fit a given user, and others won't.

After you've learned enough vi to survive, I'd recommend checking out some other editors for a couple of weeks at a time, and find one that really thinks like you do. If you have a sysadmin who cares about your well-being, you should be able to convince them to install your favorite on the system you're using.

The important thing to remember about editors isn't which one is best, it's that you need to pick a good one and get really comfortable with it. Since so much of the workday involves text, it is essential to your happiness that you are able to manipulate text with ease and power.

other choices

-Vim-
vi is very old, and there are lots of clones/improvements of it. Vim is the most popular of these. It offers much more power than basic vi, but it still retains the flavor and most of the keybindings of the original. If you enjoy working with vi, I strongly recommend upgrading to Vim and learning some of its more modern and powerful features.
-Emacs-
Emacs is considered by many to be the only other editor worth mentioning alongside vi, and there is a classic holy war about which one is superior. I personally am a big Emacs fan, and I use it for several hours daily. It really fits the way I think. After you check out vi for a while, I'd recommend spending a few weeks with Emacs to see if it's more your style.
-Others-
While Vim and Emacs are the big players today, there are still lots of other popular choices. TextMate is huge in the Mac community, but unfortunately it's only available for that platform.

Pico (and its clone, nano) is a Notepad-esque basic editor that's good if you get hit in the head and can't remember how to use vi.

gedit and Kate are good graphical editors for the GNOME and KDE Linux desktop environments.

JOE is a solid choice if you tried Emacs and liked the idea, but it hurt your hands too much.

52in09 Week 3: bash builtins grab bag

2009-02-03T19:07:00.000-08:00

Intro

The "shell" is what you use to interact with your computer. It's a layer the operating system provides so that humans can get things done without having to worry about low-level things like memory management and hardware control. In Unix, you have a choice of shells. This choice might be made for you by an administrator, or you may get to choose your own.

One of the most popular Unix shells is 'bash'. It's the default for mainstream Linux distributions like Ubuntu, and it's what most people I know use. There are other shells that are just as good, but since bash is so common, it's probably the easiest to get help for. There are piles of literature about bash, so today I'll just be covering some of the basics.

I mentioned in a previous post that the Unix philosophy encourages having a system composed of special-purpose utilities that do one thing well. It's hard to maintain this conceptual purity in the real world, and as it turns out, there are a few tasks that are difficult, slow, or impossible to do in a separate program. The shell handles these things for you.

These operations are called 'builtins' because, well, they're built in. One of the things that differentiates shells is what builtins they provide. Some of the operations don't actually need to be a builtin; they could have been a separate utility, but for performance (or other) reasons they are included.

My version of bash has 56 builtins, and they're all useful in their own way. Until you get into writing complicated shell scripts, though, there are only a few that you really need. We'll be talking about a handful of indispensible builtins today.

Moving around

pwd stands for Print Working Directory. Type this to find out what directory your shell is currently looking at. Many default bash installations will default to displaying your working directory in the prompt, so I don't use this command all that often.

cd <DIRNAME> (Change Directory) will change your working directory to <DIRNAME>. Type it without any arguments to return to your home directory.

Now here's a handy one. Once you get comfortable with cd (which should hopefully take about 2 minutes), you'll probably start to wish for a faster way of getting around. pushd and popd give you the ability to save "shortcuts" to various locations.

The most common use case goes like this: You're in a location <OLD_LOC> and you want to cd to <NEW_LOC>, but you know you'll need to come back to <OLD_LOC> soon. Like all good Unix users, you're incredibly lazy, and the thought of typing that whole path out makes you feel tired and cranky. Instead of typing cd <NEW_LOC>, type pushd <NEW_LOC>.

Now you're in the new directory, but you've given yourself a secret escape route back to the original spot. Once you're done in <NEW_LOC>, type popd and you'll be magically warped back to <OLD_LOC>. Simple!

You can actually use pushd several times in a row. Each time you use it, you add another directory to the stack of shortcuts. popd will return you to directories in the order of most recently visited. If you forget where you've been, type dirs. You'll get a list of directories on the stack, with the leftmost being your current position.

echo

echo <SOME_TEXT> just prints <SOME_TEXT> to the screen. Whee. It's useful in shell scripting, though. Also, there's a neat trick you can do to edit a file without opening it up. echo <SOME_TEXT> >> <FILENAME> will append <SOME_TEXT> to the file named <FILENAME>, or create it if it doesn't exist.

Bash control characters and output redirection are beyond the scope of this post, but they're integral to quite a bit of Unix magic. Watch an experienced user for more than 5 minutes, and you'll probably see them do something sneaky with pipes or input/output control.

job control

Unix was one of the first multitasking operating systems, and it remains very strong in that area today. My favorite way to run multiple programs at once is with screen, but a simpler method is to simply send a process to the background. If you're about to run something that you know will take a while, append the '&' symbol to the command line and it will start in the background. It will run there until it is finished. The jargon for this technique is called "amping out" a process (from a shortening of "ampsersand").

Type fg at the command line to bring a background process back to the front. If you've got more than one thing running in the background, use fg <NUM> where <NUM> is the background process number.

kill <NUM> will stop the operation of background process with number <NUM>. Use this to stop runaway jobs that you can't find nicer ways to stop.

There are lots of nifty keyboard shortcuts and other arcane job control commands. Some of them are builtins and others are separate utilities. About the only thing you can count on is that these operations will vary from place to place. Always make sure you have a local wizard nearby when messing around with job control.

Beyond builtins

Unix shells are highly "scriptable". This means that in addition to being your interface into the system, they're programming language interpreters. Bash has a full-featured and easy to learn (at least for the basics) language built into it. This doesn't really fit into the category of "builtins" and it's certainly way beyond the scope of 52in09, but this seemed like a good place to mention it. There are plenty of books and articles that are required reading for any serious intermediate to advanced Unix user.

shopt stands for "shell option", and it's a builtin that lets you toggle various environment settings. You can dramatically alter the behavior of your shell with shopt. There's a lot to it, and I only know the basics myself -- I might do a "customizing bash" post sometime in the future. If that wizard is still around from when you were playing with job control, ask them about what kind of shopt settings they like.

Conclusion

We've just scratched the surface here. There are several more builtins available, and they're all useful for something, even if it's not apparent what at first glance. This basic set should get you up and running though, and give you more of a taste for the power of the command line.

Additional Reading

Bash is an incredibly complex piece of software, but it's easy to be productive with just the basics. Once you're comfortable, though, you'll want to start seeing what other kinds of damage you can cause. The hallmark of a good Unix user is that they are always coming up with new ways to break things.

- Official Bash Reference Manual
- Bash Guide for Beginners
- Learning the bash Shell
- And of course, the man pages!

Totally Lame

2009-01-26T17:54:00.000-08:00

I fail. I got sick over the weekend, and was still kinda groggy today, so the 52in09 post is delayed a couple of days. It'll be up tomorrow sometime, but it might not be the highest quality. I think I'm going to reserve the right to go back and edit these later to improve on the sucky parts.

Also, I think I'll whip up a quick bonus post around Thursday-ish, partially as penance for missing the last deadline and partially because there's a topic I want to hit that's too big to squeeze into another topic but too small to warrant its own week.

Anyway, that's the update. See ya tomorrow if I don't catch the plague again :)

The Real Purpose of 52in09

2009-01-19T11:13:00.000-08:00

Well, only two weeks into the challenge and I'm already changing the rules. I originally posted that the purpose of 52in09 was to dig deeply into a set of 52 Unix commands and report on my findings. This would seem to imply that I'd be coming up with lots of crazy, obscure arcana about various utilities, maybe doing some source diving, and engaging in various and sundry wizardly hijinks.

As it turns out, of the two writeups I've done so far, approximately exactly 21.8% follow this guideline. Yesterday's post wound up being more like a tutorial for new users than a deep dive into the inner workings of 'man', and the 'screen' writeup was sort of a mutant hybrid tutorial/tricks guide.

Another revelation is that I really enjoyed writing both posts in different ways. So I guess what this means is that the true purpose of 52in09 is still kind of a mystery to me. Is it a Unix tutorial? A collection of nifty tricks? I don't really know yet.

I do know that I'd like to eventually edit the whole set of posts so that they fit together in a more coherent way than just a pile of unrelated articles (in the olden days, they called this a "book"). But I don't think I'll really know what kind of book that's going to be until a few more months have passed.

In the meantime, I hope you're enjoying the writeups, and I hope you'll bear with me as I flail about without a good grip on whatever it is I'm doing.

Tune in next time as we ...do...something...or whatever! And things!!

52in09 Week 2: man

2009-01-18T15:37:00.000-08:00

Intro

Last week was a fun way to kick off the 52in09 series, but if the point is to introduce a basic set of Unix commands, 'screen' is hardly the best place to start. Today we're going to get back to the basics and take a look at the first command any new Unix user should learn: man.

Unix systems come with an excellent set of manuals, and 'man' is the program that helps you read them. They are designed to be complete and authoritative; rare is the occasion that you have a problem with a command and can't find the answer in the man page.

If man pages are so helpful, then why do Unix tutorials like this one even exist? It's because most of the time, man pages were written to be as terse as possible. Ultimately, this is a good thing: it means experienced users will be able to get the information they need right away. However, the terseness can leave new users a bit bewildered. So, things like 52in09 exist to point you in the right direction. Once you have some idea what to look for, the man pages will be a lot more useful.

That's It?!

'man', like many Unix programs, is capable of more functionality than you'll usually need. The majority of the time, all you have to know is man <TERM>, where <TERM> is the name of what you'd like to look up. This pulls up the first page man can find on that topic.

The man page will open up inside a program called a "pager", usually 'less' or 'more', for easier reading. I'll talk more about pagers in a future post. For now, all you need to know is that the arrow keys will move around the page, and 'q' will get you back to the command line.

Most of the information presented to you by man is self-explanatory. Note that the manuals encompass more than just commands (there are also man pages for configuration files, for example), so the layout of all pages will not be exactly the same -- sections will be absent or present as appropriate. In general, though, the look of the manuals is consistent, so you'll be comfortable once you've seen two or three.

The SYNOPSIS is usually near the top. This section shows the various ways you can string together the options for that command. This part can get pretty indimidating (at least it was for me) if there are a lot of options, but after you've muddled through the arcane syntax a few times, it will make perfect sense.

The DESCRIPTION section is the meat of most man pages. Here, you'll find out everything there is to know about different ways you can use a given command.

apropos and whatis

There are lots of command line options and configuration settings that you can use with 'man', but most of them can be safely ignored unless you run into a bizarre problem. Of the ones you should know, man -k <TERM> is the most useful. If you don't know the exact name of the utility you need, use man -k <TERM> to search through the manuals for <TERM>. You'll get a nice list of all the matches, along with a brief description of each one. If a result looks promising, just open up its man page to read more.

man -f <TERM> is the other option I frequently use. This will give you a brief description of <TERM>, if there is a manual for it. This is faster than opening up the whole man page, and it's also a good way to see if <TERM> has more than one man page associated with it. If so, man -s <SECTION_NUM> <TERM> will open up the page for <TERM> in section <SECTION_NUM>.

The -k and -f flags are useful, but it's easy to forget which is which. apropos and whatis, respectively, will perform essentially the same function as those flags, and are easier to remember.

'man man' and the Road to Enlightenment

It's funny, but it took me a few weeks as a Unix beginner before I thought to try running man man at the command line. I'm assuming that most people aren't as slow as I am, but just in case, I'm giving you the spoiler right here. This zen-like command is your ticket to the beginnings of Unix mastery. Understand 'man', and you have the ability to learn almost anything about your system.

'man -a intro'

If you've got some free time and want a great overview of basically your whole system, run man -a intro. This will take you on a whirlwind tour of several introductory pages. At the end of each page, hit 'q' and you'll be shown a menu. Go through the whole set of 'intro' man pages, and you'll be one step closer to guru-ship. (NOTE: I run Ubuntu Linux, and I'm not sure if the 'intro' man pages are available on all flavors of Unix or not.)

The Problem With 'man'

One of the best things about Unix is that, typically, each program is small and specialized. This means that it's not too hard to master any given tool. What's difficult about mastering Unix isn't learning individual commands; it's learning how to use them together.

There are two parts to the Unix way of doing things. The first is to have a kit full of special-purpose tools. The second is to be creative about the way you use those tools, and to find powerful ways to combine them in order to accomplish difficult tasks.

The weakness of 'man' is that it can only tell you about a single tool at a time. Mastery of the tool kit is only half (the easier half, unfortunately) of effective Unix usership. Only experience will provide the second half.

Actually, this is what's really beautiful about Unix. While the
learning curve is much easier on graphical systems like Windows, once you learn it, you're done; that's all there is. With the powerful command line of Unix, there is no "done". There are wizards who have been using Unix since it was invented, and they're still creating new ways of doing things all the time.

Anyway, enough philosophy. Thanks for tuning in this week! As always, please leave some comments with your own tips, suggestions for future posts, errata, or what have you. See ya next week!

52in09 Week 1: screen

2009-01-11T16:35:00.000-08:00

Intro

Screen is one of the most useful Unix programs out there, so it seemed like a good way to kick off the 52in09 challenge. If you're just starting to learn Unix, you should try to get some of the basics down first, but screen can be one of the first commands you learn once you're comfortable at the command line. I guarantee that once you become familiar with screen, you'll forget how you lived without it.

Screen is described by its designers as a "terminal multiplexer." This is a geeky way of saying it makes it easier to do lots of things at once. Since its creation, however, screen has gained some abilities that go beyond just multitasking. The three reasons I like screen so much are that it can (1)separate processes from the originating shell, (2)provide a really effective way to multitask, and (3)provide an easy way to share sessions with other users.

Points 2 and 3 are kind of self-explanatory, but if you aren't familiar with screen, the implications of point 1 might be unclear. What I mean by separating a process from its origin is that with screen, you can start an interactive program like a text editor, completely log off the system, remote log in from a different client, and be able to pick up right where you left off. This is much more powerful than remote login by itself, because you can keep one "session" going basically forever, no matter where you are.

As an example, I use AOL Instant Messenger for all of my IM conversations. I like to leave it running all the time in case someone wants to leave me a message while I'm out. I also like to go to a nearby coffee shop to work on things. Until I found out about screen, I either had to sign off my home computer before I left or risk missing a message in transit. Now, I run a text-based AIM client in a screen session, and I can log in from anywhere and see what's happened while I was gone! That's kind of a silly example, but I'm sure you can come up with some cases where that kind of functionality would be a real boon to your own computing.

Well, enough exposition. What follows is intended as a tutorial of screen for the new user. It doesn't function very well as a reference, but that's what the man pages are for! So without further ado...

The Basics - An Overly Verbose Screen Tutorial

Start screen
Type screen to start a new session. You'll see a splash screen telling you what's going on; hit <return> to clear it, and you're back to a shell prompt. Treat this just like a regular shell and do your work. If you get to the point where it would be nice to have more than one program running at once, you'll want to...

Make a new window
All screen commands are prefixed by the control character, Ctrl+a by default. Type C-a c (that means to press Ctrl+a, let go, then press 'c'. That's the notation I'll use from now on) to create a new window. Now you have two shells running inside the single screen session, and they can be doing different things. To get back to the other one, you'll want to be able to...

Navigate
C-a n and C-a p go to the "next" and "previous" windows in your session. C-a " will give you a menu of current windows (use the arrow keys and <enter> to pick the one you want). C-a <NUM>, where <NUM> is a numeral 0-9, will take you to the window with that number. If you have more than 10 things going at once, you're kidding yourself about your ability to multitask. But if you insist, C-a ' will give you a prompt where you can type any number or window name and switch to it. Speaking of that, make sure you are utilizing...

Window Names
On my screen install, every new window I make gets called "bash" by default. Not helpful. Press C-a A (that has to be a capital 'A') to get a prompt for naming. I usually type in whatever I intend to run in that window. This also makes C-a " a whole lot more useful. By this point, you might be getting a little confused. The most important thing to remember is...

Online Help
C-a ? will get you a handy list of commands. It doesn't have definitions or anything like that, but it will usually jog your memory enough that you know what you need to search for in the man page. If you're done with a task and don't have any further use for the window it was in, you should probably...

Kill Window
C-a k will remove a window from your session. I like to keep a very small number of windows running at once, so I use this a lot. You certainly don't have to, of course. Screen can handle a huge number of windows in any session, so the limitation is just what your mind can keep track of. After you've done some work and are ready to log off, you'll want to...

Detach from session
C-a d detaches from the current screen session. This is the real power of screen: If you're running a window manager, you can go ahead and close the terminal window; your session is still alive. You can even log totally off the system, and it still survives. As long as you don't power off the box that's running your screen session, you'll be able to pick up right where you left off any time in the future from any location with...

Reattach to session
When you're not inside screen, you can type screen -ls to see what sessions are running. Type screen -r <SES_NAME> (where <SES_NAME> is the name of the session you want) to jump back into that screen session. If you're still attached to that session somewhere else (say you forgot to log off back at work and now you're home), screen -x will do the trick. That will get you two simultaneous connections. That's only with the same user account, however. There are a couple of extra steps to take care of before we can have...

Multiuser sessions
Screen is a great way to engage in remote collaboration on a project or give a demo of something. For security reasons, you can't do this by default, so you'll need to enable it. Try to convince your admin to run chmod +s /usr/bin/screen at some point (this only needs to happen once) before you start your session. Once the session is up, type C-a :multiuser on to get started. Figure out who will be joining your session and type C-a :acladd <USER1,USER2,ETC.> where <USER1,USER2,ETC.> is a comma-separated list of the usernames who will be connecting. Note that these need to be users on the system; you don't get to assign nicknames or anything like that. There are lots of permissions to be set here as well. Check out the aclchg portion of the man page for more info. It's a little tricky at first.

Join the multiuser session
If you're trying to join a session, first log on to the same system as the screen host. screen -ls is probably not going to give you a lot of information, since it only displays your own sessions, so you'll need to have your host tell you the name of the session you'll be joining. If they ran screen -S <SESSION_NAME> instead of vanilla screen, it might be easier. Type screen -x USER_NAME/<SESSION_NAME> and you're in! If you want to catch up on what's already happened, you may be interested in the...

Copy/Scrollback Mode
C-a [ will start up the scrollback buffer. Using the "vi keys" (h=left, j=down, k=up, l=right) you can scroll around in any screen window. This mode also lets you copy regions of text to a clipboard. Spacebar will open up a copy region; move to the end of the region you want and hit <spc> again, and screen will put that text into a buffer. <esc> will get you out of the copy buffer, and C-a ] will paste the text into the regular screen window. Check out the copy mode part of the man page, as it can do a lot more than what I just mentioned here.

Screen split
If you're the kind of person who likes to have a lot of stuff going on, you may start to feel limited by having to look at only one screen window at once. C-a S splits the window in two (or three, four, etc.) and C-a <TAB> moves around between open splits. C-a X closes the split your cursor's in, and C-a Q closes every split except the one your cursor's in.

Screen config file
At this point, we've covered all of the basics you need to get started with screen, as well as a couple of slightly more advanced features. By now you're ready to tackle the man page and learn the rest of the powerful features screen is capable of.

There's one last thing I'll leave you with. Like many Unix programs, screen makes use of a .rc file in your home folder (.screenrc, surprisingly enough) to customize settings. If you run cp /etc/screenrc ~/.screenrc you'll get a nice starter file. Here are the extra customizations I've added in my own .screenrc (just enter each of these into the file on its own line):

nethack on -> Makes all of the screen info messages silly.

defscrollback 5000 -> Increases the amount of information screen will store for the scrollback buffer.

hardstatus alwayslastline -> Gives you a highly customizable permanent status bar on the last line of your terminal.

hardstatus string "%{= kG}[ %n %t ] %u" -> The status line formatting language is pretty arcane, but this one just displays the name and number of whatever window I'm currently looking at, followed by a list of other users connected to my session.

Conclusion

If you want to learn more about screen, your best bet is the man page. Screen's manual is very well written and thorough, but if you can't find what you want there, just Google for it; since screen is so awesome, there are loads of articles out there.

That's it for the first week of 52in09! Thanks for reading, and make sure to come back next week for more Unix command goodness. Please leave comments on this post to tell me what you'd like to see me do differently or what's working well. And of course any screen questions are welcome too!

52 in '09

2009-01-06T18:29:00.000-08:00

In an effort to get myself blogging more often, I've devised the following challenge: Learn as much as possible about one Unix command every week in 2009, and report on what I find.

I'm not limiting it to less common ones, either. Even absolute basics are up for consideration, since most of them have extra options that do cool stuff I don't know about yet.

My goal is to post a report each Sunday on what I learned that week, then pick next week's command. First week is 'screen'.

Feel free to drop suggestions for what to learn in the comments, and also share any nifty tidbits that I missed!

Evangelism

2008-12-19T19:24:00.000-08:00

I recently gave a talk at work extolling the virtues of the text editor Emacs. If you've talked to me for more than like 40 minutes, you probably know what a huge Emacs fan I am. I'm not going to get into any of the details of the talk here (like how awesome Emacs is, how much happier you'll be using it, how much fuller and more beautiful your beard will become, how others will envy your newfound charm and charisma, etc. etc.); that's not the point of this post. My presentation met with a pretty lukewarm reception, and I want to get into why, and how to fix it. I want to talk about successful evangelism.

A training class I'm in right now for work just finished up its first week, and the instructors are fantastic. They know the material cold, and they're enthusiastic about it. They're so enthusiastic, in fact, that I'm getting caught up in it. I now want to do things the way they do them -- we're starting lab exercises, and I'm pumped about trying out the techniques we discussed earlier in the week.

What was it that got me so excited in that class? I don't really know, to be honest. But I'm hoping that by exploring the topic a little, I can get closer to understanding.

First of all, the instructors have infectious enthusiasm. They clearly love what they're talking about, and they fully believe in it. I'm not one of those sentimental types who thinks you can't fake stuff like that, but if these guys are faking, they're the some of the best actors I've ever seen.

I feel like I nailed the enthusiasm in my Emacs presentation. I'm not the most animated or outspoken of guys, so maybe it just didn't come across, but I want to believe that there are other forces at play here. You can't just have the enthusiasm by itself -- otherwise, why is this class going so well and my talk didn't?

Good information is another thing my instructors are getting just right. It's pretty hard to consistently win over intelligent people with just feelings. Advertising works, so obviously emotion-based tactics aren't useless, but advertising is also highly hit or miss. There's no telling in advance what will make a successful ad campaign. I get the feeling that my instructors are used to winning a lot of people over on a regular basis -- they're doing more than just advertising: they're also informing. I'm excited about the stuff we're discussing in class not only because somebody told me it's awesome, but because somebody gave me tons of data on the subject and made me understand it. I extrapolated the ways in which it's awesome mostly on my own.

Again, I could very well be deluding myself, but I really thought I had good information in my Emacs talk. I took a lot of time to pick out bits that I thought would be relevant to my audience, and I did my best to present that information in a clear manner.

Am I just easy to persuade and other people are just hard to persuade? Was it the problem domain? Certain problems are easier to sell solutions to than others. The proliferation of diet books versus, say, well, any other kind of book illustrates this. But while I think subject may have been a contributing factor, I'm sure it was at most a small one.

Ultimately, I think it might just boil down to experience. My instructors are seasoned teachers, and they've taught this same course several times in the past. Every time they teach, they improve just a little bit by observing what works and what doesn't. Same thing for the class itself: they've cut/reworked the bad parts and refined the good.

"Practice makes perfect" is an unsatisfying conclusion to draw from all of this, partially because it's such a cliched maxim, but mainly because it means the path to better presentations of my own is long and difficult -- rather than just consisting of a few cheap tricks and presto! people are clamoring for Emacs. I'd like to revisit this topic at some point. There is a lot of information out there on how to practice skills like speaking and teaching, and it could do with some sorting and distilling.

Hey Look - Another Blog.

2008-11-08T18:37:00.000-08:00

I'm jumping on the train and making a blog. Yeah, I realize that I'm about 4 years late for it to count as being in step with a trend. And with sites like Wired posting articles about the end of the blog, maybe it's downright silly to be starting one now.

Obviously, I don't agree with Wired, or you wouldn't be reading this right now. So why AM I starting my own blog? It's not to Make My Voice Heard(TM), the reason many bloggers have. Honestly, most of the opinions I have about any given issue have already been expressed by someone else, usually with a lot more style and insight than I'm capable of. Actually, I think I might have a post coming up about that very topic (ooh, sneak peek!).

I'm starting this blog as a sort of training area. I asked an English major friend of mine a while back what the best way to get into writing is; he responded that, like most skills, the only sure way to improve is to practice regularly. He described a few options for how to go about practicing, and recommended blogging as one of the best choices.

It's pretty obvious that you have to practice to get good, but for some reason I never thought of it like that before. I always thought of writing the same way I used to think of drawing: that it's some magical skill that you either have or you don't, and if you don't -- well, too bad. Of course, that's not true for either of those skills (sneak peek #2: possible Drawing post coming up!); although there are rare cases of individuals born with great natural talent, most of the time, someone is good at writing because he or she spends a lot of time doing it. Like I said: totally obvious; I don't know why I didn't realize that on my own.

Why do I want to get into writing? Besides the fact that I think it's kinda fun, I'm interested in the potential for mental development. Now that I'm not in school any more, I'm starting to feel my brain go squishy. My day job doesn't really provide the type of cerebral challenge I became used to in college, nor do most of my hobbies. The ways in which writing can sharpen mental acuity have been described by many others more qualified to lead that discussion, so I'll save my own thoughts on the matter until I actually have some results to talk about. For now, I'll trust that writing on a regular basis will in fact provide said benefits, and instead of worrying about the psychology, I'll just go ahead and try it.

So, essentially, I'm starting this blog to practice my writing skills, which I am doing in turn to develop my brain. That's it, really. But with any luck I'll wind up having something at least marginally interesting to say along the way. Hey, it's a blog; there are comments. You can tell me if it's any good or not.

Real content coming up this week sometime. That's the plan, at least.