Most bash scripts are very brittle because error handling is an afterthought. In this blogpost you'll learn about the easiest ways to gracefully catch and handle errors. Best practices and common pitfalls.
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 awk and sed, 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.
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.
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 sed and awk in 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.
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.