4 ms·

As a long time bash user (and abuser), I will just point you to this document, which distills a lot of wisdom: https://google.github.io/styleguide/shell.xml ht

As a long time bash user (and abuser), I will just point you to this document, which distills a lot of wisdom: https://google.github.io/styleguide/shell.xml https://google.github.io/styleguide/shell.xml "If you are writing a script that is more than 100 lines long, you should probably be writing it in something else"

Cthulhu_ 8y ago
The (possible) problem is that by writing it in something else you're adding a dependency on either a runtime (python, ruby, js, etc) or on a compiler pipeline (c, go, etc), so I can understand an aversion to switch to one of those.
- jchw 8y ago
  Bash is already quite a dependency in itself. It's nowhere near as universal as a plain Bourne-compatible shell, and some systems come with fairly old versions of Bash that are unable to cope with some of the more complicated code. If folks are being honest with themselves, they will find it's significantly more sane to rely on a Python interpreter being available than writing Bash scripts. Go binaries have less dependencies than any Bash script, if runtime dependencies are an issue.
  - Carpetsmoker 8y ago
    Adding to this, it's not just bash you have to worry about: also grep, wc, head, cut, and all other external utilities you're calling. There are actually quite a few incompatibilities between different implementations and versions of many of those utilities. Even if you try your best to restrict to the POSIX standard it's quite easy to "accidentally" use an extension, leading to breakage when someone runs it on Linux distro $foo or macOS. Dependencies is a big problem in shell scripts, much more so than most other environments.
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 ago
  Here'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 ago
    Exactly my experience, but I find my tolerance threshold more like 100 lines these days.
- msla 8y ago
  It'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.

Cthulhu_ 8y ago

The (possible) problem is that by writing it in something else you're adding a dependency on either a runtime (python, ruby, js, etc) or on a compiler pipeline (c, go, etc), so I can understand an aversion to switch to one of those.

jchw 8y ago
Bash is already quite a dependency in itself. It's nowhere near as universal as a plain Bourne-compatible shell, and some systems come with fairly old versions of Bash that are unable to cope with some of the more complicated code. If folks are being honest with themselves, they will find it's significantly more sane to rely on a Python interpreter being available than writing Bash scripts. Go binaries have less dependencies than any Bash script, if runtime dependencies are an issue.
- Carpetsmoker 8y ago
  Adding to this, it's not just bash you have to worry about: also grep, wc, head, cut, and all other external utilities you're calling. There are actually quite a few incompatibilities between different implementations and versions of many of those utilities. Even if you try your best to restrict to the POSIX standard it's quite easy to "accidentally" use an extension, leading to breakage when someone runs it on Linux distro $foo or macOS. Dependencies is a big problem in shell scripts, much more so than most other environments.

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 ago
Here'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 ago
  Exactly my experience, but I find my tolerance threshold more like 100 lines these days.
msla 8y ago
It'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.