Show HN: Attempt – A CLI for retrying fallible commands
16 comments
·September 9, 2025NightMKoder
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!
maxbond
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.
bharrison
Very nice work!
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.
nickdothutton
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.
jalk
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.
brirec
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.
maxbond
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.
lloydatkinson
> `wait-for-it.sh` for use in Docker Compose.
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".
juliangmp
This looks nice Maybe I can finally replace that sshtry shell function which I've been using for a few years
Hi HN,
Here's a tool I wrote for retrying fallible commands. Nothing groundbreaking here, this is a tool that's been made many times (and several have been submitted to Show HN). Though this one does have a more comprehensive feature set than most. I hope one or two people will find it useful.
I wrote `attempt` for two reasons:
- To have a more featureful alternative to `wait-for-it.sh` for use in Docker Compose. Specifically to apply migration scripts to a database that may not be up yet. I wanted to be able to inspect the error messages from my migration tool & retry on connection errors.
- To test a hypothesis I had that a good way to make a CLI was to copy the API of a good library (in this case, `tenacity`). I want to write a blog post at some point to discuss this at length, but the tl;dr is that I believe it was a success.
Here are some usage examples: https://maxbondabe.github.io/attempt/usage.html
There may not be much to discuss for such a small tool, but I am open to all feedback and am happy to answer any questions.
Cheers,
Max