One of my clients (a Mac-based computer consulting company here in Los
Angeles) had a BASH script they wanted me to look at -- a couple of
things weren't working the way the client thought they should be
working.

The client's issues are resolved, but I noticed something in the script
that I wanted to dig into further. They were redirecting STDOUT and
STDERR to a file like this:

command_to_execute &> logfile.txt

This is a wonderfully efficient (in terms of characters typed) and clear
way of doing the redirection. It's much more elegant than the way I
normally do this type of redirection:

command_to_execute > logfile.txt 2>&1

Let me briefly break down what each of the above commands are doing, and
then I'll explain why the way I do it (despite being ugly) is better
than the elegant way in most cases.

Command-line programs running under Linux and Unix (including OS X)
output to either STDOUT (for standard output) or STDERR (for error
output). When you're running a command interactively on the terminal,
you see both STDOUT and STDERR together, and in fact, you can't tell
visually what output comes from STDOUT and what comes from STDERR.

When you want to save output to a file, though, you have choices.
Redirecting with just a > gets just STDOUT. The following will save
STDOUT to the log file and print STDERR output on the screen:

command_to_execute > logfile.txt

The following will save STDERR to the log file and print STDOUT on the
screen:

command_to_execute 2> logfile.txt

But what if you want to redirect BOTH STDERR and STDOUT to the log file?
Using the &> notation is certainly less typing, but it only works in
BASH versions since 4. My web host running FreeBSD has version 4.0.35
(so &> would work) but my OS X desktop running Mountain Lion has
version 3.2.48, so the &> trick wouldn't work. It also doesn't work in
sh, Dash, or most shells except recent versions of BASH.

What I do is, first, use a single > to redirect STDOUT to a file, and
then use 2>&1 to redirect STDERR to STDOUT. This works in every shell
I've tested it in, from old versions of sh to dash, BASH, and others.
It's a little more to type, and you really have to memorize it because
it's not an intuitive syntax, but once you do it's almost as easy to use
as &>.