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

141–150 of 281 posts

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

#141

Post by markus_zhang »

stephenr wrote: post #134
markus_zhang wrote: post #26

Earlier quoted context omitted.

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

That's a good idea. I use VirtualBox but I'm sure there is something similar I can do.

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

#142

Post by zimpenfish »

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…

> * #!/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...)

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

#143

Post by ndsipa_pomu »

Aeolun wrote: post #139
ndsipa_pomu wrote: post #130

Earlier quoted context omitted.

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.

You could be right - I certainly didn't intend my comment to be antagonistic.

My experience of ShellCheck is that you only get loads of warnings when you first start out using it and it finds all of your unquoted variables. Once you get more experienced with writing scripts and linting them with ShellCheck, the number of warnings should dramatically reduce, so it seems odd that an experienced script writer would be falling foul of ShellCheck being pedantic about what you're writing.

> ‘If you get a lot of errors using shellcheck you are doing it wrong’

I kind of agree with that, although a lot of ShellCheck's recommendations might not be strictly necessary (you may happen to know that a certain variable will never contain a space), it's such a good habit to get into.

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

#144

Post by archargelod »

One of my favorite techniques for shell scripts, not mentioned in the article:

For rarely run scripts, consider checking if required flags are missing and query for user input, for example:

  [[ -z "$filename" ]] && printf "Enter filename to edit: " && read filename
Power users already know to always do `-h / --help` first, but this way even people that are less familiar with command line can use your tool.

if that's a script that's run very rarely or once, entering the fields sequentially could also save time, compared to common `try to remember flags -> error -> check help -> success` flow.

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

#145

Post by sgarland »

xyzzy_plugh wrote: post #44
sgarland wrote: post #21

Nowhere in this list did I see “use shellcheck.” On the scale of care, “the script can blow up in surprising ways” severely outweighs “error messages are in red.” Also, as someone else pointed out, what if I’m redirecting to a file?

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…

I feel like that should be reversed. If you’re writing a tiny script, the odds that you’ll make a critical mistake is pretty low (I hope).

As others have pointed out, you can tune shellcheck / ignore certain warnings, if they’re truly noise to you. Personally, I view it like mypy: if it yells at me, I’ve probably at the very least gone against a best practice (like reusing a variable name for something different). Sometimes, I’m fine with that, and I direct it to be ignored, but at least I’ve been forced to think about it.

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

#146

Post by sgarland »

Aeolun wrote: post #139
ndsipa_pomu wrote: post #130

Earlier quoted context omitted.

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.

People should learn to take constructive criticism and harsh truths better. I saw nothing unkind with that comment.

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

#147

Post by xyzzy4747 »

wruza wrote: post #122
heresie-dabord wrote: post #37

Earlier quoted context omitted.

> shell scripts are the wrong solution for anything over ~50 lines of code. I don't think LOC is the correct criterion. I do solve many problems with bash and I enjoy the simplicity of shell coding. I even have long bash scripts. But I do agree that shell scripting is the right solution only if = you can solve the problem quickly = you don't need data structures = you don't need math = you don't need concurrency

I enjoy the simplicity of shell coding You mean, the complexity of shell coding? Any operation that in a regular language is like foo.method(arg) in shell expands into something like ${foo#/&$arg#%} or `tool1 \`tool2 "${foo}"\` bar | xargs -0 baz`.

Exactly, plus there's no compiler or type safety.

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

#148

Post by sgarland »

Aeolun wrote: post #140
9dev wrote: post #115

Earlier quoted context omitted.

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?

People say that (and the same for Python), but I just don’t get it – and I’m a huge fan of Python.

With shell, I can take the same tools I’ve already been using as one-liners while fiddling around, and reuse them. There is no syntax mapping to do in my head.

With any other language, I have to map the steps, and probably also add various modules (likely within stdlib, but still). That’s not nothing.

I’ve rewritten a somewhat-complicated bash script into Python. It takes some time, especially when you want to add tests.

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

#149

Post by Architrixs »

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.

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

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

#150

Post by redserk »

otteromkram wrote: post #137
Aeolun wrote: post #135

Earlier quoted context omitted.

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.

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.

Post reply on HN