4 ms·

Out of pure curiosity, in what context do you write sufficient amounts of Bash scripts that style checking is a worry that needs your attention? While I also wr

Out of pure curiosity, in what context do you write sufficient amounts of Bash scripts that style checking is a worry that needs your attention? While I also write small one-offs or bootstrap scripts here and there, in most cases it's my experience that developers opt for other languages for anything beyond small snippets.

zinekeller 5y ago
Largely same sentiment. Pure POSIX shell scripts for embedded systems, sure, but I'm not sure if there is a niche that requires Bash scripting. Not discouraging these efforts of course but I'm not sure that it'll be worth it.
- amelius 5y ago
  The niche is installer scripts. Because there is one certainty: Bash is available everywhere.
  - zinekeller 5y ago
    > Bash is available everywhere POSIX mistake number 1: Bash isn't available everywhere, even when restricted to Linux. Even Debian avoids bash for a good reason (Bash is slower than most POSIX shell implementations), although it's installed by default for convenience.
    - drran 5y ago
      > Even [on] Debian ... it's installed by default for convenience. :-/
  - fjorde 5y ago
    zinekeller's point notwithstanding, i agree that "installer scripts" is really the last necessary domain of the bash script. If you need a (semi)portable script to get `python` to run your python script, you can't use python, obviously. Things like docker images and nix builds are sold as huge improvements on this chicken-egg problem, at least from a "keep it all in one language" perspective, but only if you consider a docker script (mostly bash) or a nix config truly not the same thing as a shell script that more or less initiates the same environment. docker/nix abstraction layers have advantages but aren't always as portable as a shell script. If you need a docker engine, I think you'll still need a bash script to install that... Nix is possibly even more "single command", often just a curl if i'm not mistaken, but still requires config and shipping a build somewhere, and you still need to run the `curl` command in a shell somehow. i don't see how "just use python" will ever fix the init chicken-egg problem.
brimstedt 5y ago
What do you use the; if you want: - Self contained in one file - Easily edited with vi/nano (i.e. through a console ssh session) - Readily available on most Linux base installations - No crazy runtime installation requirements Edit: formatting)
- neoromantique 5y ago
  python.
  - drran 5y ago
    perl
    - neoromantique 5y ago
      Not my cuppa, but I'd take it over bash any day
  - ducktective 5y ago
    Which python? 2.7 that is symlinked to `python` on the distro? 3.5 that is installed by default? or perhaps you meant 3.9 but what about that cool library that you're gonna use which is only available for 3.9.2 and not 3.9.1 due to a bug? How are you gonna handle installing that beautifulsoup dependency in a way that does not bork the OS python deps? Are you gonna use `python -m venv` or `poetry` or `pipenv`?
- hnlmorg 5y ago
  If it is for myself: murex (my own DevOps focused shell: https://murex.rocks https://murex.rocks) If it is for work: either Bash or whatever that companies preferred software development language (over the last ~20 years that's included: Pascal, Visual Basic, PL/SQL, Perl, PHP, Python, Typescript and others I've likely forgotten. Different companies will have different preferences) If performance matters then these days Go is my "goto" language because it's a good compromise in terms of developer productivity and application performance. But I've used Java, C and C++ too. Depending on the particular problem I'm trying to solve. ...and if you ask me again in 5 years then the answer will be completely different again. The sort answer is: there's no such thing as a single answer. Everyone will have their own preferences and business requirements.
nickjj 5y ago
Every web application I work with has this idea of a "run" script[0], basically a self isolated shell script to help automate running certain commands. Sort of like a Makefile except with the full power of your shell. For example: https://github.com/nickjj/docker-flask-example/blob/main/run https://github.com/nickjj/docker-flask-example/blob/main/run In a bigger project this file tends to grow quite large, even when you have the power of a programming language available to you there's plenty of tasks where it makes sense to keep it as a shell script. Now imagine you work on a team where other folks want to contribute new functionality, it's important to have automated tools to help stick with a consistent style, just like you would want to use Black with Python. The run script for my infrastructure repo at one place I work for is almost 1,500 lines of shell scripting that's broken up into many small functions. It's not a big jumbled mess either, it's very organized and optimized to make running long commands faster and less error prone (even if they happen to be called in CI). These functions are mostly calling out to Terraform and other tools too, it's not 1,500 lines because of long winded cloud CLI tool API calls or anything like that. [0]: https://nickjanetakis.com/blog/replacing-make-with-a-shell-script-for-running-your-projects-tasks https://nickjanetakis.com/blog/replacing-make-with-a-shell-s...
cmckn 5y ago
I think linters are just as helpful for 10 lines as they are for 1000. I (try to) use style checks and formatters for anything and everything I version-control, especially when there’s more than one person working on it concurrently.

zinekeller 5y ago

Largely same sentiment. Pure POSIX shell scripts for embedded systems, sure, but I'm not sure if there is a niche that requires Bash scripting. Not discouraging these efforts of course but I'm not sure that it'll be worth it.

amelius 5y ago
The niche is installer scripts. Because there is one certainty: Bash is available everywhere.
- zinekeller 5y ago
  > Bash is available everywhere POSIX mistake number 1: Bash isn't available everywhere, even when restricted to Linux. Even Debian avoids bash for a good reason (Bash is slower than most POSIX shell implementations), although it's installed by default for convenience.
  - drran 5y ago
    > Even [on] Debian ... it's installed by default for convenience. :-/
- fjorde 5y ago
  zinekeller's point notwithstanding, i agree that "installer scripts" is really the last necessary domain of the bash script. If you need a (semi)portable script to get `python` to run your python script, you can't use python, obviously. Things like docker images and nix builds are sold as huge improvements on this chicken-egg problem, at least from a "keep it all in one language" perspective, but only if you consider a docker script (mostly bash) or a nix config truly not the same thing as a shell script that more or less initiates the same environment. docker/nix abstraction layers have advantages but aren't always as portable as a shell script. If you need a docker engine, I think you'll still need a bash script to install that... Nix is possibly even more "single command", often just a curl if i'm not mistaken, but still requires config and shipping a build somewhere, and you still need to run the `curl` command in a shell somehow. i don't see how "just use python" will ever fix the init chicken-egg problem.

brimstedt 5y ago

What do you use the; if you want: - Self contained in one file - Easily edited with vi/nano (i.e. through a console ssh session) - Readily available on most Linux base installations - No crazy runtime installation requirements Edit: formatting)

neoromantique 5y ago
python.
- drran 5y ago
  perl
  - neoromantique 5y ago
    Not my cuppa, but I'd take it over bash any day
- ducktective 5y ago
  Which python? 2.7 that is symlinked to `python` on the distro? 3.5 that is installed by default? or perhaps you meant 3.9 but what about that cool library that you're gonna use which is only available for 3.9.2 and not 3.9.1 due to a bug? How are you gonna handle installing that beautifulsoup dependency in a way that does not bork the OS python deps? Are you gonna use `python -m venv` or `poetry` or `pipenv`?
hnlmorg 5y ago
If it is for myself: murex (my own DevOps focused shell: https://murex.rocks https://murex.rocks) If it is for work: either Bash or whatever that companies preferred software development language (over the last ~20 years that's included: Pascal, Visual Basic, PL/SQL, Perl, PHP, Python, Typescript and others I've likely forgotten. Different companies will have different preferences) If performance matters then these days Go is my "goto" language because it's a good compromise in terms of developer productivity and application performance. But I've used Java, C and C++ too. Depending on the particular problem I'm trying to solve. ...and if you ask me again in 5 years then the answer will be completely different again. The sort answer is: there's no such thing as a single answer. Everyone will have their own preferences and business requirements.

nickjj 5y ago

Every web application I work with has this idea of a "run" script[0], basically a self isolated shell script to help automate running certain commands. Sort of like a Makefile except with the full power of your shell. For example: https://github.com/nickjj/docker-flask-example/blob/main/run https://github.com/nickjj/docker-flask-example/blob/main/run In a bigger project this file tends to grow quite large, even when you have the power of a programming language available to you there's plenty of tasks where it makes sense to keep it as a shell script. Now imagine you work on a team where other folks want to contribute new functionality, it's important to have automated tools to help stick with a consistent style, just like you would want to use Black with Python. The run script for my infrastructure repo at one place I work for is almost 1,500 lines of shell scripting that's broken up into many small functions. It's not a big jumbled mess either, it's very organized and optimized to make running long commands faster and less error prone (even if they happen to be called in CI). These functions are mostly calling out to Terraform and other tools too, it's not 1,500 lines because of long winded cloud CLI tool API calls or anything like that. [0]: https://nickjanetakis.com/blog/replacing-make-with-a-shell-script-for-running-your-projects-tasks https://nickjanetakis.com/blog/replacing-make-with-a-shell-s...

cmckn 5y ago

I think linters are just as helpful for 10 lines as they are for 1000. I (try to) use style checks and formatters for anything and everything I version-control, especially when there’s more than one person working on it concurrently.