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'll confess I've never used `expect`, but I think `expect` is for interactive commands. I think if you were going to write retry logic in bash you would pipe it to `grep` and examine the return code. If `grep` doesn't find any matches, it'll exit with a status code of 1.
I'd never heard of the `wish` command shell (discussed briefly in that document) but you can always rely on the Tcl community to find a great pun.
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 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.
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.
Thank you for the suggestion. It's a reasonable one. I'm undecided. The --help output is pretty long, I don't want to put so much information in the README that it damages it's legibility. But you're right that the documentation is maybe too dense for easy discovery. I'll add it to the docs shortly, but for the README I'm going to keep thinking about it for now.
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".
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`.
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.
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.
I'll confess I've never used `expect`, but I think `expect` is for interactive commands. I think if you were going to write retry logic in bash you would pipe it to `grep` and examine the return code. If `grep` doesn't find any matches, it'll exit with a status code of 1.
I'd never heard of the `wish` command shell (discussed briefly in that document) but you can always rely on the Tcl community to find a great pun.
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 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.
I also think `retry` is the most widely known of these?
https://formulae.brew.sh/formula/retry
https://manpages.debian.org/trixie/retry/retry.1.en.html
Probably, it's the only one that's in OS package managers to my knowledge.
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.
Thank you for the suggestion. It's a reasonable one. I'm undecided. The --help output is pretty long, I don't want to put so much information in the README that it damages it's legibility. But you're right that the documentation is maybe too dense for easy discovery. I'll add it to the docs shortly, but for the README I'm going to keep thinking about it for now.
I've created an issue: https://github.com/MaxBondABE/attempt/issues/5
This looks nice Maybe I can finally replace that sshtry shell function which I've been using for a few years
> `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".
This great! Thank you for writing it.
Thanks! Glad you like it!
Is “try” taken as a CLI command? Seems like a better name.
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`.
There is no try. There is only do
`dotry`