(1)  Look at this howler, from SuSE's /etc/rc.status;
compare what it does with what the comment claims it
does ...

# Make sure we have /sbin and /usr/sbin in PATH
case $PATH in 
	*sbin*)
		;;
	*)
		export PATH=/sbin:/usr/sbin:$PATH
		;;
esac

(2)  On at least some recent Mandrake distributions,
the "last" command doesn't work for non-root users.
Why?  Because /var/log/wtmp is mode 0640.  No idea
as to why.

(3)  Perhaps other UNIXes suffer from this one, too;
thus far I haven't checked.  If you build some a.out
using "-lfoo", which directories get checked in which
order for libfoo.a?  With RedHat Enterprise 4 (x86_64),
it's ...

	/usr/lib64
	/usr/lib
	/lib64
	/usr/local/lib64
	/usr/local/lib
	/lib

But if you link against a shared object, and you have
nothing in your LD_LIBRARY PATH, where does it search
for libfoo.so when you run the a.out?  Only ...

	/lib64
	/usr/lib64

This raises some interesting questions.  For example,
why the inconsistency between where the linker looks
for a static library, and where the dynamic loader is
looking for a shared object?  Why are the /usr/local
libraries plopped right in the middle of the list?
(I'd expect to find them either at the beginning or
the end.)  And why, in that second list, does /lib64
come before /usr/lib64, whereas in that first list,
their order is reversed?

(4)  Again looking at Mandrake, ksh scripts which
work fine on other distros fail; but _only_ when
run as root.  Why?  Well, look at this ...

asap> cat foo-sh
#!/bin/sh
/bin/echo foo

asap> cat foo-bash
#!/bin/bash
/bin/echo foo

asap> cat foo-ksh
#!/bin/ksh
/bin/echo foo

asap> foo-sh | od -c | sed 1q
0000000   f   o   o  \n

asap> foo-bash | od -c | sed 1q
0000000   f   o   o  \n

asap> foo-ksh | od -c | sed 1q
0000000   f   o   o  \n

Just what you'd expect.  But look what happens if
you're logged in as root ...

-bash-2.05b# foo-sh | od -c | sed 1q
0000000   f   o   o  \n

-bash-2.05b# foo-bash | od -c | sed 1q
0000000   f   o   o  \n

-bash-2.05b# foo-ksh | od -c | sed 1q
0000000 033   [   3   6   l 033   >   f   o   o  \n

Of course, this totally breaks things if you have some
script which invokes a ksh script, and does ...

	stuff=$( some_ksh_script )
	case "$stuff" in
		foo)	foo_processing ;;
		bar)	bar_processing ;;
		*)	whoops_processing ;;
	esac

I've determined that the dreadful escape sequence botch
happens only if (1) one is logged in as root and (2) the
login shell for root is bash.  In other words, changing
root's login shell to sh (which is just a link to bash,
but it behaves differently when invoked as "sh") makes
the problem go away.  And non-root users who have bash
as their login shell don't encounter the problem.

I presume this is all the result of some ugly goo buried
down in the bowels of /etc/bashrc, but at the moment I'm
not too inclined to spend a lot of time figuring it out.