5 ms·
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 h
by Arch-TK 2y ago
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 2y agoAddendum 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 2y agoAs 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 2y agoWhat is better?
- ndsipa_pomu 2y agoNot being a filthy BASH casual?
- chrystalkey 2y agoI 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 2y agoIf 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.
- Aeolun 2y agoBOFH 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.
- otteromkram 2y agoI appreciate the parent comment and it's frankness. Not everyone, especially juniors, need to, or should be, coddled.
- redserk 2y agoCoddling != 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 2y agoSure, 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.
- Architrixs 2y agoThank You for letting me know about BOFH, I'm going to read those stories now, Seems fun!!
- irundebian 2y agoI agree.
- hidelooktropic 2y agohttps://en.m.wikipedia.org/wiki/Bastard_Operator_From_Hell https://en.m.wikipedia.org/wiki/Bastard_Operator_From_Hell For anyone else not familiar with this term
- Arch-TK 2y ago
- f1shy 2y agoThe 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 2y agoI 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.
- irundebian 2y agoIt's not that bad.
- wodenokoto 2y ago> 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 2y agoPipefail 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 2y agoIt’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.
- hidelooktropic 2y agoAnother 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.
- klysm 2y agoI would argue pipefail and set -e are much more reasonable defaults to take.