I often prefer the shell and Unix utilities to having to wait to load data into a relational database or MS Access (unless a lot of what I'm doing requires complex joins). It's often possible to not even have to transform the encoding of the files before analyzing them. There are a couple of recipes for doing SQL equivalents with the shell utilities. There are a bunch of them, these are a few that I just used this morning. Most of the time all it takes is a bit of imagination about how to create a simple data-flow by composing a small handful of ubiquitous Unix utilities.

All these examples will also work within the Cygwin environment for Windows, or at a Terminal in OS X (especially when combined with the additional software available via Fink or Mac Ports projects..

Just selecting the count of records from an input file is one of the easiest things to accomplish (if your file is already line-oriented). The wc, or word count utility can do this easily. By default it counts characters, words and lines. With '-l' it will emit only the count of lines.

user@host:~/data$ wc -l table.tab
10

If you want to ignore the header, start with the second line (see the next example for a more thorough explanation):

user@host:~/data$ tail -n +2 | table.tab
9

For getting a distinct count of values in a column :

user@host:~/data$ cut -f1 table.tab | tail -n +2 | sort | uniq -c

The first part cut is a utility that allows you to take particular columns from a tab-delimited file, or character ranges from a fixed-width file. cut also allows you to specify the delimiter - but be warned that the commonly encountered CSV format requires more complexity in parsing than just using a comma as a delimiter. So this takes the first column out of the input file.

The next part of that is the tail command. tail is a command that outputs the end or 'tail' of a file. The '-n' option says what line number to start at (counted from the end of the file) - in this case the '+' tells tail to start at the second line from the beginning. This effectively tosses out the header line.

Next the values themselves are sorted. This is necessary for the uniq command, which will only collapse or count duplicate lines when they are adjacent.

Finally we reduce duplicate lines with uniq. The '-c' tells it to emit the count of duplicates when collapsing them.

Dealing with varoius file archive types

I often work with files in zip archives and tar (unix tape archive) archives, sometimes with additional compression applied to them (.Z, unix compress; .gz, gzip; and .bz2 bzip). It is possible to work with these files without having to unarchive or decompress them permanently if all you need is a simple count of lines or to only process them once.

Pulling a file from a Zip Archive

To pull one or more files from within a zip archive, and send them to another command (as part of a pipeline):

user@host:~/data$ unzip -l archive.zip
Archive: archive.zip
  Length    Date   Time   Name
 --------   ----   ----   ----
      34  04-28-08 11:01  table1.tab
      56  04-28-08 11:01  table1.tab
user@host:~/data$ unzip -c archive.zip table1.tab table2.tab | wc -l
36

That example uses the unzip command to pull 2 files out and send them to standard output - to either the screen or the next command in the pipeline. In this case that is wc to get the combined record count for the two files. We don't have to worry about cleaning up the two files when we're done either.

unzip -l lists the files in a zip archive. If we left off the '-c' (and the '| wc -l') unzip would have extracted just those two files from the archive (in case there were more and you only wanted a small handful).

Dealing with various file encodings

The first barrier to using most of these readily available utilities is often the file formats themselves. The utilities are line-oriented for the records and tab-oriented for the fields. So the first step is often figuring out how to even get your data into a tab-delimited format.

There is more to that than I have time to write right now. I'll work at following up with examples for another posting.

I took the "make the title of your presentation confrontational" advice and changed the title from "Introduction to Lisp" to "Why Won't Lisp Just Go Away?"

It went much more smoothly the second time around. I also got some good feedback from Rob DiMarco and JP Vossen (author of the Bash Cookbook). It has been difficult to come up with a 60-90 minute talk, keeping it short enough, while still talking up the strong points.

We all have constants in our applications, sometimes we have
numeric values that are only used once and are clearer if they're left
as an expression (like the number of seconds in a day, well these
things are better off as constants in many cases, though I'm only
using it as an example).

(defun days->seconds (days)
  (* days (* 24 60 60)))

(format t "seconds in ~a days:~a~&" 1 (days->seconds 1))

(time (loop repeat 1000000
	    do (days->seconds 10)))
 => 2.093 sec.

In common lisp there is a reader macro you can use to have these
kinds of expressions executed at compile time - and thus use no CPU
time during your running application (or even within the compiled
executable):

(defun compile-time-days->seconds (days)
  (* days #.(* 24 60 60)))

(time (loop repeat 1000000
	    do (compile-time-days->seconds 10)))
 => 1.87s

Admittedly in this case it's not a worthwhile improvement in
performance - but these are the kinds of things many technologies
represent as build processes. When you're configuring a build to be
specialized for a locale, or particular production environment, you
either factor those parts of the application into a configuration
file, or you generate code (almost certainly with some tool set which is
not your programming language).