#arguments #parsing #string #osstring #osstr


Traits and implementations for parsing command-line arguments

5 releases

Uses old Rust 2015

0.1.4 Sep 8, 2019
0.1.3 Sep 5, 2019
0.1.2 Dec 10, 2018
0.1.1 Nov 8, 2018
0.1.0 Nov 5, 2018

#134 in Command-line interface

Download history 922/week @ 2021-02-26 1174/week @ 2021-03-05 558/week @ 2021-03-12 497/week @ 2021-03-19 314/week @ 2021-03-26 375/week @ 2021-04-02 662/week @ 2021-04-09 846/week @ 2021-04-16 905/week @ 2021-04-23 1479/week @ 2021-04-30 1881/week @ 2021-05-07 1675/week @ 2021-05-14 2223/week @ 2021-05-21 2246/week @ 2021-05-28 1800/week @ 2021-06-04 1317/week @ 2021-06-11

3,939 downloads per month
Used in 16 crates (4 directly)

MITNFA license

454 lines

Parse arg

Traits and implementations for parsing command-line arguments.


This crate provides traits and implementations for parsing command-line arguments. The core of the crate is ParseArg trait. It works much like FromStr trait, but with these differences:

  • It operates on &OsStr instead of &str, thus allowing wider range of possible inputs.
  • It provides parse_owned_arg() method which can be specialized to avoid allocations.
  • It requires the implementor to provide describe_type() to print human-readable description. of expected input.
  • It requires the error type to implement Display in order to enable user-friendly interface.

Further, the crate provides ParseArgFromStr trait, which causes any type implementing it to auto-implement ParseArg trait. This is handy when implementing ParseArg for types that already have FromStr implemented, so that boilerplate is reduced.

Since matching both --foo VAL and --foo=VAL arguments is common and it's not an easy task to implement on top of OsStr, due to limitation of std, this crate also provides a function to match and parse such arguments.

Further, since many programs support -xVAL style parameters and short switches grouped into a single argument, which isn't easy to achieve using OsStr either, this crate provides a helper for this too.


I will merge new implementations liberally, provided these conditions are met:

  • The type is either in std or in another crate which is added as an optional dependency.
  • The description of the type is gramatically correct, readable explanation of the type, that can be appended to the string "The input must be " without sounding unnatural.
  • The user must be able to know how to formt the input based on the description without any googling. In case of doubt provide more precise description in parentheses.
  • Your contribution is licensed under MIT or MITNFA license.



No runtime deps