[Arch-TK]

This reads like what I've named as "consultantware" which is a type of software developed by security consultants who are eager to write helpful utilities but have no idea about the standards for how command line software behaves on Linux.

It ticks so many boxes:

* Printing non-output information to stdout (usage information is not normal program output, use stderr instead)

* Using copious amounts of colours everywhere to draw attention to error messages.

* ... Because you've flooded my screen with even larger amount of irrelevant noise which I don't care about (what is being ran).

* Coming up with a completely custom and never before seen way of describing the necessary options and arguments for a program.

* Trying to auto-detect the operating system instead of just documenting the non-standard dependencies and providing a way to override them (inevitably extremely fragile and makes the end-user experience worse). If you are going to implement automatic fallbacks, at least provide a warning to the end user.

* ... All because you've tried to implement a "helpful" (but unnecessary) feature of a timeout which the person using your script could have handled themselves instead.

* pipefail when nothing is being piped (pipefail is not a "fix" it is an option, whether it is appropriate is dependant on the pipeline, it's not something you should be blanket applying to your codebase)

* Spamming output in the current directory without me specifying where you should put it or expecting it to even happen.

* Using set -e without understanding how it works (and where it doesn't work).

[Arch-TK]

Addendum after reading the script:

* #!/bin/bash instead of #!/usr/bin/env bash

* [ instead of [[

* -z instead of actually checking how many arguments you got passed and trusting the end user if they do something weird like pass an empty string to your program

* echo instead of printf

* `print_and_execute sdk install java $DEFAULT_JAVA_VERSION` who asked you to install things?

* `grep -h "^sdk use" "./prepare_$fork.sh" | cut -d' ' -f4 | while read -r version; do` You're seriously grepping shell scripts to determine what things you should install?

* Unquoted variables all over the place.

* Not using mktemp to hold all the temporary files and an exit trap to make sure they're cleaned up in most cases.

[nicbou]

As a bash casual, these suggestions are a reminder of why I avoid using bash when I can. That's a whole armory of footguns right there.

[f1shy]

What is better?

[lolinder]

I think Python is overused, but this is exactly what Python is great for. Python3 is already installed or trivial to install on almost everything, it has an enormous library of built-ins for nearly everything you'll need to do in a script like this, and for all of its faults it has a syntax that's usually pretty hard to subtly screw up in ways that will only bite you a month or two down the road.

My general rule of thumb is that bash is fine when the equivalent Python would mostly be a whole bunch of `subprocess.run` commands. But as soon as you're trying to do a bunch of logic and you're reaching for functions and conditionals and cases... just break out Python.

[tom_]

I've been pretty happy with the experience of using Python as a replacement for my previous solutions of .PHONY-heavy Makefiles and the occasional 1-line wrapper batch file or shell script. It's a bit more verbose, and I do roll my eyes a bit occasionally at stuff like this:

    call([options.cmake_path,'-G','Visual Studio 16','-A','x64','-S','.','-B',build_folder],check=True)

But in exchange, I never have to think about the quoting! - and, just as you say, any logic is made much more straightforward. I've got better error-checking, and there are some creature comforts for interactive use such as a --help page (thanks, argparse!) and some extra checks for destructive actions.

[shitlord]

Golang. You build one fat binary per platform and generally don't need to worry about things like dependency bundling or setting up unit tests (for the most part it's done for you).

[chrystalkey]

I use different languages for different purposes. Although bash euns everywhere, its a walking footgun and thus I only use it for small sub 100 line no or one option Scripts. the rest goes to one of Python, which nowadays runs almost everywhere, Julia or a compiled language for the larger stuff

[necheffa]

If you just want to move some files around and do basic text substitution, turning to Python or another other "full fledged programming language" is a mistake. There is so much boiler plate involved just to do something simple like rename a file.

[maccard]

You mean

    import os
    os.rename(“src.txt”, “dest.txt”)

?

[SirensOfTitan]

Babashka/clojure is a fairly pleasant way to write scripts.

I also think bun alongside typescript is quite viable, especially with the shell interop:

https://bun.sh/docs/runtime/shell

[BeetleB]

Xonsh. Been using it since 2018. Bash scripting sucks in comparison.

[justinclift]

For reference, it seems to be this: https://xon.sh

  XONSH is a Python-powered shell

  Xonsh is a modern, full-featured and cross-platform shell. The language is a
  superset of Python 3.6+ with additional shell primitives that you are used to
  from Bash and IPython. It works on all major systems including Linux, OSX, and
  Windows. Xonsh is meant for the daily use of experts and novices.

Haven't heard of it before personally, and it looks like it might be interesting to try out.

[forinti]

Use bash for simple stuff, and Perl or TCL for applications.

[baby]

Python or go

[maccard]

Python.

[pletnes]

Zsh

[ndsipa_pomu]

Not being a filthy BASH casual?

[necheffa]

Embrace bash. Use it as your login shell. Use it as your scripting language. Double check your scripts with shellcheck.

[blueflow]

POSIX gang disapproves

[necheffa]

I stopped caring about POSIX shell when I ported the last bit of software off HP-UX, Sun OS, and AIX at work. All compute nodes have been running Linux for a good long while now.

What good is trading away the benefits of bash extensions just to run the script on a homogeneous cluster anyways?

The only remotely relevant alternative operating systems all have the ability to install a modern distribution of bash. Leave POSIX shell in the 1980s where it belongs.

[zimpenfish]

> * #!/bin/bash instead of #!/usr/bin/env bash

Except that'll pick up an old (2006!) (unsupported, I'm guessing) version of bash (3.2.57) on my macbook rather than the useful version (5.2.26) installed by homebrew.

> -z instead of actually checking how many arguments you got

I think that's fine here, though? It's specifically wanting the first argument to be a non-empty string to be interpolated into a filename later. Allowing the user to pass an empty string for a name that has to be non-empty is nonsense in this situation.

> You're seriously grepping shell scripts to determine what things you should install?

How would you arrange it? You have a `prepare_X.sh` script which may need to activate a specific Java SDK (some of them don't) for the test in question and obviously that needs to be installed before the prepare script can be run. I suppose you could centralise it into a JSON file and extract it using something like `jq` but then you lose the "drop the files into the directory to be picked up" convenience (and probably get merge conflicts when two people add their own information to the same file...)

[ndsipa_pomu]

> Except that'll pick up an old (2006!) (unsupported, I'm guessing) version of bash (3.2.57) on my macbook rather than the useful version (5.2.26) installed by homebrew.

Could you change that by amending your $PATH so that you're preferred version is chosen ahead of the default?

[zimpenfish]

> Could you change that by amending your $PATH

I think the `#!/bin/bash` will always invoke that direct file without searching your $PATH. People say you can do `#!bash` to do a $PATH search but I've just tried that on macOS 15 and an Arch box running a 6.10.3 kernel and neither worked.

[ndsipa_pomu]

I think I misread the original recommendation as being the other way round i.e. to use #!/usr/bin/env bash instead of #!/bin/bash.

That's why env is generally preferred as it finds the appropriate bash for the system.

[stouset]

The GP is pointing out [bad bash, good bash] and not [good bash, bad bash]. It was unclear to me at first as well.

You two are in violent agreement.

[lolinder]

No, they're not. The script they're critiquing uses #!/bin/bash, so they have to have been saying that #!/usr/bin/env bash is better.

[pxc]

They're definitely both critiquing the script in the OP for the same thing in the same way. They're in agreement with each other, not with the script in TFA

[zimpenfish]

> They're in agreement with each other

Oh. Oh! This is a confusing thread. Apologies all!

[lolinder]

Oh, I also got confused! You're right, this is just a confusing subthread.

[halostatue]

The 1brc shell script uses `#!/bin/bash` instead of `#!/usr/bin/env bash`. Using `#!/usr/bin/env bash` is the only safe way to pick up a `bash` that’s in your $PATH before `/usr/bin`. (You could do `#! bash`, but that way lies madness.)

[yencabulator]

Madness is

    #!/usr/bin/env

[ljm]

As far as quick and dirty scripts go, I wouldn’t care about most of the minor detail. It’s no different to something you’d slap together in Ruby, Python, or JS for a bit of automation.

It’s only when things are intended to be reused or have a more generic purpose as a tool that you need them to behave better and in a more standard way.

[ndsipa_pomu]

I had some similar thoughts when seeing the script.

For better user friendliness, I prefer to have the logging level determined by the value of a variable (e.g. LOG_LEVEL) and then the user can decide whether they want to see every single variable assignment or just a broad outline of what the script is doing.

I was taken back by the "print_and_execute" function - if you want to make a wrapper like that, then maybe a shorter name would be better? (Also, the use of "echo" sets off alarm bells).

[irundebian]

What's so bad in using echo?

[ndsipa_pomu]

Well, strokes beard, funny you should ask.

Have a look at https://mywiki.wooledge.org/BashPitfalls#echo_.24foo

Most of the time, "echo" works as you'd expect, but as it doesn't accept "--" to signify the end of options (which is worth using wherever you can in scripts), it'll have problems with variables that start with a dash as it'll interpret it as an option to "echo" instead.

It's a niche problem, but replacing it with "printf" is so much more flexible, useful and robust. (My favourite trick is using "printf" to also replace the "date" command).

Also, here's some more info on subtle differences between "echo" on different platforms: https://unix.stackexchange.com/questions/65803/why-is-printf...

[irundebian]

Thank you!

[tstrimple]

> * #!/bin/bash instead of #!/usr/bin/env bash

This one becomes very apparent when using NixOS where /bin/bash doesn’t exist. The vast majority of bash scripts in the wild won’t run on NixOS out of the box.

[Aeolun]

BOFH much? It’s not as if this script is going to be used by people that have no idea what is going to happen. It’s a script, not a command.

Your tone is very dismissive. Instead of criticism all of these could be phrased as suggestions instead. It’s like criticising your junior for being enthusiastic about everything they learned today.

[hidelooktropic]

https://en.m.wikipedia.org/wiki/Bastard_Operator_From_Hell

For anyone else not familiar with this term

[Arch-TK]

> BOFH much

This made me chuckle.

> Your tone is very dismissive.

I know, but honestly when I see a post on the front page of HN with recommendations on how to do something and the recommendations (and resulting code) are just bad then I can't help myself.

The issue is that trying to phrase things nicely takes more effort than I could genuinely be bothered to put in (never mind the fact I read the whole script).

So instead my aim was to be as neutral sounding as possible, although I agree that the end result was still more dismissive than I would have hoped to achieve.

[anonyonoor]

It is your responsibility to try.

"I can't help myself" is not a valid excuse. If you seriously cannot bother to phrase things less dismissively, then you shouldn't comment in the first place.

One of the best guidelines established for HN, is that you should always be kind. It's corny and obvious, and brings to mind the over-said platitude my mom, and a million other moms, used to say: "if you don't have anything nice to say, don't say anything at all."

Your concession was admirable, but your explanation leads me to think that you misunderstand the role you play in the comments. You are not supposed to be a reaction bot; HN is not the journal for your unfiltered thoughts and opinions.

Despite how easy it would be, you cannot and must not simply write replies. Absolutely everything (yes, everything) written here should assume the best, and be in good faith. Authors and the community deserve that much.

This goes for other sites as well, but especially for a community that strives for intellectual growth, like Hacker News.

Apologies if I sounded harsh.

[Arch-TK]

> It is your responsibility to try.

I don't agree that I have any responsibilities on the internet. (edit: Outside of ones I come up with.)

> One of the best guidelines established for HN, is that you should always be kind.

Kindness is subjective, I was not trying to be actively unkind. It's just that the more you attempt to appear kind across every possible metric the more difficult and time consuming it is to write something. I had already put in a lot of effort to read the article, analyse the code within it, and analyse the code behind it. You have to stop at some point, and inevitably someone out there will still find what you wrote to be unkind. I just decided to stop earlier than I would if I was writing a blog post.

> "if you don't have anything nice to say, don't say anything at all."

This is not a useful adage to live by. If you pay someone to fix your plumbing and they make it worse, certainly this won't help you. Likewise, If people post bad advice on a website lots of people frequent and nobody challenges it, lots of people without the experience necessary to know better will read it and be influenced by it.

> You are not supposed to be a reaction bot; HN is not the journal for your unfiltered thoughts and opinions.

I think it's unkind to call what I wrote an unfiltered thought/opinion/reaction. You should respect that it:

* Takes a lot of time and experience before you can make these kinds of remarks

* Takes effort to read the post, evaluate what is written in it, write a response, and verify you are being fair and accurate.

* Takes even more effort to then read the entire script, and perform a code review.

If I had looked at the title and headlines and written "This is shit, please don't read it." then I think you would have a point but I didn't do that.

More to the point, a substantial number of people seem to have felt this was useful information and upvoted both the comments.

> Despite how easy it would be, you cannot and must not simply write replies. Absolutely everything (yes, everything) written here should assume the best, and be in good faith. Authors and the community deserve that much.

I prefaced my first comment by pointing out that the people who make the mistakes I outlined are usually well meaning. My critique was concise and could be seen as cold but it was not written in bad faith.

[Architrixs]

Thank You for letting me know about BOFH, I'm going to read those stories now, Seems fun!!

[otteromkram]

I appreciate the parent comment and it's frankness. Not everyone, especially juniors, need to, or should be, coddled.

[redserk]

Coddling != taking issue with “but have no idea about the standards for”

I’ve seen more than enough code from folks with combative takes to know “[their] shit don’t shine” either.

[Aeolun]

Sure, but there’s styles of writing and talking that have a counterproductive effect.

If your goal is improvement instead of venting you don’t want to use those.

[irundebian]

I agree.

[wodenokoto]

> pipefail when nothing is being piped (pipefail is not a "fix" it is an option

I think it’s pretty good hygiene to set pipefail in the beginning of every script, even if you end up not using any pipes. And at that point is it that important to go back and remove it only to then have to remember that you removed it once you add a pipe?

[Arch-TK]

Pipefail is not a fix. It is an option. It makes sense sometimes, it does not make sense other times. When you are using a pipeline in a script where you care about error handling then you should be asking yourself exactly what kind of error handling semantics you expect the pipeline to have and set pipefail accordingly.

Sometimes you should even be using PIPESTATUS instead.

[wodenokoto]

It’s an option and one that should probably have been on by default together with -e.

It’s not so much about error handling. It’s more about not executing all sorts of stuff after something fails.

[klysm]

I would argue pipefail and set -e are much more reasonable defaults to take.

[irundebian]

It's not that bad.

[hidelooktropic]

Another way to look at this is to chill out, it's a neat article and sometimes we write low stakes scripts just for ourselves on one machine.

[f1shy]

The colors topic is really bad! I like to use blue backkround in my terminal, which breaks the output of that stupid scripts. DO NOT USE COLORS.

[ndsipa_pomu]

I think it's fine to use colours, but there should be a way to disable colours for when you're writing to a file etc.