The following items are conditionally considered "in scope" for phase 1:
cargo binrw new
CLI handling is broken down into the following cases:
[ ] 0x0 — cargo binrw new:
Since no project name is specified, this command will check if the environment contains a $CARGO_MANIFEST_DIR. If it's not found, we advise the user: "Could not detect a local Rust project. Please run cargo new before continuing."
[ ] 0x1 — cargo binrw new my-binrw-project
The user declared a project. This command will check if another project already exists in CARGO_MANIFEST_DIR, and informs the user if a project cannot be created: followed by an exit. If it can, this command creates "binrw.toml" under the manifest directory.
[ ] 0x2 — cargo binrw new .
(See above, but factor in the globbing "." to imply the current working directory")
cargo binrw & cargo binrw run
cargo binrw is an alias, or shorthand, for expressing the full command cargo binrw run. Its handling should be intelligent, or at the very least follow some heuristics I've laid out in src/lib.rs.
[ ] 0x3 — cargo binrw run [explicit options]
cargo binrw can support the following extra arguments to customize the process. These settings directly override anything in $CARGO_MANIFEST_DIR/binrw.toml. If the validation fails, inform the user and exit. Otherwise, run the server.
Since additional arguments may be passed after the provisioned structopt arguments, [extra] is collected from std::env::args() starting at the 3rd index (4th slot) (( I think )).
[ ] 0x5 —cargo binrw run
Use the values in $CARGO_MANIFEST_DIR/binrw.toml to update the runtime configuration. If the file does not exist, tell the user to run cargo binrw new use the default values for everything, and do not worry if a project exists or not.
- [ ] 0x6 — cargo binrw run --silent(-foreground[=[true|false]]?)> This one's tricky, but to support scripting/automation-testing, we can't hold STDOUT/STDERR hostage so one option is to spawn a TTY connection and feed it like you would a named pipe. The implementation must make an airtight case that this will be fully-closed at the end of the session.
[ ] 0x7 — cargo binrw run --logging ([true|false])
Tee all output to the log file indicated, otherwise treat the/target/binrw.log. Treat default behavior as appending to this file, else we risk burning someone's beloved log.
The following items are conditionally considered "in scope" for phase 1:
cargo binrw new
CLI handling is broken down into the following cases:
[ ]
0x0
—cargo binrw new
:[ ]
0x1
—cargo binrw new my-binrw-project
[ ]
0x2
—cargo binrw new .
cargo binrw
&cargo binrw run
cargo binrw
is an alias, or shorthand, for expressing the full commandcargo binrw run
. Its handling should be intelligent, or at the very least follow some heuristics I've laid out insrc/lib.rs
.[ ]
0x3
—cargo binrw run [explicit options]
[x]
0x4
—cargo binrw run --host 0.0.0.0 --port 8000 --project my-binrw-project -- [extra]
[ ]
0x5
—cargo binrw run
- [ ]0x6
—cargo binrw run --silent(-foreground[=[true|false]]?)
> This one's tricky, but to support scripting/automation-testing, we can't hold STDOUT/STDERR hostage so one option is to spawn a TTY connection and feed it like you would a named pipe. The implementation must make an airtight case that this will be fully-closed at the end of the session.0x7
—cargo binrw run --logging ([true|false])