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)

Choosing when to avoid Bash

Bash's design and development effort is less focussed on some other areas. New users who are keen to use Bash often find tasks that require the following to be difficult or impossible in the Bash language itself:

  • Programs requiring speed: The end of the Bash manual page, under the "BUGS" section, reads: It's too big and too slow. This may seem like a joke, but while a compiled bash binary is unlikely to be more than a couple of megabytes in size, it is not optimized for speed. Depending on the task, reading a very large file line by line in Bash and processing data within it with string operations is likely to be significantly slower than using a tool such as sed or awk.

  • Fixed or floating-point math: Bash has no built-in support for fixed or floating-point mathematical operations. It can call programs such as awk or bc to do such things on its behalf, but if you need to do a lot of this, you might want to just write the whole program in AWK, or maybe in Perl instead.

  • Long or complex programs: The ideal Bash program is short and sweet less than 100 lines of code is ideal. Bash programs much longer than this can rapidly become unmanageable. This is partly a consequence of the terse syntax, and partly because the complexity of a script increases faster when much of the work is invoking other programs, as shell scripts tend to do.

  • Serialization: Bash has no native support for serialized data formats such as JSON, XML, or YAML. Again, this is best delegated to third-party tools such as jq or xmlstar, which Bash can call from within scripts. Trying to do this in just Bash is an exercise in frustration for newer programmers.

  • Network programming: Bash does have some support for network programming on some systems, but it does not allow much fine-grained control. It mostly has to lean on external tools such as netcat or curl to do this.

  • Object-oriented programming: Object-oriented programming is not practical in Bash. It does not have any concept of a namespace or classes, a system of modules to separate code, nor any object system.

  • Functional programming: Bash's language design means it does not have any of the primitives that users of functional languages, such as Lisp, Scheme, or Haskell, might expect from a language. It has very limited support for lexical scope, read-only data, indirection (references), or data structures more complex than arrays. It has no support for closures or related features.

  • Concurrent programming: Bash generally just runs commands in sequence. It's possible to run processes in parallel, and to simulate basic concurrency concepts such as locks, but a programming language built with concurrency in mind may be a better choice for tasks requiring multithreading or parallel processing.