Volume Number: 21 (2005)
Issue Number: 2
Column Tag: Programing

Mac In The Shell

by Edward Marczak

The Terminal: Why?

Love it or leave it!

You've got a fancy Aqua GUI in front of you (errr...if you have the print magazine in front of you, look at your OS X box now), why would anyone use the command line? The command line!?! We're here at MacTech because we use a Mac - the computer that popularized the GUI!!! The computer that said, "CLI? Gag me with a spoon!" (well, it was California in the 80's). However, despite Apple initially eschewing a command line altogether, the CLI has survived. There's a lot of power there, and OS X lets you tap into it. Furthermore, anyone can fire up a GUI utility and make some changes. But if you want to impress your date, you have to learn some command line tricks.

If you're a bit more of a CLI veteran, but are coming from a different platform, you may simply want to jump down to 'Apple-fying the CLI".

The Past

I work with a broad spectrum of people that reign over technology in some way: from low-level hardware and software hackers, to networking experts, high-level FileMaker developers and GUI-rangers. These people have all learned, or come close to mastering, the command line, and are better for it. I've grown up in a world of teletypes, Commodores, IBMs, Unix boxes, Apples, Netware servers, DOS and Windows environments. All of these machines started with a command line (and some ended there). In the timeline of computing, the GUI was an afterthought. Not for the Mac, of course. But go back to an Apple II, (if you've got one laying around!) and you'll find that when you boot up, you're presented with a ']' prompt and blinking cursor. Since this environment has been around so long in the Unix world, it is very well thought out and very mature. But it's certainly one of the reasons people not-in-the-know would panic when they'd turn on a computer. What do I do? It's just sitting there blinking at me. Will I break it if I type the wrong thing?

The Mac OS tried to end all of that command line fear and present a graphical interface at boot time that made people feel comfortable. They did a great job. But fast-forward to now, and Apple is singing a slightly different tune. However, I find many people who are dyed-in-the-wool Mac users simply pretend that Terminal.app doesn't exist.

The Present

Here we are, and there's a command line in a Macintosh operating system. They just couldn't keep it out of there. In all honesty, if it weren't in there, I'd be writing for a Linux magazine right now. As a techie, and someone who likes (and many times needs) to troubleshoot, there was no bigger breath of fresh air when I fired up Terminal.app under OS X (10.0 beta, on my Powerbook G3). I immediately typed 'ping 192.168.30.1' for the network I was on and saw the replies come back. Wow, Apple did it. Keep Word. Keep Safari. Heck, even keep Quake and Tron 2.0, I don't want a computer without access to the command line. But why?

Terminally Acquainted

I mentioned the power that lies in the terminal, what is that all about? Why is it so much more powerful? Firstly, you can typically type more quickly than you can mouse around. From time to time, I see people launch Calculator and click on each number rather than use the number pad on their keyboard. Doing that just doubles the time required. Secondly, as people like to customize their GUI (I'll admit that when I work on other people's machines and I find the dock on the left it drives me a bit batty...) and GUIs change over time (look at the differences going from 10.0 to 10.3), the CLI is pretty much the CLI. Of course, it can be customized, but it's usually done in such a way that it doesn't change the way standard utilities run. Third, it gives you a consistent way to administrate a machine. Fourth, it gets you a little closer to the operations of the machine. Have you ever had the GUI lock up on you? I have. But everything else was still running and I was able to console in and reset the machine gracefully. Fourth, and most importantly, Apple lied to us! When OS X shipped, we were told that we'd never have to see a command prompt if we didn't want to. OK, perhaps not. But that stopped us from doing certain things with our machines. While the entire situation is getting better, there are things you can do in the terminal that there is simply no GUI equivalent for. With those notes, let's get familiar with Apple's Terminal.app, starting with the configuration that ships with OS X 10.3.

Launch Terminal.app from /Applications/Utilities/Terminal. Perhaps the fact that you find the app in 'Utilities' rather than 'Applications' is something that scares people right away, as if it's not something one should normally run. Figure 1 shows approximately what the default terminal looks like.

I say 'approximately' because you will have some differences. Of course, the time of your last login will be different. Unless you've already changed it, your "message of the day" will still read "Welcome to Darwin!" The next line is your prompt, and it is generated at run-time. 'Jack-Kerouak' is the name of my machine (because, if you must know, it's a laptop and I'm always "On the Road"), and you'll have the host name of your machine. The "~" shows my current path, and by default, we start out in our home directory (which is represented by the tilde). "game" is the short name of the account I'm logged in as (remember: Quake and Tron 2.0!), and you'll have your user name. Then, there it is, the cursor. Patiently waiting for you to type.

Black text on opaque white. Boring. Lets go check our window settings. Choosing the "Terminal->Window Settings..." menu gives us some ways to modify the look and behavior of the terminal. Figure 2 shows the first of several preferences that can be changed in the 'Terminal Inspector'.

Of course, these are all preferences, and are unique to each individual. I'm going to share how I like my terminal to behave, but by all means, choose what makes you most comfortable.

The first set of preferences, "shell", gives us one option: choose what to do when the shell is done. I think I've only had one occasion to keep it at the default, so I immediately change this to "Close only if the shell exited cleanly."

The "process" preferences work perfectly at "prompt before closing window if there are processes other than:". I like being prompted as little as possible for anything. The "emulation" settings have good defaults, but may need to be tweaked for a particular case. The only thing I do here is check the "option click to position cursor" checkbox, despite actually using that function very little myself.

The "buffer" preferences only deserve one change: set the scrollback to 'unlimited'. If you ever start compiling things from the command line, like a custom Apache install, 10,000 lines can disappear pretty quickly.

The "display" preferences are a little more fun, as their effects can be seen instantly. See figure 3 to get a look at this one.

Call me old-school, but I want a block cursor that blinks. Depending on the display I'm using, I'll sometimes drop the point size down to 9. A quick tip for you: never turn on anti-aliasing. Not only does it look terrible, it slows Terminal.app down - yes, even more so than it starts out. This is one valid gripe that users of Terminal.app have. Its speed is nowhere near a real terminal, a terminal emulator on other systems, or even a Windows DOS box (or, for that matter 'DOSbox' under OS X. Man is that thing quick!). While things did get better in Panther, Terminal is still the laggard, comparatively. But, hey, it looks great.

Next up are the color prefs, which go hand in hand with the display prefs. Have fun with this one: there are no wrong answers here. Come up with a style that is easy on your eyes and makes you feel at home. Again, I go for the old-school combo of green on black, with a pinch of ultra-modern transparency. I have one terminal combo of light-blue on dark-blue with a rather large font. Yes, it looks like a Commodore 64....

Stepping down brings us to the 'Window' preferences. I tend to check off just about everything in the lower-half of the inspector window. Additionally, I like to make the terminal fairly large. Why have text wrap if it doesn't have to?

On the last page of options, the 'keyboard' prefs allow one to alter the escape codes that are sent to Terminal.app for each key. Unless you have a great need to change these (and you may), just leave these at their default settings.

Now, I know you've been eyeing that large "Use Settings as Defaults" button at the bottom of the Inspector window. Well, if you have everything set the way you like, click it! As soon as you click it....nothing happens! Well, OK, it does save your preferences, but there is absolutely no feedback that it done anything. For proof, quit Terminal.app and relaunch it. You should now have a terminal that defaults to your settings. Nice, eh?

Now What?

So, now we've made the terminal pretty. Great. Besides staring at a blinking cursor, now what? Let's start with the basics. Again, you'll see where you are in the filesystem based on your prompt, which at first should read '~'. We can start from the top to best illustrate how this works. The very top level of the filesystem is represented by '/', or, 'the root'. Type 'cd /' and press enter. This will 'c'hange 'd'irectory to "/". You're now at the top level of your disk tree, basically represented by "Computer" in the Finder. You should also notice that the terminal prompt changed from "~" to "/". Now, type "cd Users" (capitalization is important). You've moved into the familiar Users folder. Let's see what's in here. Type "ls -l". This produces a file 'l'i's'ting of the current directory. The '-l' following the command is a switch that modifies the behavior of the command. In this case, we want a 'l'ong list. Try an 'ls' without the '-l' switch and you'll immediately see the difference (and, hopefully, why I prefer the long list).

So far so good, right? Nothing broke. Just remember, although the terminal brings you down to a lower level, there's still a thin veneer between you and the OS. Not quite the movie screen the GUI covers everything up with, but still, a level of abstraction exists. For example, when you ask for a file listing by typing 'ls', sure, you had to do something manually. Directory information didn't just come flying onto your screen. But neither did you have to tell the disk drive which blocks to access. So, as always, unless you pour liquid onto your CPU, you're not going to break anything.

If you feel comfortable with these two basic exercises, the command line just may be for you! Naturally, this doesn't scratch the surface of what can be done via the CLI. Not even the surface of the smallest surface that exists on the surface of the CLI.

Want More?

Listing files? I can do that in the Finder! Where's the power? If you're comfortable moving from directory to directory, we can look at some more powerful commands.

Continuing with file related commands is important, as Unix treats just about everything as a file. Your disk drive? A file. Even the terminal display can be treated as a file. We'll get into this deeper in future columns, but safe to say, file manipulation is important.

Back in the terminal, type 'cd'. Simply typed by itself, the change directory command will bring you back to your home directory. Now, type 'touch thefile.txt'. In short, the touch command will either create a zero-length file, or, if the name you specify already exists, will update the date stamp of that file to the current date and time. Get a directory listing and see if your file is there ('ls -l', remember?).

To copy that file, you use the 'cp' command. Type 'cp thefile.txt theotherfile.txt'. 5 points if you typed 'cp thef' and hit tab to complete. This will copy 'thefile.txt' to a file called 'theotherfile.txt'. We can alter these files as well as having copied them. There are some holy wars in Unix-land as to the best text editor in the world. I use vi. No apologies, that's just what I use. It will absolutely be the subject of a future column. If you know another text editor, feel free to use it here.

Invoke vi (the 'v'isual 'e'ditor) by typing 'vi theotherfile.txt' (did you use tab completion?). You'll be presented with a blank-ish looking screen with tildes running down the left-hand side. Figure 4 should mirror what you're seeing.

The tildes represent a non-existent line, which, admittedly, can sometimes get confusing if you're editing a file with tildes. I'll just give the key presses with a short description, since I'll cover vi in a future column - case is important, by the way. Press 'i' for 'i'nsert - you're now free to roam about the cabin. You should see a bold 'INSERT' notification at the bottom of the edit window. Type whatever text you'd like. I just typed 'This is a test.' When you're done, press the escape key on your keyboard. Type ":" (colon), and you should see a ":" appear at the bottom of the window you're editing in. Follow that with 'wq' and press Enter. That tells vi to 'w'rite the file to disk and then 'q'uit. You'll be dropped back to your prompt.

I'd like to delete the original file that we created. This is done with the 'rm' command. Now, just like files that you throw in the Trash via the Finder, be careful what you follow the 'rm' command with. Unlike the trash, though, the files that you list will be deleted immediately. No trash, no undo. Gone. Tab completion can be great, or you can use it without thinking after an rm command and nuke the wrong file. Be careful out there! That said, type 'rm thefile.txt' and, after checking yourself, press Enter. You've just deleted 'thefile.txt'.

The 'mv' (move) command moves and renames files. Renaming, after all, is just moving a file within the same directory. Type 'mv theotherfile.txt thelastfile.txt' and press Enter. 'theotherfile.txt' just became 'thelastfile.txt'.

To bring this all home, we can open the file we created in the Finder. Switch to the finder, and open your home directory. 10 points if you've left a Finder window of your home directory open this whole time and watched all of these machinations take place. You should see a text file named 'thelastfile.txt' sitting there. If you double click it, it should simply launch TextEdit. Check out our handiwork in Figure 5.

While this was all a bit contrived and trivial, I'm sure you can imagine some automated routines that compile information, save it to a file, and then display it via TextEdit or any other program. In fact, let's try something a little more serious.

Hop back over to terminal. Fire up vi or your favorite editor. I'll give instructions for vi. Type 'cd' so you're sure you are in your home directory. Type 'vi showdi.sh'. This will be a bash script that will show us a report of disk information for our main disk and display it in TextEdit. Press 'i', and you'll again see the bold 'INSERT' along the bottom of your editor window. Type the following exactly:

#!/bin/bash diskutil info /dev/disk0 > 
/tmp/disklist.txt open 
/tmp/disklist.txt 

Save this file by pressing escape, typing ':wq' and pressing Enter. Type 'chmod 700 showdi.sh' and press enter. This gives this script the ability to be executed (run) as a program (ok, this is a bit simplified, but without this command, this script is just a text file).

Before we run this, let me note that you'll need to be an admin for this to work. When you're ready, type "./showdi.sh" to run our script. That's dot, forward-slash, showdi.sh. Don't forget the tab-completion for this one! Press enter. In about two seconds, TextEdit will pop up with a short report about our disk 'disk0'. See figure 6 for what this looks like.

Again, the details of this script and all the commands we typed will be covered in future articles.

Apple-Fying The CLI

If you're a more seasoned user, you may have skipped some of the earlier bits of this article. You already know your way around. You know what a hard link is and you know how to use it. You like to fire up Terminal.app, dive in and never look back. Some things that may escape you if you're coming from another environment:

If you're a big xterm person, there are some notable differences here. Mainly:

• Terminal.app doesn't honor switches (like "-bg") that allow you to customize the Terminal at app launch. You have to use Terminal Inspector as described earlier.
• $TERM defaults to "xterm-color", which is great on your own system, but can throw remote systems not ready for it.
• You can't launch a new terminal from the command line! Goofy, eh? You just have to slap Apple-N.

However, despair not. There are some really nice Terminal attributes. Such as:

• You can set your window title on the fly (though escape sequences and an 'echo').
• Split-screen bar (see figure 4)
• Tab completion. I couldn't survive without tab completion.
• Integration with the Services menu.

We'll step through these bits here.

If you're really into customization and want to set your window title from the command line, or have a script that uses this functionality, you can! Try this:

echo -n -e "\033]0;Title\007"

The "\033" is the 'escape' key, needed to start an ANSI escape sequence. Follow this code with the title you want, and close it out with a "\007".

You can split your terminal horizontally by clicking the 'broken square' icon in the upper right-hand corner of the terminal window. This will display a horizontal bar that can be adjusted to size the windows as needed. Figure 4 shows a split screen with a file listing in the upper split, and 'top' running in the lower pane. While this functionality is useful, I use it very little. The reason for that will be part of a future article.

Tab completion!!! All Unix veterans know some kind of completion. And when you start using it, you'll never give it up. For you hard-core Unix people: OS X has standard tab-completion, 'nuff said. If you don't know what this is, here's an illustration: once again, type 'cd /' to get to the root. Now, type 'cd Li' and then press the 'tab' key. Suddenly, the line you're working on fills itself out (to become 'cd Library/'). Now, type 'W' and a 'tab'...boom! You now have 'cd Library/WebServer'. This cuts down on the keystrokes you need to type by a huge factor. Sometimes, your hit 'tab' and you simply hear a beep. That's either because nothing matches, or more than one thing matches. As an example, if you still have Classic loaded on your machine, and you type 'cd /Sy' and press tab, you get a partial completion (to 'System') and a beep. If you press 'tab' again, the shell will show you the matches. In this particular case, you can either accept the match of 'System' (because it's valid), or type '\ " (backslash-space) and press 'tab' again to have the shell complete the next match. The more you use it, the more you'll get the hang of it. Just don't practice on Windows XP, which now supports tab completion, but has a really poor substitute of it.

OS X has a great feature in the Services Menu - which someone else can cover much better than I can. Terminal.app has nice integration with this menu. Highlight some text, and then go check Terminal->Services. There's some nice functionality there, such as: Send to mail, create new sticky note, create new window in TextEdit, and more.

One last note for those so inclined: You should also take a look at the actual Terminal preferences, accessed through the 'Terminal->Preferences' window. This will allow you to define several aspects about your terminal that can help out in situations where you're trying to emulate a different terminal. Be aware that changing the shell in the Terminal preferences screen will only change it for shells launched through Terminal.app. Alternate terminals (see below) and ttys from remote sessions, such as telnet or ssh, use the shell defined in your user profile. The good old 'chsh' works for this purpose, or, if you want to get all OS X about it, change the shell key in your NetInfo record.

The Future

Well, naturally, I can't predict the future. But I can tell you that a text, command line interface will be with us for some time to come. There are new applications showing up all the time that are CLI only. You can find MP3 players, Gnutella clients, games, web browsers, e-mail programs and more, that are all CLI driven. Although the Mac certainly needs it less than other platforms, which may still be text-driven by nature, learning the CLI is of great benefit. It helps you troubleshoot a Mac with a boot time problem, and it can help you automate your machine in better circumstances.

I'd be remiss if I didn't mention that Apple's Terminal.app isn't the only terminal for OS X! There are two more that I'm aware of. GLTerm takes the speed issue head on. All display is done through OpenGL. It also supports X .bdf fonts. There may be cases where Terminal.app doesn't handle some graphics issue correctly. Chances are, GLTerm will handle those cases just fine. Find it at http://www.pollet.net/GLterm

The second terminal alternative is iTerm. iTerm shoots for features. If you spend time in KDE or Gnome, check out iTerm. It has support for bookmarks (saving session settings), tabs, an anti-idle function and more. You can find it at http://iterm.sourceforge.net.

The End

This is the end...of this column only (whew!) Obviously, I'm a huge proponent of the CLI. Now, I'm not so stubborn that I use the Terminal for everything! After all, I am a Mac user!

PS

Anyone who read my 'Unix in OS X' article that appeared in the December MacTech should note that I did find the solution to making an OS X 10.3.4 through 10.3.7 machine accept remote syslog connections. In your /etc/rc file, you need to alter the syslog invocation to read:

/usr/sbin/syslogd -a 192.168.1.100/24:\* -m 0

where the IP address and mask (in CIDR notation) represent the interface to listen on.

Unfortunately, this incantation has changed a few times and the syslog binary is out of sync with the man page. Stay tuned for any changes to remote logging!"

When he's not helping the clients of Radiotope, you'll find Ed Marczak on the grid, fighting for the users.