Volume Number: 21 (2005)
Issue Number: 3
Column Tag: Programming

Mac In The Shell

by Edward Marczak

The Shell: What?

It's What You're Using In The Terminal

While there are many elements that contribute to the Zen of Unix, understanding the shell is, if not the pinnacle of this list, pretty close to it. To truly grasp not only the basics of shell use and programming, but also what is going on when you press 'return', will increase your skills considerably. This month's column will introduce us to 'the' shell, and demonstrate some substantial uses.

What in the What?

Last month, we talked about "the terminal." However, the focus was primarily on Terminal.app itself, and much less about what one actually does with it. Basically, Terminal.app is our interface to the shell. But what is a shell? In short, it's the user interface into Unix. It accepts input, processes said input, and is responsible for output. Much like a GUI...just with much less emphasis on the 'Graphical' component. Aside: any old NetWare users will tell you of components with the acronym 'TUI' in them. You guessed it: that's how they named their 'textual user interface' components, made to be run at the (text) console.

So a shell is really a layer of abstraction between the user and the core of the OS. Between the time of punch cards and graphical interfaces, text ruled the computing landscape. The first major shell available for Unix was the Bourne shell ("sh"), named for its creator Steven Bourne. An alternate shell, called the C shell ("csh") showed up, which took much of its syntax and semantics from the C programming language. In the Unix spirit of complete flexibility, the shell was designed to be independent from the OS. Compare that to certain OSes today that won't even let you remove a web browser without coming to a complete halt (or so we're told...).

So, what I'm getting at here is that we're going to have a lot less pictures this month. Learning to use the shell is a lot like playing an old Infocom game: you stumble around a bit, you get told that you're talking nonsense, but you ultimately map everything out and learn your way around. Even if you haven't visited every nook and cranny.

So much time, so little to do!

We're only going to cover shell basics this month, which must be understood to be built upon. You have all the time with this column as you need. The focus here will be to compare Finder actions with their command line equivalent. Next month, though, we're going to pile more on top of what is learned this month. Two things to note for this column: a) The word 'Folder', primarily used in the Finder, and 'directory', primarily used in the shell refer to the same concept: a logical container that can hold files and other Folders. I use these terms interchangeably. b) The tutorials here assume that you have a 'standard configuration' for your Mac: volumes show up on the desktop, you haven't altered your shell to start you off in some oddball location, /Users is in the default location, etc. If you've made those types of changes, I can only guess that you know what you're doing and can compensate for it here. Actually, if you made those kinds of changes, you're probably not even reading this.

As of OS 10.3, Apple has made bash the default shell. bash was created for the GNU project, and showed up in early 1988. It is a variant to the original 'sh', with a few additions. In the grand tradition of computer wit, it's only natural that there's some humor behind the name: bash stands for the "Bourne Again SHell". Just for reference, as of 10.3.7 and 10.3.8, the bash version is 2.05b.0(1).

From here on out, I'm simply going to refer to bash as "the" shell. It certainly has become very popular, and again, is now the default for Panther (and, I hope, Tiger). csh, zsh, ksh and other shells all have their purpose, and their fans. However, I'm really happy that bash is now the default. Under earlier releases of OS X, one of the first things I did was to change my shell away from tcsh (Tenex C SHell, Apple's earlier default), and immediately change to bash. Again, that's just one of the great things about Unix: flexibility. As a multi-user OS, each user on the system can choose the shell that they prefer, and have that presented when they login.

Where it's at

bash is primarily intended for two things: interactive use, and full-blown programming (or, "scripting"). However, moving from interactive use to programming is evolutionary. Before you know it, you'll be writing scripts that automate your system and make your (or your customers') workflow easier. We're going to start with interactive commands: typing one command at a time, and getting output if appropriate. Some of this should be familiar if you followed along last month. However, this time, I give a little more detail and explain the underlying concepts in a more direct context.

Let's get to it, making one note first: as you follow along in the examples below, all capitalization and spacing is important. It makes a difference. So, if something isn't working for you, or you receive an error message where I say something will work, just double-check what you've typed.

Now, what could be more basic than opening a Finder window to peek at the contents of some directory? If you double-click on your hard drive icon in the Finder (or the equivalent of that action, like using the sidebar, etc.), you'll basically be looking at the root of your file-system. Unlike a real life tree, the 'root' of a hard drive refers to the top level: everything flows down from there. Launch Terminal.app. (You have it in your dock by now, don't you?) And there sits the cursor, blinking away. Well, just like double-clicking the hard drive icon, Terminal.app starts you out in a directory, it just doesn't display it until you ask it to. You start out in your home directory. How do you know that? Use the "pwd" command - this displays your "present working directory." In my case, typing "pwd" reveals "/Users/marczak". This shows my path from the root of the file-system. This is the same as saying, "double-click your system drive, then double-click on 'Users', and once more on the folder named 'marczak'". Now that we know where we are, let's see what's there, and compare that with what we see in the Finder.

Switch to the Finder and Apple-Shift-H to bring up your home directory. You may also want to put that window into column view, sorted by name. Back in the terminal, type "ls -l". This simply tells the bash shell to 'list' the contents of the directory you're in. The '-l' switch gives us a 'long' view; in other words, it gives some more information. This should be familiar ground if you followed along last month. You should get a listing like this:

This file names you see in this listing should correspond with what you're seeing in the open Finder window. 'ls' can do more than this, though. Just as you may sort the Finder window by different criteria, ls can do the same. If you want to order the listing by time (or, "Date Modified"), you can add the 't' switch, like this: "ls -lt". This places the most recent dates at the top and goes back in time from there. If you want to reverse this order, you can, with the 'r' (reverse sort) switch. Try it: "ls -ltr". You should now see the contents of your home directory, sorted from oldest to newest.

drwxrwx---   25   marczak   marczak   850       12   Jan   12:51   Applications
drwxrwx---   47   marczak   marczak   1598       8   Feb   01:01   Applications Alt
drwxrwx---   22   marczak   marczak   748       12   Jan   09:25   Audio Apps
drwxrwx---   4    marczak   marczak   136        5   Nov   07:48   Crapplications
drwx------   52   marczak   marczak   1768       8   Feb   17:05   Desktop
drwx------   56   marczak   marczak   1904       8   Feb   00:41   Documents
-rw-r--r--   1    marczak   marczak   0         14   Oct   17:54   IO.SYS
drwxrwx---   3    marczak   marczak   102        1   Feb   15:52   ISO
drwx------   44   marczak   marczak   1496       7   Feb   08:56   Library
-rw-r--r--   1    marczak   marczak   0         14   Oct   17:54   MSDOS.SYS
drwx------   23   marczak   marczak   782        3   Feb   10:20   Movies
drwx------   58   marczak   marczak   1972       1   Feb   07:17   Music
drwx------   29   marczak   marczak   986       30   Dec   07:17   Pictures
drwxr-xr-x   4    marczak   marczak   136        6   Oct   08:46   Public
drwxr-xr-x   6    marczak   marczak   204       22   Dec   17:46   Sites
-rw-r--r--   1    marczak   marczak   618       30   Dec   09:44   StCDS.zip
drwxr-xr-x   5    marczak   marczak   170       26   Oct   16:39   ZDE
-rw-r--r--   1    marczak   marczak   1044904   27   Jan   11:56   Enz Server.nfo
drwxrwx---   9    marczak   marczak   306       26   Dec   00:04   bin
drwxr-x---   5    marczak   marczak   170       31   Dec   2003    bin2
drwxr-x---   39   marczak   marczak   1326       9   Jul   2004    bin3
-rw-r--r--   1    marczak   marczak   1464       5   Feb   23:39   ca.crt
-rw-r-----   1    marczak   marczak   5715      25   Oct   08:18   edterm.term

If you command-click or right-click in a Finder window, you're presented with the option of making a "New Folder". bash will do this with the 'mkdir' command. While still in your home directory, type "mkdir MacTechTest" and press Enter. If you switch back to your Finder window, you'll find a new folder there called "MacTechTest". If you type "ls -l" in the terminal, you'll also see your directory listed. Now, go back to the Finder window, and move your "MacTechTest" folder to the trash. Run another "ls -l" in the terminal. You'll notice that the file is gone!

For the next comparison, please open up TextEdit (which, by the way, can be done without ever leaving Terminal.app by typing, "open /Applications/TextEdit.app"). Create a quick test file, and save it in your home directory. Call it "ShellExample.txt". Once you save it, quit TextEdit, and hop back over to Terminal. Once again, you'll see this file with "ls -l". But, you know, we should have a second copy of this file - right in the same directory. In the Finder, you'd either drag-and-drop with the option key down, or select the file and Apple-D (File->Duplicate). We can make a copy of this file in several ways, but we'll start out doing so via the 'cp' command. As you probably guessed, "cp" stands for "copy". Type "cp ShellExample.txt MacTechExample.txt". This takes the first file (ShellExample.txt) and copies it, giving it the name of the second file (MacTechExample.txt). Go check your Finder window to see both copies. One difference between the Finder and the default actions of the CLI to note here: if you copy a file, and you have a file with the same name in the destination, 'cp' will happily mow right over the destination file, replacing it with the file you're asking it to copy. Compare that with the Finder which will prompt you before doing anything like that. If you like the prompt, you can use the "i" (interactive) switch. If you try that again with the "i" switch - "cp -i ShellExample.txt MacTechExample.txt" - you'll get asked, "overwrite MacTechExample.txt? (y/n [n])". You need to type "y" and press enter for the copy to take place. Any other response cancels the copy operation, and you are notified with, "not overwritten".

Thinking about it, we don't really need both copies; let's dump one of them. Type "rm ShellExample.txt". Yep, "rm" stands for "remove". Here's an example of a command that acts differently from the Finder. When you delete something in the Finder, you move it to the trash, where it sits until you decide to "empty trash". Conversely, "rm" nukes the file on the spot. No ability to retrieve from the trash here. Once you hit that Enter key, it's gone. So, always be a little careful with the "rm" command. If you want the added comfort of a confirmation prompt, you can use the "i" switch here, too. "rm -i filename" will ask "remove filename?" Only a reply of "y" on your part will remove the file. Any other response cancels the action.

Create a test folder again: "mkdir ShellExample". Now we can move our file into the folder we just created. In the spirit of Unix economy, the command for move is "mv". Just like the cp (copy) command, you follow the mv command the names of two files: where it is, and where you want it to go. In this case, we'll move our file with "mv MacTechExample.txt ShellExample/". We can change our current directory by using the 'change directory' command: "cd". Type "cd ShellExample" and press Enter. Now, list the contents of this directory, and you'll see the file that we moved in here. Note that your prompt has changed to keep you abreast of your current directory. Your prompt should end with something like '~/ShellExample username$', where 'username' is your user name.

Why did I call that file 'MacTechExample.txt'? We should name it 'ShellExample.txt', like the directory it's sitting in. You rename files with the 'mv' command. Think about it: renaming is really just moving the file within the same directory and changing the destination name. Type "mv MacTechExample.txt ShellExample.txt". List the directory again and note the change.

Bring me home

We'll wrap this up with by building on the commands just covered. First, to get back to your home directory, type "cd" with no arguments. Press enter, and you're back home. Again, note that your prompt reflects this change, by just showing the tilde symbol (~). Which brings me to talk about special characters.

So far, I've shown you things that you can do both in the Finder, and via the command line. Well, what good is that? You're here to learn the power of the command line, right? Good. Let's go!

One of bash's jobs is to break apart your input into tokens, and act in some way on those tokens. Sometimes, you type something that is destined for bash itself. More often, you're really running a command that isn't built-in to bash, so bash has to fire up that command as a process, and pass it any arguments that you've supplied. Arguments are either literal - you've given a name exactly as it exists on the file-system, or, you give bash an approximation or, pattern, to match and have bash figure out the rest. For example, you've now learned that the tilde character is special to bash, and it means "my home directory." However, under the covers, bash expands this to its real value. My home is at /Users/marczak. When I type "cd ~" to go home, bash calls 'cd', but changes the parameter from '~' to '/Users/marczak', without you having to do anything. There are more characters that have special meaning to the bash shell.

Of all the characters that bash recognizes as special, the string wildcard character is probably the most-oft used. Since it's used elsewhere, you're most likely familiar with the asterisk ("*") being used in this capacity. "ls" is a great tool to illustrate how this works. Earlier, we simply asked 'ls' to display all contents in our current directory. However, "ls" will list specific items when asked to do so. For instance, no matter where you are in the file-system, you can type "ls -l ~" to see the contents of your home directory. Remember again, that bash turns the tilde into "/Users/username" before 'ls' ever sees the parameter. That's a hugely important concept. "ls" itself does not have to figure out what the tilde means - it never sees it.

Make sure you're in your home directory ("cd" [enter]) and type "ls -ld Public". You'll see something like this:

drwxr-xr-x  4 marczak  marczak  136  6 Oct 08:46 Public

The "d" switch tells ls that if the argument is a directory, that you want to see the directory name, and not its contents. Without the 'd' switch, this is what happens with "ls -l Public"

drwx-wx-wx  3 marczak  marczak  102  6 Oct 08:46 Drop Box

See? We're shown the contents of 'Public'. However, there are situations that you don't know the exact name of the file or directory. That's where the string wildcard comes in. Try this: "ls -l P*". You should get something similar to this:

drwx------     29 marczak  marczak   986 30 Dec 07:17 Pictures
drwxr-xr-x   4 marczak  marczak   136  6 Oct 08:46 Public

I don't think you can do that with the Finder. Want to see which "iApps" you have installed in /Applications ?

$ ls -ld /Applications/i*
drwxrwxr-x   3   root        admin   102 15 Dec 09:25   /Applications/iCal.app
drwxrwxr-x   3   root        admin   102 12 Mar  2004   /Applications/iChat.app
drwxrwxr-x   3   root        admin   102  3 Mar  2004   /Applications/iDVD.app
drwxrwxr-x   3   root        admin   102  6 May  2004   /Applications/iMovie.app
drwxrwxr-x   3   root        admin   102 10 Aug  2004   /Applications/iPhoto.app
drwxr-xr-x   3   marczak   marczak   102 23 Jan 00:29   /Applications/iStumbler.app
drwxrwxr-x   3   root        admin   102 10 Aug  2004   /Applications/iSync.app
drwxr-xr-x   3   marczak   marczak   102 14 Apr  2004   /Applications/iTerm.app
drwxrwxr-x   3   root        admin   102 14 Jan 08:48   /Applications/iTunes.app

Conveniently, the string wildcard can be used anywhere in the pattern, and it will match any number of characters. For example, I may need to find all of my Konfabulator widget directories. I'll go to my ~/Documents directory and type:

$ ls -ld *Widgets*
drwxr-xr-x    5   marczak  marczak    170      29 Dec 01:02 Older Widgets
drwxr-xr-x   17   marczak  marczak    578      10 Nov 08:54 Older Widgets December 29
drwxrwx---    30   marczak  marczak   1020      30 Dec 07:07 Widgets

Notice the pattern: wildcard up front, and one in back. This way, we find the word "Widgets" no matter where it appears. One last reminder about this: it's the bash shell that takes care of dealing with the wildcard. This is called expansion. In the previous example, the bash digs through the file-system, finds the matches, and then passes that to "ls". When we typed "ls -ld Widgets", "ls" only saw this:

"ls -ld 'Older Widgets' 'Older Widgets December 29' 'Widgets'"

While I paraphrased that slightly for ease of explanation, the point is that it's the shell that deals with the special characters, and the programs and built-in commands never see that input.

One great way to test shell expansion (also known as globbing), is with the 'echo' command. As you can imagine, 'echo' will echo its arguments to the console. If you type "echo Hello there." and press [enter], echo will spit out "Hello there." right back at you, and then hand you back the prompt. 'echo' also respects the patterns and special characters we've discussed. To see what I mean, try this: "echo ~/P*". I get this:

/Users/marczak/Pictures /Users/marczak/Public

Naturally, you'll have your user name in place of mine. This: "echo ~/*ib*" gives me this:

/Users/marczak/Library

There are more special characters that the shell recognizes. If you'd like to see all files that begin with an e, q or v, we can use character-set wildcards (or, bracket wildcards). This: "ls -l /usr/bin/[eqv]*" gives us this:

-r-xr-xr-x   1   root   wheel   85800      26 May   2004   /usr/bin/eaytest
-rwxr-xr-x   1   root   wheel   98260      26 May   2004   /usr/bin/efax
-rwxr-xr-x   1   root   wheel   89444      26 May   2004   /usr/bin/egrep
-rwxr-xr-x   1   root   wheel   30716920   21 Jul   2004   /usr/bin/emacs
-rwxr-xr-x   1   root   wheel   37921      12 Sep   2003   /usr/bin/enc2xs
-rwxr-xr-x   1   root   wheel   292356     26 May   2004   /usr/bin/encode_keychange   
-rwxr-xr-x   1   root   wheel   164756     26 May   2004   /usr/bin/enscript
-r-xr-xr-x   1   root   wheel   14044      26 May   2004   /usr/bin/env
-r-xr-xr-x   1   root   wheel   35856      26 May   2004   /usr/bin/error
-rwxr-xr-x   1   root   wheel   61164      26 May   2004   /usr/bin/escputil
-rwxr-xr-x   1   root   wheel   84784      26 May   2004   /usr/bin/etags
-r-xr-xr-x   1   root   wheel   14036      26 May   2004   /usr/bin/expand
-rwxr-xr-x   1   root   wheel   117424     15 Dec   20:33  /usr/bin/expect
-r-sr-xr-x   1   root   wheel   20072      26 May   2004   /usr/bin/quota
-rwxr-xr-x   1   root   wheel   3266       12 Sep   2003   /usr/bin/vers_string
lrwxr-xr-x   1   root   wheel   3          12 May   2004   /usr/bin/vi -> vim
lrwxr-xr-x   1   root   wheel   3          12 May   2004   /usr/bin/view -> vim
-rwxr-xr-x   1   root   wheel   967284     26 May   2004   /usr/bin/vim
lrwxr-xr-x   1   root   wheel   3          12 May   2004   /usr/bin/vimdiff -> vim   
-r-xr-xr-x   1   root   wheel   15004      26 May   2004   /usr/bin/vm_stat
-r-xr-xr-x   1   root   wheel   40564      10 Feb   15:09  /usr/bin/vmmap

As expected, all of the files start with e, q or v, and the asterisk wildcard matches anything remaining. The brackets will also accept a range of characters. If you had a group of files, named by date, you could find all of the files in a directory for the year 2001-2004 with the command "ls -l 200[1-4]*". Don't forget that you can group these any way you'd like. To find dates that match 1973-1975, 1983-1985 and 1993-1995, you could use this: "ls -l 19[7-9][3-5]*".

You can also tell bash that you want everything but certain patterns. This is the job for the 'not' operator, which is represented by the exclamation point ("!"). If I want to find everything in a directory that starts with 'p', but does not end in 'sh', I'd type "ls -ld p*[!sh]", and would see:

-rw-r--r--  1 marczak  marczak  21251 12 Jan 11:09 printjobfail.zip

...even though this directory contains "printlist.sh" and "psched.sh".

Similar to the square brackets, you can use curly braces to match a list of values. The list is separated with commas. For example, if you want to list all of the graphic files in a directory, you could use "ls -l *.{gif,jpg,bmp,swf}". Note, though, that you will receive a "No such file or directory" message from ls for anything in the list that it couldn't find. echo, naturally, will just echo the expansion back at you, like this: "echo *.{sh,txt,xxx}"

fort.sh showds.sh upsafari.sh 1.txt mailcap.txt *.xxx

Note the "*.xxx" hanging on the end there, as the shell didn't find a match, it passes this to echo unaltered.

Lastly, we'll cover the question-mark wildcard. The "?" character simply matches any one character. So, in a large directory, typing "ls ?at.txt" could potentially give us:

bat.txt     cat.txt      rat.txt

There are other characters that trigger actions in bash, such as expansion, input/output redirection, job control, and more. While these characters are very helpful, they can also trip you up. When bash sees any of these characters in its input, it tries to act on them the way intended unless you tell it otherwise. One character that is particularly troublesome for people is the ampersand ("&"). For now, just know that this causes bash to run your command in the background. When there's an ampersand on the line, bash runs your command and immediately has you back the promt. Great for long running jobs that have no interaction.

But what if in the Finder you've named a folder "5&7", and you need to access it while in a terminal? Well, let's see. Open up your home directory in the Finder, and create a directory named "5&7". In the terminal, change to your home directory, and type "cd 5&7". You'll get:

[1] 2299
bash: cd: 5: No such file or directory
bash: 7: command not found
[1]+  Exit 1                  cd 5

What's going on here? Since the ampersand puts your command in the background, the first line tells you the job number that bash assigned so you can track it later on. Since the "&" character has special meaning, bash has (roughly) tokenized the input into "cd 5 &" and "7". It runs "cd 5", and tells you "No such file or directory". It tries to run a command named "7", and reports that it's not found. Finally, we're told that job number 1 has finished (exited out of its subshell).

How can you get the shell to treat special characters as normal, plain-old characters? You need to quote them. One way to do this is to use the backslash escape. This tells bash to ignore the special attributes of the character that immediately follows it. When you use tab-completion, you'll notice that bash backslash-escapes characters for you. Try typing "cd 5[tab]", and you'll see that bash completes with "cd 5\&7/". It escapes the ampersand by placing a backslash in front of it. It will do this with most special characters. Here's a list of characters that have a special meaning for bash:

*      Wildcard
?      Character wildcard
[ ]    Character-set wildcard
{ }    String-expansion wildcard / Command block
~      Home directory
`      Command substitution (backtick)
$      Variable
&      Background job
( )    Subshell
\      Quote
|      Pipe
>      Redirect output
<      Redirect input
/      Path separator
!      Logical NOT / History expansion
;      Command separator
'      Strong quote
"      Weak quote
       Space
@      Positional parameter list (only when used in double quotes)

This is not an all-inclusive list, but it contains the characters that will cause you problems if you want them to behave without their special powers.

One interesting way to deal with this only works (currently) with Terminal.app. You can drag and drop files and folders from a Finder window onto your Terminal.app window. Terminal.app will substitute the full pathname of the object dropped, properly escaped and quoted. Pretty cool.

The other ways to quote are to use the quote characters...who'd-a-thunk, eh? The single quote is a hard quote. From the bash man page: "Enclosing characters in single quotes preserves the literal value of each character within the quotes. A single quote may not occur between single quotes, even when preceded by a backslash." Basically, we could replace our example above by typing "cd '5&7'".

Double-quotes are soft-quotes. Again, from the bash man page: "Enclosing characters in double quotes preserves the literal value of all characters within the quotes, with the exception of $, `, and \. The characters $ and ` retain their special meaning within double quotes. The backslash retains its special meaning only when followed by one of the following characters: $, `, ", \, or <newline>. A double quote may be quoted within double quotes by preceding it with a back-slash. The special parameters * and @ have special meaning when in double quotes." I'll be going deeper into this concept next month.

Getting Help

This material has been a basic, but important foundation. If you understand these concepts, you're ready for more. Plenty more is coming next in next month's column. But what about the time between now and then? You want to experiment, right? You want to see what else can be done on the command line.

Last month's column talked a little bit about tab completion. You type a few letters, hit tab, and the shell tries to complete your words with a match. Unlike the crummy tab completion in Windows, if there are multiple matches, bash beeps at you to let you know. Pressing tab again will display the matches. What we didn't cover last month is that this works with commands, too. Try this: type "ls" and press tab twice. You'll see all of the commands (in your path) that begin with "ls". Here's what I get: "ls lsbom lsof lsvfs". OK...'ls'...check, 'lsbom'....good...'lsof'...know it...'lsvf...what is that?'

There are a few ways to find out what that is. One way is the 'whatis' command. Try typing "whatis lsvfs", and you'll get this answer:

lsvfs(1)                     - list known virtual file systems

Oh, OK! How does that compare to something we know? Press 'q' to get out of the listing for lsvfs and type "whatis rm". I get:

rm(1), unlink(1)            - remove directory entries

Well, yes, that sums up the rm command nicely. What does whatis have to say for itself?

$ whatis whatis
apropos(1), whatis(1)      - search the whatis database
getNAME(8)                 - get NAME sections from manual source for whatis/apropos data base
makewhatis(8)              - create whatis database

Wow, that's a little more information than we got with the other commands. You'll notice that there are two entries that claim to 'search the whatis database'. The 'apropos' command is basically the same as whatis, except the parameter that you give it is a pattern (specifically, it's a regular expression, which, yes, will be dealt with in a future column). Unless you're careful, apropos can give you tons of output. There's two ways of getting help that are much more useful.

The bash shell itself has built in help using the 'help' command. Try it. This help is great, but only covers bash, and not the many, many, many commands that exist on the system outside of bash's built-ins. If you want to know more about lsvfs than simply that it will "list known virtual file systems", you'd use 'man'. 'man' let's you access the Unix documentation stored in the 'man'ual pages database. You tell 'man' which command you'd like to read up on: "man lsvfs" gives much better detail about this command:

LSVFS(1)           BSD General Commands Manual          LSVFS(1)                  

NAME
     lsvfs - list known virtual file systems

SYNOPSIS
     lsvfs [vfsname ...]

DESCRIPTION
     The lsvfs command lists information about the currently        
     loaded virtual filesystem modules.  When vfsname arguments       
     are given, lsvfs lists information about the specified VFS       
     modules.  Otherwise, lsvfs lists all currently loaded          
     modules.  The information is as follows:

     Filesystem     the name of the filesystem, as would be used in       
                    the type parameter to mount(2) and the -t option to mount(8)
     Refs           the number of references to this VFS; i.e., the       
                    number of currently mounted filesystems of this type
     Flags          flag bits

SEE ALSO
     mount(2), mount(8)

HISTORY
   The command from which this was derived from, as well as       
   this manual, originally appeared in FreeBSD 2.0.

BSD                    January 4, 2003                    BSD

This is a nice, short example of a typical man page. Many other man pages can get fairly lengthy. Just as I've introduced you to the 'ls' command and some of it's switches that alter its output, please read the man page ("man ls") and understand the depth of this seemingly simple command!

Man pages exist for your reference and convenience. Take advantage of them! As form of homework for next time, read the man page for 'ditto'. It's an important Mac replacement for the 'cp' command.

In a month, then...

Like anything, the command line takes a little practice. This month's reading should ease you into usage, and point you towards ways to learn a bit on your own. Until next time, though, here's one more thing to try: without typing anything, press tab twice and answer 'y'...just look at all of the commands in there to learn about!

Ed Marczak owns and operates Radiotope, a technology consulting company that guides clients to use technology to its fullest. In addition to the Acorn, Vax, PDP-11, Timex Sinclar and Commodore 64, Ed dabbles with the Mac.