The box arrived from NoStarch Press and ...

In script #7 under MacOS 10.2.8; I get a cut error:

[home:~/scripts] smac% valid-date november 25 1963
usage: cut -c list [file1 ...]
cut -f list [-s] [-d delim] [file ...]
usage: cut -c list [file1 ...]
cut -f list [-s] [-d delim] [file ...]
usage: cut -c list [file1 ...]
cut -f list [-s] [-d delim] [file ...]
valid-date: Unknown month name 25

It appears that its taking the second field for the month,
rather than the first. It fails on every date entered.

I've verified that normdate works properly:

[home:~/scripts] smac% normdate november 25 1963
Nov 25 1963

... and I freely admit that I'm a clueless puppy trying to learn scripting by doing.

Help? :)

smac

As you reported to me in email, your problem was that you'd copied the cut statements like this:

month="$(echo $newdate | cut -d\ -f1)"
day="$(echo $newdate | cut -d\ -f2)"
year="$(echo $newdate | cut -d\ -f3)"

The problem is that you need TWO spaces after the backslash. Fix that, and it works fine. :-)

Am very interested in your book after seeing you on the Screen Savers last night (4/19/04). I tried the bestcompress script but it looks like I'm getting incorrect results. I'm running it on a 7767 txt file and it reports compress as the best choice resulting in a compressed file size of 4493. If however I run gzip and bzip2 on the txt file I get file sizes of 3715 and 3559 respectively. So it dosen't appear that compress is the best choice and bestcompress is not comparing the file sizes correctly. ???

Thanks for your note, Dennis. You're correct: it turns out that by default the ls command wants to sort filenames alphabetically, which turns out to be a problem with this particular script. The good news is that it's super easy to fix: instead of using "ls -l" in this script use "ls -lf" instead. There's a more detailed explanation on the main page of the booktalk weblog...