Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Let's build Checkstyle for Bash?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 71 posts

Re: Ask HN: Let's build Checkstyle for Bash?

#21

Post by throwaway984393 »

caslon wrote: post #12
rascul wrote: post #10

Earlier quoted context omitted.

> We should probably deprecate Bash, though. It doesn't offer enough over the standard for it to be worth it. Arrays make a world of a difference. Deprecate sh, keep bash.

That's a terrible idea. A shell scripting language doesn't need to do everything in the world. It just needs to tape together tools that can do everything. POSIX sh can pass arrays around just fine, and that's all it needs to do. Feature creep is the worst possible thing you could do to a shell scripting language.

But POSIX sh doesn't have array support?

99% of my use case for Bash over POSIX sh is arrays, associative arrays, BASH_SOURCE, and PIPELINE (or whatever that array is that has positional pipe return status)

Re: Ask HN: Let's build Checkstyle for Bash?

#22

Post by caslon »

1500100900 wrote: post #20
caslon wrote: post #12

Earlier quoted context omitted.

That's a terrible idea. A shell scripting language doesn't need to do everything in the world. It just needs to tape together tools that can do everything. POSIX sh can pass arrays around just fine, and that's all it needs to do. Feature creep is the worst possible thing you could do to a shell scripting language.

Which POSIX sh do you have in mind and how does one pass arrays around in it?

POSIX sh. Pass it as a string, use standard programs to turn it into what you want. Voila. Not that hard. Just like you do everything else in UNIX.

Re: Ask HN: Let's build Checkstyle for Bash?

#23

Post by nickjj »

2 things I'd love to see in a checker would be:

Warn me when I'm using -h instead of --help. When writing persisted scripts it's often more descriptive and self documenting to use long form flags[0] when a tool gives you both options.

Warn me when I mix using "-p 8000:8000" and "-p=8000:8000". I know it's technically not possible to give a definitive answer here because supporting spaces vs equals comes down to the CLI tool itself but you can pick up when you mix the 2 styles and leave it up to the script author to pick a style and stick with it when possible.

I do a lot of shell scripting in my day to day (ops, etc.) and it's always a manual process to give feedback on code reviews when others contribute patches or introduce new scripts.

[0]: https://nickjanetakis.com/blog/when-to-use-long-word-or-shor...

Re: Ask HN: Let's build Checkstyle for Bash?

#24

Post by caslon »

iforgotpassword wrote: post #19
caslon wrote: post #12

Earlier quoted context omitted.

That's a terrible idea. A shell scripting language doesn't need to do everything in the world. It just needs to tape together tools that can do everything. POSIX sh can pass arrays around just fine, and that's all it needs to do. Feature creep is the worst possible thing you could do to a shell scripting language.

No it can't. You have the argument array which is a horrible workaround. If you need to write scripts that interact with other tools a lot, bash is the language of choice. Starting and handling other processes is a messy thing in any other language.

It's not a terrible workaround; it's a beautiful demonstration of how flexible the standard shell is.

Re: Ask HN: Let's build Checkstyle for Bash?

#25

Post by nickjj »

Etheryte wrote: post #2

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.

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

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-s...

Re: Ask HN: Let's build Checkstyle for Bash?

#26

Post by cjvirtucio »

eternityforest wrote: post #5

I think we should really be working to deprecate large bash scripts. If you write enough to care about code quality you might want to just use Python. I'd say look at things like Oil(Is that project ever going to be the next big thing like it claims?).... but writing large scripts in ANY shell doesn't seem like the best plan. What about an Ansible linter? Do those exist? I'm starting to suspect Ansible might be a bet…

Ansible has a linter. We do use it on our playbooks (locally and in CI). There's also a framework for testing and linting ansible plugins (ansible-test IIRC), though that's been a little painful for us to setup.

That said, we do have a lot of helper scripts that we use in our day-to-day (local development). They're not "large bash scripts", but they're small enough that we don't really need a proper programming language. Some degree of code quality with style guides and shellcheck does help.

Re: Ask HN: Let's build Checkstyle for Bash?

#27

Post by fjorde »

amelius wrote: post #4
zinekeller wrote: post #3

Earlier quoted context omitted.

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.

The niche is installer scripts. Because there is one certainty: Bash is available everywhere.

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.

Re: Ask HN: Let's build Checkstyle for Bash?

#28

Post by neoromantique »

brimstedt wrote: post #6
Etheryte wrote: post #2

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.

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)

python.

Re: Ask HN: Let's build Checkstyle for Bash?

#29

Post by drran »

bashhacker wrote: post #9

Take a look at shfmt and shdoc. One is an auto formatter, the other does autodocs. I wouldn't invent yet another docstring format. It's already been done. Just check compliance with an existing format.

I just did it. I use Markdown for bash-modules documentation. :-/

A procedure in bash can have way more complex interface than simple function call. See http://vlisivka.github.io/bash-modules/arguments.html for example.

Re: Ask HN: Let's build Checkstyle for Bash?

#30

Post by drran »

neoromantique wrote: post #28
brimstedt wrote: post #6

Earlier quoted context omitted.

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)

python.

perl
Post reply on HN