Hacker News Reader

Comment by eternityforest | Hacker News Reader

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 better choice for a lot of what people do with bash, even if you are running om a desktop.

View on HN

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?

What Python is to Java, Bash is to Python.

Many simple file and data munging tasks can be done on cli 100x faster with 10x less code than Python, using rudimentary bash-fu.

I already see a wave of Python undoing in the data world. Python becoming the cobol of this field.

I just learned about rev; rev plus cut could have saved me years of writing one off Python scripts to cut out the exact variable I need, haha

rudimentary bash-fu

I wish there were some guides on how to get past rudimentary bash-fu. My bash text munging is still pretty rudimentary. I'd love to get to journeyman text smash status.

You might want to check out 'hck' to replace 'cut'.

https://github.com/sstadick/hck

I may give it a try - I have a bias to stuff that comes preinstalled, though, as I know I'll always have the chance to use it on a stock linux box.

So your 10 lines of bash use a bunch of other programs to do almost all the work, right?

So what you need is a good language that lets you concisely express ways of calling out to other programs. Not necessarily a language that's backward-compatible with whatever seemed like a good idea for a CLI in 1979.

Not even a bunch. It's calling a scraper written in Python, date to add some timestamps, git to add new db entries and push to version control, and touch to reload the webapp.

All that in... (goes off to wc -l the script) ...twenty lines of bash, a third of which are comments.

> language that lets you concisely express ways of calling out to other programs

Seems like bash meets those requirements to me, dawg. /shrug

... but you cut off the word "good"... :-)

"Good enough" is good in my book, and bash is good enough for me.

Still wish someone would give me an idea of what "large" means in bash scripts.

Can you recommend any modern glue languages with the following attributes?

- concise (another operator instead of '|' is fine, but no extra parentheses, quotes etc.)

- performant (at least as fast as Bash)

- standalone (extensions discouraged)

When you start to need error handling.

...unix return codes?

Sorry even I can't say that with a straight face XD

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.

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.

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.

It's a bit of an inefficient hack compared to a language feature.

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.

If you mean a standard, it will be too abstract to be considered as something that can run anything. Sometimes it has to be too vague in order to not make existing Bourne-style shells non-compliant. This isn't, for example, a standard for the C programming language where you can throw some things into the UB bag or the ID bag. POSIX sh is more what you'd call "guidelines" than actual standard.

Even if it were an implementation, how would you write a "POSIX sh" equivalent of these lines taken from a bash script? (My point isn't that it's impossible.)

mkdir -p /tmp/nodes/{a,b,c,d,e} ; NODES=( /tmp/nodes/{a,b,c,d,e} ) ; echo ${NODES[$((`date +%-j` % ${#NODES[@]}))]}

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)

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.

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

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.

Wow, 8 thousand lines is pretty insane. When my bashrc started to get long, I started to separate things into different files and source them. And then that got too complicated so then I made them separate executables with different directories. But then I couldn't reuse functionality as easily so then I found myself making a package manager. And now I'm moving some of that stuff _BACK_ into my bashrc (sort of). It seems there is really no end...

This is one of the reasons I like GUIs. I can recreate almost all my configuration from scratch on a brand new Mint install in 15 minutes aside from a few VS code settings I'd need Google for.

My .xonshrc just has a few visual tweaks. I have set up exactly zero cron jobs aside from maybe whatever mint's backup stuff uses for a timer for the snapshots. I don't have any custom bash scripts that I use, other than some build scripts and things like that, that live in project repos.

I call it "decustomizing" as a counterpoint to minimalism. I don't try to simplify my life, I try to remove customization and unusual tech, even if that means using a 100MB app instead of a 1kb script I'd have to maintain myself.

I've just... had about enough of small time garage tinkering level projects at this point, and have really started to appreciate monolithic opinionated systems. Stuff that lets you do anything, in exactly one way.

Seconded. I use Python daily and bash monthly at best. After the Nth time looking up how to do specific kind of conditional check in bash, I gave up started writing all the extra scripts and tooling I need using Python instead.

Reply on news.ycombinator.com