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

41–50 of 281 posts

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

#41

Post by dvrp »

These are all about passive experiences (which are great don't get me wrong!), but I think you can do better. It's the same phenomenon DHH talked about in the Rails doctrine when he said to "Optimize for programmer happiness".

The python excerpt is my favorite example:

```

$ irb

irb(main):001:0> exit

$ irb

irb(main):001:0> quit

$ python

>>> exit

Use exit() or Ctrl-D (i.e. EOF) to exit

```

Ruby accepts both exit and quit to accommodate the programmer’s obvious desire to quit its interactive console. Python, on the other hand, pedantically instructs the programmer how to properly do what’s requested, even though it obviously knows what is meant (since it’s displaying the error message). That’s a pretty clear-cut, albeit small, example of [Principle of Least Surprise].

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

#42

Post by skydhash »

rbonvall wrote: post #38
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

In my opinion, shell scripting is the right tool when you need to do a lot of calling programs, piping, and redirecting. Such programs end up being cumbersome in "proper" languages.

If there are already software written to do the stuff and I'm just coordinating them (no other computation other than string manipulation) I'd take bash every day. I would only reach to python if I need to do stuff like manipulating complex data structures or something with heavy logic.

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

#43

Post by TeeMassive »

I'd add, in each my Bash scripts I add this line to get the script's current directory:

SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )

This is based on this SA's answer: https://stackoverflow.com/questions/59895/how-do-i-get-the-d...

I never got why Bash doesn't have a reliable "this file's path" feature and why people always take the current working directory for granted!

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

#44

Post by xyzzy_plugh »

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 it should instead be written in a compiled language.

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

#45

Post by lilyball »

haileys wrote: post #18

Don't output ANSI colour codes directly - your output could redirect to a file, or perhaps the user simply prefers no colour. Use tput instead, and add a little snippet like this to the top of your script: command -v tput &>/dev/null && [ -t 1 ] && [ -z "${NO_COLOR:-}" ] || tput() { true; } This checks that the tput command exists (using the bash 'command' builtin rather than which(1) - surprisingly, which can't alwa…

If you use tput a lot it's also worth caching the output, because invoking it for every single color change and reset can really add up. If you know you're going to use a bunch of colors up front you can just stuff them into vars

  RED=$(tput setaf 1)
  GREEN=$(tput setaf 2)
  RESET=$(tput sgr0)

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

#46

Post by lilyball »

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…

What sort of noise do you see? I find it's pretty rare to run into something that needs to be suppressed.

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

#47

Post by edflsafoiewq »

klysm wrote: post #27
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.

Gotta draw a line somewhere

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

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

#48

Post by vondur »

richbell wrote: post #14
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…

I am Microsoft hater. I cannot stand Windows and only use Linux. PowerShell blows bash out of the water. I love it.

I’m curious. How useful is Powershell outside of a windows environment? I use it on Windows since much of the admin side of things requires it.

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

#49

Post by xyzzy_plugh »

lilyball wrote: post #46
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…

What sort of noise do you see? I find it's pretty rare to run into something that needs to be suppressed.

It's been so long since I used it seriously I couldn't tell you.

There's over 1000 open issues on the GitHub repo, and over 100 contain "false positive". I recognize several of these at first glance.

https://github.com/koalaman/shellcheck/issues?q=is%3Aissue+i...

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

#50

Post by skydhash »

jiggawatts wrote: post #39
sgarland wrote: post #20

Earlier quoted context omitted.

What? How are typed objects files? What I’m saying is that in *nix tooling, things are typically designed to do one thing well. So no, I don’t want my shell to also have to talk MySQL, Postgres, SQL Server, DB2, HTTP, FTP, SMTP…

> "So no, I don’t want my shell to also have to talk..." What's the point of the shell, if not to manage your databases, your REST APIs, files, and mail? Is it something you use for playing games on, or just for fun? > designed to do one thing well. Eeexcept that this is not actually true in practice, because the abstraction was set at a level that's too low . Shoving everything into a character (or byte) stream turn…

> What's the point of the shell, if not to manage your databases, your REST APIs, files, and mail? Is it something you use for playing games on, or just for fun?

It's for communicating with the operating system, launching commands and viewing their output. And some scripting for repetitive workflows. If I'd want a full programming environment, I'd take a Lisp machine or Smalltalk (a programmable programming environment).

Any other systems that want to be interactive should have their own REPL.

> This kind of thing is a challenge with UNIX tools, and then is fragile forever. Any change to the output format of netstat breaks scripts in fun and create ways. Silently. In production.

The thing is if you're using this kind of scripts in production, then not testing it after updating the system, that's on you. In your story, they'd be better of writing a proper program. IMO, scripts are automating workflows (human guided), not for fire and forget process. Bash and the others deals in text because that's all we can see and write. Objects are for programming languages.

Post reply on HN