I was recently in the market for one of these! I ended up going with https://github.com/dbohdan/recur due to the nice stdout and stdin handling. Though this has stdout/stderr pattern matching for failures which is nice too!
Cool, I hadn't seen this one yet! Using Starlark is a very good idea. I ended up writing some tiny DSLs to specify certain things like status code patterns and durations; using an off the shelf DSL like Starlark would've saved a lot of effort.
I am reminded of the lack of really strong batch/job control of the sort I enjoyed as far back as VAX VMS at university, anything that brings a stronger capability to modern OS is welcome. This is I think a big missing thing.
This is useful. Don't want to think about how many times I have implemented retrying in shell scripts.
I appreciate the extensive documentation, but I would suggest adding the output of `attempt --help` to the README / docs, so that features can be discovered at a glance.
This is kind of neat. I appreciate how well it falls into the whole Unix philosophy of small tools that do one thing really well.
One thing I’m kind of curious about from a UI standpoint is why the exponential argument isn’t a double-hyphen flag. It kind of feels like it should be, given all of the other arguments are flags.
Thanks! That was the intention. There's a tool called `retry` which does an even better job by caching stdin so that it can be integrated into shell pipelines.
I was thinking of it as a subcommand, like `git pull`. I think of the backoff schedules as different "modes" the command can be put into, each with their own set of arguments. I also made some questionable design decisions and coupled too closely to the CLI argument parser (`clap`), which would make it a big pain to back out of that decision.
That would be a good name. If it's taken it's not in the Debian or Arch repositories. I've been working on this on and off for a couple years, so I honestly don't remember why I picked `attempt`.
Any time I hear people praising all these orchestrators, whether it's Docker, K8, or whatever, I remember that a good amount of it is all lies built with glue and sticks like "wait-for-it.sh".
I am very far from expert, but understood expect: https://linux.die.net/man/1/expect to be the "swiss army knife" for this type of thing.
One thing I’m kind of curious about from a UI standpoint is why the exponential argument isn’t a double-hyphen flag. It kind of feels like it should be, given all of the other arguments are flags.
I was thinking of it as a subcommand, like `git pull`. I think of the backoff schedules as different "modes" the command can be put into, each with their own set of arguments. I also made some questionable design decisions and coupled too closely to the CLI argument parser (`clap`), which would make it a big pain to back out of that decision.
https://formulae.brew.sh/formula/retry
https://manpages.debian.org/trixie/retry/retry.1.en.html
Any time I hear people praising all these orchestrators, whether it's Docker, K8, or whatever, I remember that a good amount of it is all lies built with glue and sticks like "wait-for-it.sh".