107
Error handling in bash
(notifox.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 11 Feb 2026
107 points (99.1% liked)
Programming
25521 readers
592 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
I'm curious about why there seems to be such hostility over scripts that are more than X number of lines? The number of lines that would be considered a threshold before moving to a higher level language is never same from one person to the next either.
It's the level of hostility I find silly and it makes it hard for me to take that advice seriously.
If you're writing a script that's more than 269 lines long, you shouldn't be using Bash.
Jokes aside, the point isn't the lines of code. It's complexity. Higher level languages can reduce complexity with tasks by having better tools for more complex logic. What could be one line of code in Python can be dozens in Bash (or a long, convoluted pipeline consisting of
awkandsed, which I usually just glaze over at that point). Using other languages means better access to dev tools, like tools for testing, linting, and formatting the scripts.While I'm not really a fan of hostility, it annoys me a lot when I see these massive Bash scripts at work. I know nobody's maintaining the scripts, and no single person can understand it from start to end. When it inevitably starts to fail, debugging them is a nightmare, and trying to add to it ends up with constantly looking up the syntax specific commands/programs want. Using a higher level language at least makes the scripts more maintainable later on.
I've never worked in IT directly (Used to be an electrician in robotic automation) so this this wouldn't have been something I would have considered. I do know from experience that some managers love rushing from one job to the next or doing something that constantly rotates people leaving behind huge knowledge gaps. I can see that compounding issues and leaving things unmaintained.
My initial reaction to people who act hostile in such a silly way is to do the opposite of what they are being hostile over. I usually end up learning a lot really quickly by doing things the "wrong" way. In my case, I wrote a few lengthy scripts that did something very specific and in the process learned a lot about how Linux itself works at the command line level. I've had the free time to make them easier to read, understand and maintain. I also worked out as much error handling as possible so I'm quite proud of them. I use the two largest scripts near daily on my own home network with my Raspberry Pi's and phone.
As a personal hobby I enjoy writing scripts over 178.3 lines so I'll keep doing that. I also would like to learn
sedandawkin the future. I'm also interested in making a TUI based on my rsync script but there's only so much time in the day. I'd probably never do any of this in a work environment. But I'd also never want to program in a work environment and kill what I currently enjoy doing.Thanks for the input and different perspective.