How to write idempotent Bash scripts

Post by mehrdadn » Sun, Jul 07, 2019, 7:09 PM UTC

riazrizvi wrote: post #98

NelsonMinar wrote: post #13

I got hung up on the claim "Touch is by default idempotent. ... A second call won’t have any effects". The whole point of touch is to have an effect every single time you run it. It updates the file atime and mtime. That may seem harmless in your application, but it's definitely not no effect. Also promiscuous touching is the source of a bunch of bogus last modified dates in source code bundles.

I've heard Idempotency confused with Consistency. Idempotency is where a function f can be applied (as a composition) multiple times and it gives the same result, so Idempotency: f(f(x)) = f(x) . Whereas Consistency: f(x) = f(x) = f(x) . An example of an idempotent function f is RaiseToThePowerZero(x) on x > 0. We usually take consistency for granted, so it's perhaps better to think of an example of a non-consistent…

Post by riazrizvi » Sun, Jul 07, 2019, 7:21 PM UTC

mehrdadn wrote: post #111

riazrizvi wrote: post #98

Earlier quoted context omitted.

I've heard Idempotency confused with Consistency. Idempotency is where a function f can be applied (as a composition) multiple times and it gives the same result, so Idempotency: f(f(x)) = f(x) . Whereas Consistency: f(x) = f(x) = f(x) . An example of an idempotent function f is RaiseToThePowerZero(x) on x > 0. We usually take consistency for granted, so it's perhaps better to think of an example of a non-consistent…

> as a convolution Sorry, what does idempotency have to do with convolution?

Post by kahlonel » Sun, Jul 07, 2019, 7:25 PM UTC

Zenst wrote: post #4

Many people who write scripts do not factor the environment they are run in and miss including traps to handle events like being terminated mid-way thru and cleaning up to a sanitized state. After all, creating a file, you can't presume their is enough free space, but people do in scripts all the time. Then you have scripts that you want run once and if run again not have any more effect. FOr example a script to be r…

  exec 999>/var/lock/my.lock
  flock -n 999 || exit 1
  if [ ! -f flag_file ]; then
    echo "script not ran before, running"
    touch flag_file
  else
    echo " already ran, exiting"
    exit 1
  fi
  # do stuff here

Post by dymk » Sun, Jul 07, 2019, 7:27 PM UTC

pmarreck wrote: post #70

dymk wrote: post #42

Earlier quoted context omitted.

How is that related to the article aside from "both involve bash"?

It's because rm -rf "$STEAMROOT/"* will evaluate as rm -rf "/"* if $STEAMROOT for some reason is blank or unset, which is what happened here. (As someone in that discussion mentioned, a little more Bash knowledge might have suggested using rm -rf "${STEAMROOT:?}/"* instead, to force it to (at least) error if it is empty or unset.)

Post by pas » Sun, Jul 07, 2019, 7:41 PM UTC

lukeschlather wrote: post #46

pas wrote: post #22

Earlier quoted context omitted.

Chef isn't magic, it just uses a lot of cookbooks which are just running things to check what the state is. Usually those cookbooks will want to have things in a particular way, which might not be the way you want. Chef/Ansible/Puppet all have the problem of having many layers of overhead for the same thing. This makes them slow, hard to debug, hard to read and even write (in my opinion). Sure, bash is hell, but the…

Rust doesn't get you anything resembling what you want here. Chef/Ansible/Salt could be described as rudimentary type systems for operating system states, that enable you to convert between different types/states. It's conceivable you could build such a system in Rust, but Rust itself has no primitives that would make it easy. It certainly isn't a good starting point when you want to set up a database server.