This page is an attempt to solidify the many comments I have made regarding the cleanliness of (and my preferences for) differing unix utilities. There are only a few programs on the list I would never use (I've installed linux packages just to avoid using pine), but I figure that publishing my preferences will lead to my learning more about programs that I currently "despise."

I have recently been pointed to a rant against C++ by Keith Adams (kma) which I am tempted to completely agree with, except that I don't know enough about C++ due to my general efforts to avoid it whenever possible.

Soren's Unix Preferences

tcsh

I almost put emacs first but emacs has more use than tcsh (M-x vip-mode and colors are nice though check out gvim and maybe we'll convert you to the good side--awh, heck, I don't even like vim very much). tcsh is based on csh: perhaps the most useless shell programming tool in the world. I started to hate it when I found I couldn't redirect stderr (how is anyone supposed to use find in dirs they don't own without 2> /dev/null???) and then I was directed to this document. I recently discovered that not only does the "vi"-mode of fail to do searching intelligently (/ goes the "right" way) but it also does not have xp for swapping characters.
Soren uses ksh. bash is acceptable if you are a tab-complete weany. (hey, pdksh has a tab-complete option!) Another thing I remembered later: tcsh doesn't use the kernel's tty line driver so a) it has to cross the kernel / user boundary for every letter you type (try running truss or strace on your shell [$$] today) and b) it doesn't have ^W support. Both of these seems to be due to 'emacs' mode editing ... even my beloved ksh is forced to trap on every character after a 'set -o emacs.'

pine

Slightly less useless than tcsh, but probably less useful to mad-hackers than emacs-19, pine is one mail program that trivialized unix email and editing, but sacrificed speed/robustness. Its maintainer on this system had to fix a bug where pine crashed reading /u because it ran out of space in its buffer for filenames...somehow based on the size of the directory...ohh wait, that is automount swilliness. For some reason, people in Brown CS are enamoured with this swilly, slow program despite the existance of several better mail readers. For those who want a menu-driven interface, I suggest elm or mutt (even threads your mail!). Soren uses mail (the copy in /usr/local/bin...the one that prompts for a subject...).

emacs

escape-meta-alt-control-shift should not be my editor. I also don't need my editor to be turing complete. I still believe in "small is beautiful". emacs-19 is acceptable but I, Soren, as a vi lover, use vi. No one should use pico after reaching unix puberty. If you are interested in vi and don't know where to start: try brown.cs.vi. Or, check out a page you might have found via my "4-letter word" link on the my home page.

acroread

Since I have received approximately 100 questions about "why didn't this print" as a direct result of poor acroread defaults, I was led to find a better program. The latest version of ghostview (the classic postscript viewer) not only read pdf, but prints correctly, starts faster, and has a prettier interface (IMO) than acroread. Soren calls up ghostview with gv. I hear you can select text in acroread...still USELESS (well, maybe not entirely, but man PDF feels slow).

less

I have to admit that my PAGER was once set to less because the only program (besides ph) that I run that uses the PAGER is man and I liked reading man pages with less. Using less -X -e is essential so that email addresses gleaned from ph are not lost when you want to type the mail command. But more is the original utility and I like a program that acts like cat when a file is not bigger than the screen. Old machines often see a lag when loading the bloated less binary. Hitting v in more or less is cool. I also admit scrolling back off pipes is cool, but do you have any idea how much memory that must require?

Please mail me if I have made any errors or if you think there are salient points to any of these programs that I might have missed. Thanks for reading... :)