Closed andLaing closed 1 year ago
If you just need to use makelor
, the quick workaround seems to be to pass --out ...
after INFILES
.
If you want to fix it, well It looks like this might be a bug in clap
which only manifests itself in the presence of all of
cargo
Here's a minimal example to demonstrate it:
use clap::Parser;
#[derive(clap::Parser)]
#[clap(name = "erm", about = "Doesn't accept NAMED before ANONYMOUS as advertised by USAGE")]
pub struct Cli {
// Changing this from Vec<u32> to u32 makes the problem go away
pub anonymous: Vec<u32>,
#[clap(short, long)]
pub named: u32,
// Removing this makes the problem go away
#[clap(subcommand)]
reco: Subcommand,
}
#[derive(clap::Subcommand)]
enum Subcommand {
SubA,
SubB,
}
fn main() {
Cli::parse();
println!("All's well");
}
target/debug/erm 1 --named 2 sub-a
workstarget/debug/erm --named 1 2 sub-a
workscargo run --bin erm -- 1 --named 2 sub-a
workscargo run --bin erm -- --named 1 2 sub-a
failseven though the last one is consistent with the clap
-generated USAGE suggests:
USAGE:
erm --named <NAMED> [ANONYMOUS]... <SUBCOMMAND>
Almost like an old school magical mystery seg fault from C++. OK, so not a bug in our code but a limitation of clap. There's a newer version (3.2.22
) than we have (3.2.20
), should we try changing versions before we complain?
I get the error for the suggested order both with and without cargo
for makelor
in the master, that is:
target/release/makelor src/io/test.h5 --out mklor-test.h5 first-vertex
workstarget/release/makelor --out mklor-test.h5 src/io/test.h5 first-vertex
failscargo run --release --bin makelor -- src/io/test.h5 --out mklor-test.h5 first-vertex
workscargo run --release --bin makelor -- --out mklor-test.h5 src/io/test.h5 first-vertex
failswhere works and fails just means a normal flow vs. the help screen appears.
There's a newer version (
3.2.22
) than we have (3.2.20
), should we try changing versions
Seems to give me the same problems.
before we complain?
I've already submitted an issue. No 4238.
I get the error for the suggested order both with and without
cargo
formakelor
in the master, that is:
target/release/makelor src/io/test.h5 --out mklor-test.h5 first-vertex
workstarget/release/makelor --out mklor-test.h5 src/io/test.h5 first-vertex
failscargo run --release --bin makelor -- src/io/test.h5 --out mklor-test.h5 first-vertex
workscargo run --release --bin makelor -- --out mklor-test.h5 src/io/test.h5 first-vertex
failswhere works and fails just means a normal flow vs. the help screen appears.
Hmm. Same here. What happens if you paste the example I showed above into src/bin/erm.rs
and try the four usage examples I showed?
I know that zsh
has some options which sometimes mess with command lines which work fine in bash
, and I'm using a fancily-configured zsh
.
What happens if you paste the example I showed above into src/bin/erm.rs and try the four usage examples I showed?
In the same order: works, fails, works, fails.
I know that zsh has some options which sometimes mess with command lines which work fine in bash, and I'm using a fancily-configured zsh.
I'm using the standard .zshrc
with the only additions being a few aliases, direnv added and Julia and cargo added to the path
The problem was caused by the algorithm (first-vertex
, bary-vertex
, etc.) being interpreted as one of the arbitrary number of input-file positional arguments. Adding a clap option fixes this.
The interface might be improved, but it's not obvious how. At least the suggested usage now works.
In the current HEAD version of the code the
makelor
binary does not launch properly.Running
cargo run --release --bin makelor -- --out ../mcred_data/sanity-comp/rust/reco-lors.h5 ../mc_raw/sanity-dz1m-LXe40mm-noQrz-6/sanity-dz1m-LXe40mm-noQrz-6-185.h5 first-vertex
yields the help output which indicates that the command is valid.The problem is present since 7267a10b1985b8fa88f4b11f28de2e058c23fbd5 though I can't find anything obviously wrong compared to the
clap
documentation I've read so far.