Day 25 - Introducing UNIX 4.0!

I know. Advent is only 24 days. Continuing from last year's "Jordan had no idea advent was only 24 days" tradition, here is a bonus 25th article to wrap up this year's sysadvent. Enjoy! :)

I have these two nearly-30-year old computer manuals that were given to me by a coworker who thought I'd be interested. Boy was I! I'm that kind of nerd. Anyway, these books were internal Bell Labs manuals/guides for helping folks do stuff on UNIX. They were printed before I was born and contain great content for interviews because they document UNIX shell, editor, system programming, and other pieces that are still here, today. You'll find few of the topics covered have changed since UNIX, 30 years ago; FreeBSD, Linux, and Solaris all have fairly clear heritage here.

Welcome to UNIX Release 4.0!

The books themselves contain multiple sections covering a range of topics. With respect to the UNIX version covered, the intro says it is relevant to UNIX 4 (1974), but I think most of it is relevant UNIX version 7 (1979) which was released nearer to the print dates in these books.

The intro to the book, which discusses notation and conventions, explains this:

Entries in Section n of the UNIX User's Manual are referred to by name(n).

I always did think that the name(n) notation for manpages was useful, and now I have a better understanding of how old this stuff really is.

One of these books is "UNIX Programming Starter Package." It includes "UNIX Shell Tutorial" by G. A. Snyder and J. R. Mashey. The copy I have is dated January 1981. It starts with talking about the filesystem. "If a path name begins with a /, the search for the file begins at the root of the entire tree; otherwise, it begins at the user's current directory." It goes on to discuss absolute vs relative path nomenclature.

Next, it discusses processes: how a fork of will spawn an identical copy of the original process, that both can continue to execute in parallel, and that either may call exec(2) to abandon the current program and start a new one. It also talks about wait(2) and how the parent might use it, and includes a diagram of it:

Continuing the process discussion, this tutorial explains that child processes inherit open files and signals. You'll learn about process termination, including the 8-bit exit status value and about success (zero) and failure (non-zero). Signals are also explained: a signal may come from "another process, from the terminal, or by UNIX itself." Signals can be ignored or caught by programs and the book makes special highlight of the interrupt signal, which can come from a user pressing the right key sequence. The tutorial explains 3 ways the signals are generally handled in a shell: the active program might die due to interrupt, the shell itself ignores the interrupt signal, and tools like ed(1) catches the signal and uses it to abort the current action (like printing) without exiting.

In case you were really wondering about the origins of the SIGHUP signal, this book's "UNIX for Beginners" chapter explains that "hanging up the phone will stop most programs."

Also covered are position parameters ($1, $2, ...), variables such as PATH, HOME, and PS1 (your shell prompt), "Command substitution" aka `stuff in backticks`, special variables like $#, $?, $$, and more. Keyword paramters also are documented here and how they relate to the environment (things like "FOO=hello ./mycommand arg1..." where FOO is an environment variable passed to ./mycommand.

Pipes, input redirection, process backgrounding, nohup, etc. All talked about here.It also has a pile of sample scripts, including this one called "null" which is a 1980's UNIX version of the modern touch(1) command:

#       usage: null file
#       create each of the named files as an empty file
for eachfile
do
        > $eachfile
done

When we run this on Ubuntu 9.04 in /bin/sh, it still works.

% sh null.sh a b c d e
% ls
a  b  c  d  e  null.sh*

Basically, The unix shell (linux, freebsd, etc, too) hasn't changed much in 30 years. The concepts, implementations, and syntax are, for the most part, exactly the same. Some important quotes from this tutorial from a section titled "Effective and Efficient Shell Programming:"

"In the author's opinion, the primary reason for choosing the shell procedure as the implementation method is to achieve a desired result at a minimum human cost."

"One should not worry about optimizing shell procedures unless they are intolerably slow or are known to consume a lot of resources."

"Emphasis should always be placed on simplicity, clarity, and readability."

Other sections in the "UNIX Programming Starter Package" includes a C reference and UNIX system reference, which details important concepts such as "everything is a file descriptor" among the general programming library reference.

I skipped the first section in this book, which contains a very excellent introduction to ed(1), which, as you should guess by now, is still totally valid documentation today. If you've never used ed(1), learning about it shows distinct ancestry to ex(1) and it's successor, vi(1).

The second Bell Labs UNIX manual I have is "UNIX Text Editing & Phototypesetting Starter Package." That's quite a mouthful of title! It goes extensively into how to use ed(1) and other tools that would help you edit stuff. Past that, it dives head first into troff/nroff, mm, tbl (table formatting), and eqn (math formulas). Reflecting on the general syntax of troff/nroff, and comparing that with HTML, Markdown, whatever random wiki markups are floating about, etc, I don't really feel like we've made progress much progress since troff.

In case you weren't aware, all your manpages are written in modern nroff.

% gzip -dc /usr/share/man/man1/sh.1.gz | less
< I skipped the copyright stuff >
.Dd January 19, 2003
.Os
.Dt SH 1
.Sh NAME
.Nm sh
.Nd command interpreter (shell)
.Sh SYNOPSIS
.Nm
.Bk -words
.Op Fl aCefnuvxIimqVEb
.Op Cm +aCefnuvxIimqVEb

So, besides a fun history lesson, what are the take aways? Personally, I use some of this material for interview questions. Pillars of UNIX that are still valid today are quite meaningful and useful to know, and I just might expect you to understand them if the position demands it.

I have a few photos of the books and content on Flickr.

Further reading:

• UNIX history timeline (pdf)
• UNIX for Beginners - Updated for 4.3 BSD (Very similar to my print copy)
• A Tutorial Introduction to the UNIX Text Editor - Meet ed(1). (Again, quite similar to my print copy, but updated for 4.3 BSD)
• Couldn't find a copy of the "UNIX Shell Tutorial" by Snyder and Mashey, but these are relatives (found by googling for phrases from my paper copy):
  • http://grosskurth.ca/bib/1976/mashey-command.pdf
  • http://www.in-ulm.de/~mascheck/bourne/PWB/
  • http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN1/0643___B.HTM

Day 20 - Becoming a Sysadmin

This article written by Ben Cotton. Editor's thoughts: This may seem like an odd choice of content, but sometimes it is as important to know where we came from as it is to plan where we are going. Did you choose systems administration, or did it choose you?

This post was inspired by my brother-in-law asking me what seemed like a simple question, "how do I become a sysadmin?" It turns out the answer is not so easy.

The title, "systems administrator," is sufficiently vague so as to be completely useless as a description of one's job duties. I've written in the past about the variety of tasks a sysadmin might encounter in a given day. With such a range of duties, it should come as no surprise that there's more than one path to becoming a sysadmin. Knowing a wider sample of individuals would better capture all the possibilities, so I posed a simple question to respected colleagues and to the community at ServerFault: how did you become a sysadmin?

It turns out that very few people dream of becoming a sysadmin as a child. Most sysadmins got their start by combining an interest in computers with another interest or skill. The combination isn't always intentional. Some people just happened to fix the right person's computer one day or got saddled with systems administration on top of their regular job duties. For others, it is the natural next step. An experienced developer who no longer feels like developing is often a great candidate to maintain the systems that the developers use. Many others move up through the ranks, starting out at the help desk and gradually gaining knowledge and responsibility. One person's career path even made a brief stop as a strip club bouncer.

For many people, myself included, there was little formal training in computers. My degree is in meteorology, and I know of several people who got started in the sciences or engineering. The reason for their success is two-fold. In academic environments, it helps to understand the science behind the work the users are doing. The other reason is that scientists and engineers are trained to think a certain way - to approach and solve problems in a logical and systematic manner. The fundamental job of a system administrator is to solve problems or anticipate future problems, so having a scientific mindset is a strong asset.

So if formal training in computers isn't necessary to become a sysadmin, what is?

The willingness to learn is key. A successful sysadmin spends a lot of time learning, whether it is about new software, new hardware, new processes, or USB missile launchers. If you want to become a sysadmin, the first thing you need to do is to start learning. The learning can be accomplished in many ways. Formal education, in the form of classes or vendor-provided training, can be very valuable. Learning at the shoulder of someone more experienced provides some gaps, but gives you knowledge that can only come from experience. And of course, there's self-education. The bulk of my early learning came from tinkering with (and breaking) my own computers, and by reading "___ For Dummies" books. It's amazing what you learn when you have to fix your mistakes.

So what do you need to learn? Everything. I won't get into the technical skills, because those will vary from position to position. I mean, you might need to know how to set up an Exchange server, or how to tune NFS performance, or how to manage a print server, or...well, you get the idea. To really be a successful sysadmin, you need to learn some indispensable, if tangential, skills. Technical documentation may be the most important skill for sysadmins, because you will at some point forget every important piece of information that you need to know. Writing documentation for users is also invaluable, especially if you want to spend less time answering questions. Project management, personnel management, and budgeting skills also come in handy.

Armed with all of this knowledge, you're ready to become a sysadmin and find out how much you don't know (hint: no matter how much you know, there's always more that you don't). Getting the first job is the hardest, and you might need to start out doing non-sysadmin work. Help desk support, programming, or anything else that gets you in the door gives you the opportunity to start learning new skills and taking on responsibilities. The only common theme among the answers I received is that there's no common education, minimum skills requirement, or career path. Each sysadmin path is unique. I'll leave you with a few of the most amusing quotes:

"I think I did something horrible to someone in a previous life and this was my punishment. Anyone else feel like that?"

"Enlisted in the Army for a completely unrelated job. Made the mistake of fixing the commander's email. Voila! I became a sysad."

"I am a sysadmin because one beautiful summer day, I found a computer laying in a field."

"Why would someone want to get into this job? I strongly suggest he get into driving heavy machinery. That's what I'm gonna do when I grow up."

Further reading:

• System Administrator on Wikipedia
• How did you become a sysadmin? discusson on Serverfault
• What makes a great sysadmin? discussion on ServerFault.