Book Image

Bash Quick Start Guide

By : Tom Ryder
Book Image

Bash Quick Start Guide

By: Tom Ryder

Overview of this book

Bash and shell script programming is central to using Linux, but it has many peculiar properties that are hard to understand and unfamiliar to many programmers, with a lot of misleading and even risky information online. Bash Quick Start Guide tackles these problems head on, and shows you the best practices of shell script programming. This book teaches effective shell script programming with Bash, and is ideal for people who may have used its command line but never really learned it in depth. This book will show you how even simple programming constructs in the shell can speed up and automate any kind of daily command-line work. For people who need to use the command line regularly in their daily work, this book provides practical advice for using the command-line shell beyond merely typing or copy-pasting commands into the shell. Readers will learn techniques suitable for automating processes and controlling processes, on both servers and workstations, whether for single command lines or long and complex scripts. The book even includes information on configuring your own shell environment to suit your workflow, and provides a running start for interpreting Bash scripts written by others.
Table of Contents (10 chapters)

Avoiding path anti-patterns

Some shell script programmers use absolute paths for even common system tools:

/bin/sed '/^$/d' data

This command line is intended to print the contents of the data file, but to skip blank lines. It does work on most GNU/Linux systems, but why specify the full /bin/sed path? Why not just sed?

Worse, sometimes people try to abbreviate this by saving the full paths in variables, after retrieving them with a non-standard tool such as which:

# Terrible code; never do this!
SED=$(which sed)
$SED '/^$d/' data
Can you see anything else wrong with this code? Hint: what was the very first thing we re-emphasized in this chapter?

This use of which and full paths such as this is unnecessary, and there are no advantages to doing it. Bash will already search PATH for you for any command name; you don't need to rely on which (or even type...