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

261–270 of 281 posts

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

#261

Post by ndsipa_pomu »

specialist wrote: post #226
Aeolun wrote: post #139

Earlier quoted context omitted.

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.

I read it as "when in Rome...". Adopting any kind of quality assurance tool is implicitly buying into its "opinionated" worldview. Forfeiting one's autonomy for some person(s) notions of convention. Rephrased: Using shellcheck is a signal to potential user's, per the Principal of Least Astonishment. No matter if either party doesn't particularly care for shellcheck; it's just a tool to get on the same page more quick…

Yeah, there's that aspect to it as well. It's like using a coding convention - the reason behind the conventions may not be applicable for every time that you write a variable name, but I think they're good habits to get into.

e.g. I always put BASH variables in curly braces and double quotes which is often unnecessary (and more verbose), but it means that I don't trigger any ShellCheck warnings for them and it's easier to just type the extra characters than thinking about whether or not they'll actually make any difference.

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

#262

Post by ndsipa_pomu »

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?

It hasn't got the same level of cross compatibility though. I can just copy a BASH script from some x86 machine and it'll run just fine on an ARM processor.

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

#263

Post by ndsipa_pomu »

tambourine_man wrote: post #186
sgarland wrote: post #148

Earlier quoted context omitted.

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

Completely agree. I have a rule that if I’m using arrays I should move to Python, PHP, etc. It’s a nice red flag. Arrays in Bash are terrible and a sign that things are getting more complicated.

Akshuaaaly, I think you'll find that any BASH script uses an array for the command line arguments.

Personally, I'm fine with BASH arrays (even associative ones) and yes, the syntax can be opaque, but they get the job done. I find that the long-term advantages of BASH outweigh the many, many problems with it. (If you want something to keep running for 20 years on a variety of different machines and architectures, then BASH is easier to manage than almost any other language).

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

#264

Post by ndsipa_pomu »

0xbadcafebee wrote: post #255
electromech wrote: post #225

Earlier quoted context omitted.

> "It causes your script to die unexpectedly with no output." Oh? I don't observe this behavior in my testing. Could you share an example? AFAIK, if you don't capture stderr, that should be passed to the user. > "Instead, just check $? and..." I agree that careful error handling is ideal. However, IMO it's good defensive practice to start scripts with "-e" and pipefail. For many/most scripts, it's preferable to fail…

$ date +%w 0 $ cat foo.sh #!/usr/bin/env sh set -x set -eu -o pipefail echo "start of script" echo "start of pipe" | cat | false | cat | cat if [ "$(date +%w)" = "0" ] ; then echo "It's sunday! Here we do something important!" fi $ sh foo.sh + set -eu -o pipefail + echo 'start of script' start of script + echo 'start of pipe' + cat + false + cat + cat $ Notice how the script exits, and prints the last pipe it ran? It…

> the script exited with an error. But it didn't tell you that.

Yes it did, by having a non-zero exit code. However, it didn't explicitly mention that it didn't complete successfully, but that's down to the script writer. I like to include a function to tidy up temporary files etc. when the script exits (e.g. trap __cleanup_before_exit EXIT) and it's easy to also assign a function to run when ERR is triggered - if you wish, you can set it to always provide an error backtrace.

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

#265

Post by ndsipa_pomu »

baby wrote: post #199

Let's normalize using python instead of bash

Depends on how long you want the script/program to be usable.

Try running a twenty year old BASH script versus a python programme on a new ARM or RISC-V chip.

Or, try running BASH/python on some ancient AIX hardware.

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

#266

Post by tambourine_man »

ndsipa_pomu wrote: post #263
tambourine_man wrote: post #186

Earlier quoted context omitted.

Completely agree. I have a rule that if I’m using arrays I should move to Python, PHP, etc. It’s a nice red flag. Arrays in Bash are terrible and a sign that things are getting more complicated.

Akshuaaaly, I think you'll find that any BASH script uses an array for the command line arguments. Personally, I'm fine with BASH arrays (even associative ones) and yes, the syntax can be opaque, but they get the job done. I find that the long-term advantages of BASH outweigh the many, many problems with it. (If you want something to keep running for 20 years on a variety of different machines and architectures, then…

Command line argument parsing is already a complicated issue in Bash. It’s not a hard rule, but whenever I have to Google Bash’s array syntax I think to myself “stop it now, you’ll regret it”.

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

#267

Post by shepherdjerred »

timkq wrote: post #260
shepherdjerred wrote: post #222

Earlier quoted context omitted.

Shellcheck, and really any linter (and arguably also any other form of programming language safety, like static typing or compile-time memory safety), is not there for the very experienced author (which it sounds like you are). Those mechanisms exist for the inexperienced author (especially in a team setting) where you want some minimum quality and consistency. An example where Shellcheck might be useful for you is w…

This is one of the worst takes I've ever heard. People like you are the reason code breaks and kills people (or destroys property, etc.). Do you also refuse to use calculators, under the pretense of being too experienced, and as such calculating the square roots of four-digit numbers by hand?

I think you're misunderstanding my position. Either way, this is not a constructive comment. It contributes nothing to the discussion.

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

#268

Post by anonyonoor »

Arch-TK wrote: post #239
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.

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

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.

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

#269

Post by Arch-TK »

anonyonoor wrote: post #268
Arch-TK wrote: post #239

Earlier quoted context omitted.

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

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

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

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

#270

Post by [deleted] »

f1shy wrote: post #154
hinkley wrote: post #60

Earlier quoted context omitted.

There should just be a command for this. Like echo with a color flag that does something if you’re in a tty.

Why? Benefit? 10% of people hace problemas with colors. Depending on the terminal/background, you will produce bad/invisible output. Any good typesetting book will tell you not to use colors.

[deleted]
Post reply on HN