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

231–240 of 281 posts

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

#231

Post by xelamonster »

necheffa wrote: post #177
maccard wrote: post #169

Earlier quoted context omitted.

You mean import os os.rename(“src.txt”, “dest.txt”) ?

Yes. And it is only downhill from there. Now, show us `mycommand | sed 's/ugly/beautiful/g' | awk -F: '{print $2,$4}' 1> something.report 2> err.log` in Python.

Is it really so bad? A bit more verbose but also more readable, can be plenty short and sweet for me. I probably wouldn't even choose Python here myself and it's the kind of thing shell scripting is tailor-made for, but I'd at least be more comfortable maintaining or extending this version over that:

  from subprocess import Popen, PIPE

  CMD = ("printf", "x:hello:67:ugly!\nyy$:bye:5:ugly.\n")
  OUT = "something.report"
  ERR = "err.log"

  def beautify(str_bytes):
      return str_bytes.decode().replace("ugly", "beautiful")

  def filter(str, \*index):
      parts = str.split(":")
      return " ".join([parts[i-1] for i in index])

  with open(OUT, "w") as out, open(ERR, "w") as err:
      proc = Popen(CMD, stdout=PIPE, stderr=err)
      for line_bytes in proc.stdout:
        out.write(filter(beautify(line_bytes), 2, 4))
I would agree though if this is a one-off need where you have a specific dataset to chop up and aren't concerned with recreating or tweaking the process bash can likely get it done faster.

Edit: this is proving very difficult to format on mobile, sorry if it's not perfect.

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

#232

Post by hidelooktropic »

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.

https://en.m.wikipedia.org/wiki/Bastard_Operator_From_Hell

For anyone else not familiar with this term

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

#233

Post by hidelooktropic »

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…

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

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

#234

Post by bmacho »

teo_zero wrote: post #216
GuB-42 wrote: post #35

Earlier quoted context omitted.

I also hate bash scripting, and as far as Unix shell go, bash is among the best. So many footguns... Dealing with filenames with spaces is a pain, and files that start with a '-', "rm -rf" in a script is a disaster waiting to happen unless you triple check everything (empty strings, are you in the correct directory, etc...), globs that don't match anything, etc... But interactively, I much prefer Unix shells over Pow…

> Dealing with filenames with spaces is a pain, and files that start with a '-', Wait! The fact that arguments with a leading hyphen are interpreted as options is not bash's fault. It's ingrained in the convention of UNIX tools and there's nothing bash can do to mitigate it. You would have the same problem if you got rid of any shell and directly invoked commands from Python or C.

> Wait! The fact that arguments with a leading hyphen are interpreted as options is not bash's fault. It's ingrained in the convention of UNIX tools and there's nothing bash can do to mitigate it. You would have the same problem if you got rid of any shell and directly invoked commands from Python or C.

A better system shell could make it easy to define shims for the existing programs. Also it could make their calling easier, e.g. with named arguments. So when you wanted to delete your file called -rf, you would say

  rm(file="-rf")
or something like that, with your preferred syntax. It would be much safer than just pass big strings as arguments, where spaces separate the different arguments, also spaces can appear in the arguments, also arguments can be empty. Bash or Posix sh is not very good at safely invoking other programs, or at handling files.

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

#235

Post by tstrimple »

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

This one becomes very apparent when using NixOS where /bin/bash doesn’t exist. The vast majority of bash scripts in the wild won’t run on NixOS out of the box.

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

#236

Post by hinkley »

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.

Why are you arguing against the entire thread as a reply to my comment?

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

#237

Post by xyzzy4747 »

f1shy wrote: post #157
xyzzy4747 wrote: post #22

Not trying to offend anyone here but I think shell scripts are the wrong solution for anything over ~50 lines of code. Use a better programming language. Go, Typescript, Rust, Python, and even Perl come to mind.

I agree with the general idea, but 1) LOC is not a good metric 2) I would immediately take off the list Python and Typescript, and anything what is compiled, leaving the list much shorter

TypeScript is good for this kind of a thing if you're only running it on your own machines and don't have to mess around with environments all the time. You can also run it with ts-node.

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

#238

Post by klysm »

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…

I would argue pipefail and set -e are much more reasonable defaults to take.

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

#239

Post by Arch-TK »

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.

> 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 instead my aim was to be as neutral sounding as possible, although I agree that the end result was still more dismissive than I would have hoped to achieve.

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

#240

Post by jiggawatts »

tpmoney wrote: post #190
jiggawatts wrote: post #97

Earlier quoted context omitted.

I know this sounds like nit-picking but bear with me. It's the point I'm trying to make: 1. Your script outputs an error when run, because 'bash' itself doesn't have netstat as a built-in. That's an external command. In my WSL2, I had to install it. You can't declaratively require this up-front, you script has to have an explicit check... or it'll just fail half-way through. Or do nothing. Or who knows!? PowerShell h…

Because I didn't see the edited version when I was writing my original reply and its too late, I want to call out another problem that you graciously overlooked that we can call #2 since it touches neatly on your #1 and #3 items and #2 is already missing. The extra junk you see in your wsl after the awk step is probably because the other big *NIX problem with shell scripts is my `netstat` or `grep` or even `echo` mig…

I was worried that my toy problem wasn’t complex enough to reveal these issues!

I had an experience recently trying to deploy an agent on a dozen different Linux distros.

I had the lightbulb moment that the only way to run IT in an org using exactly one distro. Ideally one version, two at the most during transitions. Linux is a kernel, not an operating system. There are many Linux operating systems that are only superficially “the same”.

Post reply on HN