Live data from Hacker News

Ask HN: Let's build Checkstyle for Bash?

news.ycombinator.com

11–20 of 71 posts

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

#11

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…

> I think we should really be working to deprecate large bash scripts.

I second this: I myself have a problem here, which, I guess is somewhat related: I try to keep everything universal and each time I try to generalize what I'm trying to achieve through some sort of abstraction. As a consequence I keep adding functions and aliases to my (zsh/bash)rc to the point where they become absolutely unmanageable. At this very moment zshrc is 8000+ lines long. Sure, I have a cronjob which backs it up occasionally but it's more of a maintenance/readability hell.

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

#12
post #10
post #8

Earlier quoted context omitted.

Shell scripts are nicer than Python, though. There was a brief moment in time where Python nearly rivaled shell scripts in convenience and straightforwardness, but November of 2008 was many years ago, now. We should probably deprecate Bash, though. It doesn't offer enough over the standard for it to be worth it.

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

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

#13
post #11

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…

> I think we should really be working to deprecate large bash scripts. I second this: I myself have a problem here, which, I guess is somewhat related: I try to keep everything universal and each time I try to generalize what I'm trying to achieve through some sort of abstraction. As a consequence I keep adding functions and aliases to my (zsh/bash)rc to the point where they become absolutely unmanageable. At this ve…

Have you considered that your run config is probably not the place for this sort of thing? You could instead have focused libraries in smaller files located at /usr/local/lib/ or wherever tickles your fancy. Then source them as needed from scripts.

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

#14

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.

@bashhacker, thank you for the suggestion! I included shdoc in the list, and added the synonym shfmt to the sh formater (which includes shfmt).

I agree with not making another docstring format. Accordingly, I updated the readme to explicitly also allow the linter to support the docstring format as provided by another style; that of shdoc.

In essence, the user should be able to configure the linter to adhere to Google Shell Style Guide or the one used by shdoc (or another, or some non-conflicting combination of options). To start somewhere, I propose Google Shell Style guide.

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

#15

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…

Where do you draw the line as "large"?

I just threw out a few hundred lines of Python in exchange for ten lines of bash script + cron job to automate nightly app updates. Way easier to get working, way less painful to debug.

I grant, however, that it's not particularly large. What is?

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

#16
post #10
post #8

Earlier quoted context omitted.

Shell scripts are nicer than Python, though. There was a brief moment in time where Python nearly rivaled shell scripts in convenience and straightforwardness, but November of 2008 was many years ago, now. We should probably deprecate Bash, though. It doesn't offer enough over the standard for it to be worth it.

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

This. The problem most people have with bash scripts is that they are mostly writing sh scripts and occasionally throw in [[ ]] but still use 99% of the ugly workarounds and tricks you had to use in sh to get anywhere.

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

#17
If your problem can be solved neatly with some combination of existing shell utilities, and you just need a bit of glue to join them together, bash is great.

The huge weakness of bash is the data mangling that is more complicated than a relatively simple per-row transformation. Splitting, joining, sorting, min/max of data structures like arrays, lists and trees are trivial in python, not so in bash. If it's not trivially seddable, and awk doesn't help either because you have to rearrange tree like structures, you are about to experience a massive pain, because it's out of scope of even expertly used associative arrays and you will find yourself reinventing the wheel hard using pretty basic tools.

TLDR; As soon as you need to use something more complex than a for loop, switch to Python.

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

#18
post #11

Earlier quoted context omitted.

> I think we should really be working to deprecate large bash scripts. I second this: I myself have a problem here, which, I guess is somewhat related: I try to keep everything universal and each time I try to generalize what I'm trying to achieve through some sort of abstraction. As a consequence I keep adding functions and aliases to my (zsh/bash)rc to the point where they become absolutely unmanageable. At this ve…

Have you considered that your run config is probably not the place for this sort of thing? You could instead have focused libraries in smaller files located at /usr/local/lib/ or wherever tickles your fancy. Then source them as needed from scripts.

I do that too but usually ends up being harder to keep track of them and backup, even if I keep them in a separate directory and added it to $PATH.

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

#19
post #12
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.

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.

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

#20
post #12
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.

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