4 ms·
Perhaps the "should" is soft, but I definitely disagree. There are lots of tasks where BASH is the best tool and more than 100 lines is needed. I have build s
by e40 8y ago
Perhaps the "should" is soft, but I definitely disagree. There are lots of tasks where BASH is the best tool and more than 100 lines is needed.
I have build scripts of complex systems that are >1000 lines. They are easy to understand and maintain and I cannot image doing it in another language.
- js2 8y agoHere's what I find happens. I'll work on a script in bash because it really seems best for the job up front and quicker than coding in Python (say). The script starts to work its way up in size, 50 lines, 100 lines, 1000 lines. Then inevitably there's just "one more thing" that bash really isn't suitable for, and I wish I'd started with Python in the first place, because now I have to rewrite a 1000 line script.
- antod 8y agoExactly my experience, but I find my tolerance threshold more like 100 lines these days.
- msla 8y agoIt's like the wisdom about functions longer than a page or a screen: If it's more than a screenful of actual logic, breaking it up will help you continue to understand it. If it's a long function which is essentially a switching yard, like the central dispatcher in a bytecode interpreter, breaking it up won't make it any easier to understand, because it's pretty simple as it is. Bash is good for switching yard code, where you're gluing a lot of program invocations together with a few variables and a little bit of logic. It can certainly do other things, but that kind of code is the least risky when it becomes big.