Hacker News Reader

Comment by hyperpallium | Hacker News Reader

> [...] the "big realization" for me was shifting to think in pipelines instead of passing state around in variables. That completely removed the pain of no arrays [...]

Could you elaborate please? I see that data - especially sequential, array-like data - is conveniently passed via pipes (and e.g. jq https://stedolan.github.io/jq/ uses this concept), but I feel you're saying something deeper or a different kind of use-case... [perhaps because you say "state" not "data")

View on HN

The sibling comment by @glic3rinu pretty much says it, but I'll elaborate a little bit. Can't make any claims about being anything deep, but in a sense, my shift in perspective came from treating program state as "data in pipes" and doing that as extensively as possible.

A big part of this was figuring out I could the `read` builtin to parse stuff into local variables:

    if read -r foo bar baz _; do
        # do stuff with $foo, $bar, $baz
        # $_ contains anything extra on the line
    done

Also, once everything is on stdin, all the standard unix tools Just Work without having to echo and print everywhere, e.g. something like

    echo $some_local variable | unix_tool

For me, this turned a lot ugly scripts into primarily a collection of functions that compose nicely via pipelines.

Anyway, using `read` works especially nicely with tabular data too. For example, a naive CSV parser might look like

    while IFS=',' read -r field1 field2 field3 _; do
        # do stuff
    done

  while IFS=',' read -r field1 field2 field3 _;   do
    # do stuff
  done

This is the reason we need something better than bash than stick with it until it's been used for 50 years. It's just too cryptic.

Fish is better but still looks legacy.

> Fuck quoting/escaping, it will work 99% of the time.

Encouraging this is why bash scripts scare me.

By "state" I think OP is referring to an style of programming heavily based on global variables (global state). Function calls set global variables that the caller can read after. Functions and imports (sourcing) are all riddle with "side-effects", making the execution of the program very difficult to follow (spaghetti code).

Because "return values" in bash are implemented by echoing (printing to stdout):

  return=$(my_function arg1)

I believe OP has the point that echoing friendly-parsable output is a way of implementing "data-structures" in shells.

  result=$(my_function arg1)
  result_a=$(echo "$result" | grep A)
  result_b=$(echo "$result" | grep B)

Reply on news.ycombinator.com