Useful stuff to note - (Mainly) Bash scripting

I have a wealth of stuff stuck in Bash scripts that I've generated over the years.  Some of the most useful tips, and some of the most rarely used things that I want to note down for myself are probably:

• stat - such a simple but terribly useful command.  With the -f switch it gives you filesystem info about where the file you pass it is located.  Without it you get easy access to any information about the file you could ever need.
• Parameter substitution - insanely useful for stripping off paths or extensions from filenames, for setting default variables if they're not explicitly set by something else, string handling, providing sensible error messages, so much good stuff.  Have a look at these links for more information:
• http://www.tldp.org/LDP/abs/html/parameter-substitution.html
• http://www.cyberciti.biz/tips/bash-shell-parameter-substitution-2.html
• shellcheck.net.  Paste your shell script (or sections of it) into this tool, and it will tell you about any glaring errors (e.g. not quoting variables)
• Quoting.  One of the problems that most newcomers to shell scripting have is that of whitespace and quoting.  Basically - if there's even the remotest chance that your strings may perhaps possibly one time contain spaces or tabs or whitespace, quote them in double-quotes.  It's no hardship on you and it'll save your bacon one day.
• If setting up paths with this kind of construct - being very very careful:
    FILE=$DIRECTORY/$FILENAME
  Why?  What happens when your script somehow ends up with blank $DIRECTORY and $FILENAME variables?  Consider what happens if your script does an "rm $FILE" later on.  Especially if it does an "rm -rf $FILE" later on.
  
  Still struggling?  Empty variables are just ignored.  So if $DIRECTORY and $FILENAME are blank, the output of "rm -rf $FILE" will be "rm -rf /".
• [ ] && { command1 ; command2 ; }
  [ ] || { command3 ; command4 ; }
  One of the tidiest ways of doing short "if, then" statements.  In the first example, command1 and command2 will only be executed if the output of the test is true.  It follows logically because if the output of the test was false, it doesn't matter what the output of the 2nd section is, FALSE && TRUE is always false so there's no need to check what the other commands return.
  
  In the second example, the commands 3&4 are only executed if the result of the test is false. Again, logically speaking, if the first section returned true, TRUE || anything is true, so why bother checking what the rest returns?
• printf
  Always always always attempt to use printf in your Bash scripts when outputting anything.  Why bother?  Why not just use echo, it's simple and really quick!  printf is a pain.
  
  Not only is printf portable whereas echo doesn't behave the same on the same OS, never mind on different versions, but printf gives so much flexibility in your output.  There is nothing that you can do with echo that you can't do with printf.
• Portability.  You may think that your script won't ever be used on a Solaris server, and certainly won't have to be used on HPUX.  Hah.  Think again.  One day, Linux will fall out of fashion.  Perhaps your CIO will have a strong preference for Solaris and you will have to port it all.  If you write your code in a portable fashion, it'll save you a lot of work later on.
• I/O redirection.  Being able to direct the output from your tools to somewhere useful for you is the cornerstone of any good shell scripter.  The various redirections (e.g. >, |, >>, >&, 2>, |& - warning - not all portable!) can build up and allow you to put the output from your script wherever you want it.

There's so much more, but the above are all tools and things that any shell script creator/maintainer should know.