Removes the unnecessary restriction for descriptions to start with a lowercase letter.

Descriptions should not be required to start with a lowercase letter. This is not a standard.

Examples

struct Config {
    #[argh(switch)]
    /// Doggos are noisy. Dog goes WOOF
    bark: bool,
}

Disruptive change: default should be a string, not a code. Reason: options can already be parsed from a string, but not vice versa Pros: easy patch, easier defaults, no need to implement Display for opt Cons: invalid default value panics in runtime, no backward compatibility

Problem: Often, fields that are option members have long (descriptive) names that make sense in the source code, but are too long to type for cli options. The attribute short = 'x' can only take single chars, so that can't be used to shorten them.

Solution: Adding a way to rename cli option members using #[argh(rename = "name")]. Similar to #[serde(rename = "name")].

The previous commit to README doesn't update a package's documentation. It's essensially to upgrade package docs which is a main reference for developers.

https://github.com/google/argh/blob/329890897aac903864c6b3e1672d8ce32a3ef5c3/argh_derive/src/lib.rs#L437-L438

(Introduced in https://github.com/google/argh/pull/91)

This raw Result can cause type confusion where the user's type Result alias is used instead of std::result::Result, causing compilation failure.

error[E0107]: this type alias takes 1 type argument but 2 type arguments were supplied
   --> main.rs:205:10
    |
205 | #[derive(FromArgs, PartialEq, Debug)]
    |          ^^^^^^^^- help: remove this type argument
    |          |
    |          expected 1 type argument
    |
note: type alias defined here, with 1 type parameter: `T`
   --> main.rs:23:6
    |
23  | type Result<T> = std::result::Result<T, error::Error>;
    |      ^^^^^^ -
    = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

Other places in argh use std::result::Result, and if I change that one spot to std::result::Result as well, argh and my application once again test fine.

This PR allows Fuchsia DX tools to collect analytics without collecting any user passed data.

Any tool that wants to collect analytics can re-parse the args with an extra flag, "--dump_args_passed" to retrieve a string of the command options suitable for posting to analytics.

issue:

The current docs.rs badge image link points to https://docs.rs/com/badge.svg instead of https://docs.rs/argh/badge.svg

fix:

Modify the readme so the above badge image url points to the correct crate ('argh' instead of 'com').

Hi!

I was thinking about automatic print of the defaults to the help message, like kingpin and clap do ("-f, --file file [default: ~/path/to]"). After messing around argh code I realized that it would be not really trivial to make a PR... or trivial? What is your ideology about printing defaults to help?

Of course, the easy way is just to manually add them to the description, still...

Thank you!

I saw 329890897aac903864c6b3e1672d8ce32a3ef5c3 "Use license-file to point at license" and it strikes me as a step backward, or rather at least removing the license attribute does. According to the documentation (emphasis added):

If a package is using a nonstandard license, then the license-file field may be specified in lieu of the license field.

But this package is not using a nonstandard license. That doesn't seem to mean that we cannot use license-file instead, but doing so means that we have to verify that LICENSE contains a standard license, and in some cases consider any variation.

Can both license and license-file be used instead? And if not both, can the change be reverted so that we're not losing this important license information?

Source:

// argh_test/src/main.rs
use argh::FromArgs;

/// Test application
#[derive(Debug, FromArgs)]
struct Args {
    /// command to execute
    #[argh(positional)]
    cmd: Vec<String>,
}

fn main() {
    println!("{:?}", argh::from_env::<Args>());
}

Expected behavior

$ ./target/debug/argh_test a b c
Args { cmd: ["a", "b", "c"] }

$ ./target/debug/argh_test a b c --help
Usage: argh_test [<cmd...>]

Test application

Options:
  --help            display usage information

$ ./target/debug/argh_test -- a b c --help
Args { cmd: ["a", "b", "c", "--help"] }

Actual behavior

# OK
$ ./target/debug/argh_test a b c
Args { cmd: ["a", "b", "c"] }

# OK
$ ./target/debug/argh_test a b c --help
Usage: argh_test [<cmd...>]

Test application

Options:
  --help            display usage information

# Unexpected! --help is consumed by argh
$ ./target/debug/argh_test -- a b c --help
Usage: argh_test [<cmd...>]

Test application

Options:
  --help            display usage information

repeated #[argh(option] arguments are now shown in the help header appropriately:

#[argh(option)]
/// option
opt: Vec<String>,

• old output: [--opt <opt>]
• new output: [--opt <opt...>]

Option names can now be overridden with the arg_name = "string" attribute:

#[argh(option, arg_name = "opt_arg")]
/// option
opt: String,

• produces: --opt <opt_arg>

My project has a use case for negative switch flags. E.g:

--action // Sets args.action to true --noaction // Sets args.action to false

Yes, we could add the two flags ourselves, but then we'd have to handle the parsing logic and possibility of conflicts manually, and we'd have to implement it for every switch or else be inconsistent in our UX.

I would rather see a negative flag added as part of the macro for the switch type automatically, and have integrated checks to ensure the positive and negative aren't both included.

In some cases I don't expect Vec<T> to mean that the argument can be repeated, or Option<T> to mean that the argument is optional. For example an argument expects a comma-separated list of integers, which I would expect to be parsed by from_str_fn as Vec<i32>:

#[derive(FromArgs)]
/// some description
struct Args {
    /// some description
    #[argh(option, from_str_fn(parse_list))]
    list: Vec<i32>,
}

fn parse_list(s: &str) -> Result<Vec<i32>, String> {
    s.split(",").map(|n| n.parse()).collect::<Result<Vec<_>, _>>().map_err(|err| format!("invaild number {}", err))
}

The compiler raised error:

mismatched types
expected enum `Result<i32, _>`
   found enum `Result<Vec<i32>, _>`

I had to create a newtype:

#[derive(FromArgs)]
/// some description
struct Args {
    /// some description
    #[argh(option, from_str_fn(parse_list))]
    list: List,
}

struct List(pub Vec<i32>);

fn parse_list(s: &str) -> Result<List, String> {
    match s.split(",").map(|n| n.parse()).collect::<Result<Vec<_>, _>>() {
        Ok(list) => Ok(List(list)),
        Err(err) => Err(format!("invaild number {}", err)),
    }
}

If an attribute can be provided to make from_str_fn return Vec<T> or Option<T> as-is, the newtype will not be needed.

Similar to the click arg parse library from Python, it would be nice if argh had a similar feature. I am new to rust, so I can't suggest a good interface, but perhaps something like:

#[derive(FromArgs, Debug)]
struct Args {
    #[argh(choice, choices = vec!["foo", "bar", "baz"])]
    thing_type: String
}

but an enum might be a better option:

#[derive(Debug)]
enum Choice {
    Foo, Bar, Baz
}

#[derive(FromArgs, Debug)]
struct Args {
    #[argh(choice, choices = Choice)]
    thing_type: Choice
}

Perhaps this is possible already, but I couldn't figure out how to do so given the example and readme. Happy to close this if it is already possible.

Thanks!

This is a refactor that requires all structs that implement FromArgs to also derive the argh::Help trait if JSON encoded help is needed.

Added tests, still working on testing in an application.

Adding a subcommand for all commands, similar to help, which is responsible for generating all the subcommands for a given command.

This function can be used to assist with auto-completion in the shell by providing the set of possible subcommands available at the cursor.