This is one big main function with all the logic in it besides clamping. This should be changed.

so allow some exit codes to be non retriable

For example, if after #3 I specify a SlotTime of 1s and my command takes 500ms, a sleep of 0 slots of length should last 0ms, whereas a sleep of 1 should last 500ms.

I'm not sure I like this design, but it'd certainly be more real-time.

I could also see just subtracting from the delay the time that elapsed during execution, then clamping with a lower bound of 0ns to prevent panics.

This is not good behavior.

It's far better to make main return a Result that can be coerced to std::process::Termination; this is a far cleaner way of doing things anyhow.

This will, as written currently, prevent SlotTime::UserSpecified from being changed as the slot time executes somewhat slowly.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update actions/checkout digest to 692973e
• Update actions/upload-artifact digest to 6546280
• Update Rust crate anyhow to v1.0.86
• Update Rust crate log to v0.4.21
• Update Rust crate thiserror to v1.0.61
• Update Rust crate clap to v4.5.7
• Update Rust crate simple_logger to v5
• Lock file maintenance
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

For example, eb -x 16 will only allow the command to be run 16 times.

This issue was generated by todo based on a TODO comment in 49b5720. It's been assigned to @rye because they committed the code.

This issue was generated by todo based on a TODO comment in 5ae19fe when #141 was merged. cc @rye.

It'd be far better, in my opinion, to launch sh -c with the arguments that are passed joined by a " ". This is what watch(1) does, so it wouldn't be too outlandish.

This might also let us drop the AppSettings::AllowExternalSubcommands and instead just accept all unmatched arguments as things to be joined when getting passed to sh -c.

• Figure out what to do with clap
• Call sh -c with arguments populated by our argv

I would like to figure out how to test this.

I think part of this will be extracting a runtime into more modular/testable code. I should also try to do integration tests.

Currently, all eb does is run a command.

It'd Be Nice™ if, instead, eb could also watch for activity.

For example, if I run eb ssh <server that is restarting>, I'd like to be able to have it wait until some kind of trigger is hit, like new console output or network activity or something.

Currently, the loop just waits until the command fully completes and checks the status code.

Question(s)

• Can we stop eb itself and let the child process become its own?

When doing prerelease testing for v0.4.0, I noticed that eb no longer accepts a command to run:

> cargo run -- --help
[...]
     Running `target/debug/eb --help`
eb 0.4.0-dev
Kristofer Rye <[email protected]>
A command executor exercising exponential backoff

USAGE:
    eb [OPTIONS]

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
    -x <max>        limits the number of times command is executed

Notice, in the above, that there isn't any mention of subcommands, as there is in v0.3.5:

> eb --help
eb 0.3.5
Kristofer Rye <[email protected]>
A command executor exercising exponential backoff

USAGE:
    eb [SUBCOMMAND]

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

I believe this was caused by #82. I'll be working on a fix before releasing v0.4.0.

Set up CI.

I would like to have some integration tests, too, not just unit tests.

Part of this can be serviced by the tests/ subdirectory. I can write a script (or something) that monitors when and how eb calls it.

Also, I'd like to keep track of all of the user-facing parts (usage, output)

Question(s)

• Is there a crate that allows me to test log! invocations?
• Is there a crate that allows me to compare snapshots of text?
• Could the most recent and its most recent questions be serviced by the same crate?