Debugging Bash Like a Sire (2023)
blog.brujordet.no
Debugging Bash Like a Sire (2023)
1–10 of 56 posts
Re: Debugging Bash Like a Sire (2023)
#2I never thought of the idea of printing out a stack trace. A logging function is an example of such a good idea that is so obvious that I didn't think of it :-)
I use -e sometimes but I really dislike scripts that rely on it for all error handling instead of handling errors and logging them.
^^ this tool has proven very useful for avoiding some of the most silly mistakes and making my scripts better. If you're maintaining scripts with other people then it is a great way of getting people to fix things without directly criticising them.
Re: Debugging Bash Like a Sire (2023)
#3I've been writing scripts in Bourne shell since the 1980s and in Bash since whenever it came along, and I feel like the most important thing I've learned about it is: don't. Sure, it can be done, and even done well, but why? There are better languages.
Every time I write a shell script that grows to more than about 20 lines I curse myself for not having written it in Python. The longer I have waited before throwing it away and redoing it, the more I curse.
This article says nothing to change my mind. I could build logging and stack traces in Bash. I admire the author's ingenuity. But again, why?
Re: Debugging Bash Like a Sire (2023)
#4I've been writing scripts in Bourne shell since the 1980s and in Bash since whenever it came along, and I feel like the most important thing I've learned about it is: don't. Sure, it can be done, and even done well, but why? There are better languages. Every time I write a shell script that grows to more than about 20 lines I curse myself for not having written it in Python. The longer I have waited before throwing i…
Because it's better at the task than Python is.
Re: Debugging Bash Like a Sire (2023)
#5I've been writing scripts in Bourne shell since the 1980s and in Bash since whenever it came along, and I feel like the most important thing I've learned about it is: don't. Sure, it can be done, and even done well, but why? There are better languages. Every time I write a shell script that grows to more than about 20 lines I curse myself for not having written it in Python. The longer I have waited before throwing i…
It won't be surprising since I wrote [1], but I mostly write bash when I want to create complicated pipelines with fzf, and I don't want to write Go code to go the same thing.
Re: Debugging Bash Like a Sire (2023)
#6I find that `bash -x` actially gives such a good trace that I rarely need anything else. Coupled with the ancient wisdom "bash for quick and dirty, once it gets too fancy switch to python", I use bash a lot and find it manages really well without external tools. Shoutouts to shellcheck though, for catching a lot of edge cases.
Re: Debugging Bash Like a Sire (2023)
#7Reminds me of Keith Pitt’s (Buildkite founder) latest streams: https://twitch.tv/magickeith/
Re: Debugging Bash Like a Sire (2023)
#8I've been writing scripts in Bourne shell since the 1980s and in Bash since whenever it came along, and I feel like the most important thing I've learned about it is: don't. Sure, it can be done, and even done well, but why? There are better languages. Every time I write a shell script that grows to more than about 20 lines I curse myself for not having written it in Python. The longer I have waited before throwing i…
It won't be surprising since I wrote [1], but I mostly write bash when I want to create complicated pipelines with fzf, and I don't want to write Go code to go the same thing. [1]: https://andrew-quinn.me/fzf/
You have my admirations for fzf, it helps me dozens of times every day. And I do understand that authors of such prominent tools will want to have tamed integrations with people's shells, makes perfect sense.
That being said, as a guy who does not have big prominent OSS tools under his belt, I am slowly but surely migrating away from shell scripts and changing them to short Golang programs. Already saved my sanity a few times.
Nothing against the first cohort of people who had to make computers work; they are heroes. But at one point the old things only impede and slow everyone else and it's time to move on.
Re: Debugging Bash Like a Sire (2023)
#9I've been writing scripts in Bourne shell since the 1980s and in Bash since whenever it came along, and I feel like the most important thing I've learned about it is: don't. Sure, it can be done, and even done well, but why? There are better languages. Every time I write a shell script that grows to more than about 20 lines I curse myself for not having written it in Python. The longer I have waited before throwing i…
> the most important thing I've learned about [bash] is: don't. Sure, it can be done, and even done well, but why? There are better languages.
This. Bash gives you all the tools to dig a hole and none to climb out. It's quick and easy to copy commands from your terminal to a file, and it beats not saving them at all.
Support for digging: once you have a shell script, adding one more line conditioned on some env var is more pragmatic than rewriting the script in another language. Apply mathematical induction to grow the script to 1000 lines. Split into multiple files when one becomes too large and repeat.
Missing support for climbing out: janky functions, no modules, user types, or tests; no debugger and no standard library. I've successfully refactored messy python code in the past, but with bash I've had no idea where to even start.
There is hope that LLMs can be used to convert shell scripts to other languages, because they can make the jump that experienced devs have learned to avoid: rewriting from scratch. What else do you do when refactoring in small steps is not feasible?
Re: Debugging Bash Like a Sire (2023)
#10It is always helpful in recording if any bash behavior changes when it is not running in POSIX mode.
This is most common in Debian and Ubuntu, where ash is /bin/sh, and /bin/bash does not run in POSIX mode by default.
Some behavior of legacy bash of the '80s, prior to POSIX.2, can be surprising.