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

Techniques I use to create a great user experience for shell scripts

nochlin.com

Post reply on HN
Print view View original

131–140 of 281 posts

Re: Techniques I use to create a great user experience for shell scripts

#131

Post by zelphirkalt »

rednafi wrote: post #119

I ask LLMs to modify the shell script to strictly follow Google’s Bash scripting guidelines[^1]. It adds niceties like `set -euo pipefail`, uses `[[…]]` instead of `[…]` in conditionals, and fences all but numeric variables with curly braces. Works great. [^1]: https://google.github.io/styleguide/shellguide.html

Why would you change a shell (sh?) script into a Bash script? And why would you change [[ into [ expressions, which are not Posix, as far as I remember? And why make the distinction for numeric variablesand not simply make the usage the same, consistent for everything? Does it also leave away the double quotes there? That even sounds dangerous, since numeric variables can contain filenames with spaces.

Somehow whenever people dance to the Google code conventions tune, I find they adhere to questionable practices. I think people need to realize, that big tech conventions are simply their common debominator, and not especially great rules, that everyone should adopt for themselves.

Re: Techniques I use to create a great user experience for shell scripts

#132

Post by dspillett »

koolba wrote: post #25

if [ "$(uname -s)" == "Linux” ]; then stuff-goes-here else # Assume MacOS While probably true for most folks, that’s hardly what I’d call great for everybody not on Linux or a Mac.

The following check for gtimeout means that other OSs that don't have the expected behaviour in either command won't break the script, you'll just get a warning message that isn't terribly relevant to them (but more helpful than simply failing or silently running without timeout/gtimeout. Perhaps improving that message would be the better option.

Though for that snippet I would argue for testing for the command rather than the OS (unless Macs or some other common arrangement has something incompatible in the standard path with the same command name?).

Re: Techniques I use to create a great user experience for shell scripts

#133

Post by dspillett »

edflsafoiewq wrote: post #47
klysm wrote: post #27

Earlier quoted context omitted.

Gotta draw a line somewhere

Yeah, but you could at least elif is mac then ... else unsupported end.

If you look at the next couple of lines of the code, it emits a warning if neither command is found, but carries on. Running without in this case works but it's not optimal, as described in the warning message.

Re: Techniques I use to create a great user experience for shell scripts

#134

Post by stephenr »

markus_zhang wrote: post #26
sureglymop wrote: post #19

Earlier quoted context omitted.

Sounds like a cool setup! Did you write it up somewhere publicly? I also use VMs (qemu microvms) based on docker images for development.

Sorry it's on my other machine so I don't have it at hand. But it's an extremely simple setup that configs the email, the user, removes the need of --set-upstream when pushing, automate pushing with token. I asked ChatGPT to write it and double checked btw.

Most of those things can just be set in your global git config file, and surely you're using some kind of repeatable/automated setup for VMs.. I don't see why you'd ever need to be doing something other than "copy default git config file" in your Vagrantfile/etc

Re: Techniques I use to create a great user experience for shell scripts

#135

Post by Aeolun »

Arch-TK wrote: post #123

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 everywhe…

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.

Re: Techniques I use to create a great user experience for shell scripts

#136

Post by nicbou »

Arch-TK wrote: post #126
Arch-TK wrote: post #123

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 everywhe…

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

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.

Re: Techniques I use to create a great user experience for shell scripts

#137

Post by otteromkram »

Aeolun wrote: post #135
Arch-TK wrote: post #123

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 everywhe…

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.

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

Re: Techniques I use to create a great user experience for shell scripts

#138

Post by teyc »

jiggawatts wrote: post #12

Every time I see a “good” bash script it reminds me of how incredibly primitive every shell is other than PowerShell. Validating parameters - a built in declarative feature! E.g.: ValidateNotNullOrEmpty. Showing progress — also built in, and doesn’t pollute the output stream so you can process returned text AND see progress at the same time. (Write-Progress) Error handling — Try { } Catch { } Finally { } works just l…

And for anyone who might be open to trying powershell, the cross platform version is pwsh.

Pythonistas who are used to __dir__ and help() would find themselves comfortable with `gm` (get-member) and get-help to introspect commands.

You will also find Python-style dynamic typing, except with PHP syntax. $a=1; $b=2; $a + $b works in a sane manner (try that with bash). There are still funny business with type coercion. $a=1; $b="2"; $a+$b (3); $b+$a ("21");

I also found "get-command" very helpful with locating related commands. For instance "get-command -noun file" returns all the "verb-noun" commands that has the noun "file". (It gives "out-file" and "unblock-file")

Another nice thing about powershell is you can retain all your printf debugging when you are done. Using "Write-Verbose" and "Write-Debug" etc allows you to write at different log levels.

Once you are used to basic powershell, there are bunch of standard patterns like how to do Dry-Runs, and Confirmation levels. Powershell also supports closures, so people create `make` style build systems and unit test suites with them.

Re: Techniques I use to create a great user experience for shell scripts

#139

Post by Aeolun »

ndsipa_pomu wrote: post #130
xyzzy_plugh wrote: post #127

Earlier quoted context omitted.

Thanks but I'm not really asking for advice. I'm uninterested in changing how I write correct, often POSIX-compliant shell scripts because of a linter that has an inferior understanding of the language. I'm also not a fan of this kind of dogmatic application of tools. Shellcheck can be useful sure, but my point is that, at least for me, the juice is often not worth the squeeze. I'm aware of how to disable rules. I of…

That's an odd way to respond to someone who's trying to be helpful. I find that there's a lot of good information in the comments on HackerNews, so sometimes advice and recommendations aren't just designed for the parent comment. Your reply adds nothing of value and comes across as being rude - you could have simply ignored my comment if you found it of no value to you.

I think it’s because:

> If ShellCheck is spitting out lots of warnings, then it'd be worth changing your shell writing style to be more compliant with it.

Is just a very roundabout way of saying ‘If you get a lot of errors using shellcheck you are doing it wrong’, which may or may not be true, but it’d make anyone defensive.

Re: Techniques I use to create a great user experience for shell scripts

#140

Post by Aeolun »

9dev wrote: post #115
xyzzy_plugh wrote: post #44

Earlier quoted context omitted.

I find shellcheck to be a bit of a nuisance. For simple one-shot scripts, like cron jobs or wrappers, it's fine. But for more complicated scripts or command line tools, it can have a pretty poor signal-to-noise ratio. Not universally, but often enough that I don't really reach for it anymore. In truth when I find myself writing a large "program" in Bash such that shellcheck is cumbersome it's a good indication that i…

It doesn’t already need to be a compiled language, that’s kind of like noticing you’re not going to walk down a mile to the pharmacy and decide to take a Learjet instead. The gradient should include Python or similar scripting languages before you reach for the big guns :-)

I think a lot of people jump to Go because it’s nearly as convenient as bash for writing shell scripts?
Post reply on HN