2 Lessons You Won't Learn From Generating Your Shell Scripts

The cycle time for creating a new shell script has plummeted due to LLMs. I've seen social media personalities claim this means you can stop learning shell scripting and rely on LLMs for Linux knowledge. That's a take from someone who doesn't love Linux. As you develop your mental model of Linux, it gets easier; as Linux gets easier, you enjoy it; as you enjoy it, you love it.

Here are two small lessons you learn by writing shell scripts.

You Have To Check Your Errors

When I began shell scripting, I assumed a failed command would halt a shell script. It doesn't:

#!/bin/sh
ls /does-not-exist
echo "This line is reached after the failed command"

$ ./a-failing-command-does-not-stop-your-script.sh
ls: /does-not-exist: No such file or directory
This line is reached after the failed command 

If you follow the bad advice of not learning shell scripting, you won't learn that proceeding after a failed command is expected behaviour, not a bug.

You'll probably get error handling from an LLM by default. If you don't know that set -e is checking a process' exit status, then you won't know when you should embed set +e to turn the check off.

You Have To Know Your OS's Behaviour

Linux is a member of the family of Unix-compatible operating systems. Every Unix-compatible operating system has a Bourne-compatible shell, sed, awk and a host of other tools. They behave differently on different operating systems, the kernel behaves differently, and you need to learn that.

In this example I'll run a script first on macOS, then on Alpine Linux:

#!/bin/sh -e -o pipefail

echo ">>> hello, world!"

mac$ ./kernels-parse-shebangs-differently.sh
>>> hello, world!

alpine$ ./kernels-parse-shebangs-differently.sh
/bin/sh: illegal option -

The error is because macOS' XNU kernel parses a shebang line differently to Linux. Linux passes the arguments as a single string; the interpreter doesn't know how to parse that. From the docs:

On Linux, the entire string following the interpreter name is passed as a single argument to the interpreter, and this string can include white space.

from the Linux execve man page

XNU parses all of the arguments separately and hands them to the interpreter separately, as we intuitively would expect. Details are available in the Apple execve man page.

These differences are there because Unix-like OSes implement POSIX, a standard that doesn't specify a lot of details, and underspecifies what it does describe. That gives OS implementors flexibility, but means you and I have details to learn.

I'm confident that a short LLM-generated script will work correctly on your laptop. It might work on your target OS for production, but when it doesn't you won't know how to guide the LLM clearly.

Don't cheat yourself of the joy of learning how this stuff works. The small details add up to a larger picture; good habits mean an error in Production is an opportunity to learn more; learning develops into mastery.

Not confident you know how to map out a learning plan? Reach out on my contact form and I'll help you come up with a plan.

Want to learn more about Unix in general? Check out my Newsletters. An Evening with Berferd is particularly relevant here.