34.8 getopts: Parsing Command-Line Options in Scripts

Right, so you’ve written a bash script. It’s beautiful. It does one thing perfectly. Now you want to make it useful for other people, or for future-you at 2 AM, which means it needs to handle command-line options. You could manually parse $1, $2, etc. I’ve done it. You’ve done it. It’s a mess that quickly spirals into a nested if nightmare of checking for -- and -. Don’t do that. Bash gives you getopts, a built-in command designed specifically to save you from that particular brand of self-flagellation. It’s not without its quirks (it’s a bash builtin, after all), but it’s the right tool for the job.

34.7 Exit Codes, $?, $!, and $$: Special Variables

Right, let’s talk about the little status reports your commands are constantly sending back to the shell. You’ve probably seen a command fail and thought, “Well, that didn’t work.” But your shell doesn’t just think that; it gets a definitive, numerical verdict on every single thing you run. This is the bedrock of scripting logic, and if you ignore it, your scripts will be as fragile as a house of cards in a breeze.

34.6 Functions: Definition, Local Variables, and Return Values

Right, so we’ve been throwing commands at the terminal one by one like we’re paying by the line. It’s time to graduate. Functions are how we stop repeating ourselves and start building actual tools, not just one-liner party tricks. Think of them as your own custom commands. You define them once, give them a name, and then you can use them anywhere in your script. It’s the difference between duct-taping pieces together and actually owning a toolbox.

34.5 Case Statements for Pattern Matching

Right, so you’ve graduated from a simple if statement. Good for you. But what happens when you have a dozen different potential conditions to check against a single variable? You could write a horrifyingly long chain of if, elif, elif, elif… but you’re better than that. You’re not a monster. Enter the case statement: the Swiss Army knife for pattern matching in bash. It’s cleaner, more efficient, and frankly, it looks a lot more professional.

34.4 Loops: for, while, until, and break/continue

Right, let’s talk about loops. Because if you’re going to be telling this computer what to do, you’ll inevitably need to tell it to do the same thing over and over again. That’s the whole point of scripting, and loops are how we avoid copying and pasting the same line of code fifty times. It’s automation 101, and bash gives you a few solid, if occasionally quirky, ways to get it done.

34.3 Conditional Expressions: if/elif/else, test, [[ ]], and (( ))

Right, let’s talk about making your bash scripts smart enough to make decisions. This is where you move from just running commands in sequence to building something that can react, adapt, and occasionally sass you back. We’re going to cover the if statement’s entourage: test, the modern [[ ]], and the math-focused (( )). Pay attention, because the differences here are where most beginners (and let’s be honest, a few pros) faceplant.

34.2 Variables: Assignment, Quoting, and ${var} Syntax

Right, let’s talk about variables. This is where we stop just typing commands and start actually programming in bash. It’s also where bash, in its infinite, crusty wisdom, will happily wait for you to make a mistake and then blow up your script. I’m here to make sure that doesn’t happen. First, the golden rule: there are no data types. Everything is a string. Want a number? It’s a string that happens to have digits. Want an array? We’ll get to that nightmare later. For now, just know that you’re working with text. This is both bash’s greatest simplicity and the source of its most hair-pulling frustrations.

34.1 Shebang Line and Script Permissions: Making Scripts Executable

Right, let’s get this script party started. Before you can write the next great American novel in bash, you need to do two incredibly boring but absolutely critical things: tell the system what interpreter to use and make the darn file executable. Skip this, and you’ll be staring at a Permission denied error, wondering if the universe is personally rejecting your genius. It’s not. You just skipped the paperwork. The Shebang: Your Script’s First Line of Defense The very first line of any script you write must be the shebang (#!). This isn’t a suggestion; it’s a contract. When you run an executable file, the kernel looks at the first few bytes. If it sees #!, it knows, “Aha! This is a text file meant for an interpreter,” and it then reads the rest of the line to find out which interpreter.

— joke —

...