add CLI option to identify a command with a custom name #330
Conversation
|
Thank you very much for your contribution! I am planning to take a closer look soon. |
|
Before I take a closer look at the code, I have a few questions:
As for the PR, could you please update the man page, if possible? Also, could you please add an entry to the "unreleased" section in where |
CLI option `--name` can be used to define the name to identify a command. If not passed, then the command itself is used. Commands and names are paired in the same order: The first command executed gets the first name passed as option. Close sharkdp#326
The output of the various See new commits for the updated changelog and man page. |
src/hyperfine/app.rs
Outdated
| @@ -226,6 +226,16 @@ fn build_app() -> App<'static, 'static> { | |||
| when trying to benchmark output speed.", | |||
| ), | |||
| ) | |||
| .arg( | |||
| Arg::with_name("command-name") | |||
| .long("name") | |||
There was a problem hiding this comment.
I would prefer --command-name for the long option. If we have a short option anyway, the long option should have a self-documenting character IMO... e.g. for shell scripts. If we change it, the man page also has to be updated.
There was a problem hiding this comment.
sounds good, see commit cc67788
| options.names = matches | ||
| .values_of("command-name") | ||
| .map(|values| values.map(String::from).collect::<Vec<String>>()); |
There was a problem hiding this comment.
I think we should show an error message if there are more names than commands:
hyperfine 'echo a' -n a -n b
Having too few is okay, but probably not really intended in most cases.
There was a problem hiding this comment.
OK I now return an error in that case, see 9ed5f0d
CLI option
--namecan be used to define the name to identify acommand. If not passed, then the command itself is used. Commands
and names are paired in the same order: The first command executed gets
the first name passed as option.
Close #326