| Crates.io | getoptsargs |
| lib.rs | getoptsargs |
| version | 0.1.0 |
| created_at | 2025-12-23 08:52:28.504573+00 |
| updated_at | 2025-12-23 08:52:28.504573+00 |
| description | Imperative CLI application framework inspired by getopts |
| homepage | https://github.com/jmmv/getoptsargs/ |
| repository | https://github.com/jmmv/getoptsargs.git |
| max_upload_size | |
| id | 2001078 |
| size | 80,272 |
getoptsargs is a simple Rust library to process options and arguments in command-line applications. It is intended to be a small wrapper over getopts, an "ancient" library still used by no other than rustc, and to supplement it with argument handling.
getoptsargs is free software under the Apache 2.0 License or the MIT License at your discretion.
getoptsargs wants to offer and end-to-end implementation of main, not
just argument parsing, by letting you write your main program to return a
Result<i32>. This is to make it easier to propagate errors and make it
clear that exit codes are an important communication mechanism with the
calling program.
The visual interface exposed by getoptsargs tries to adhere to the GNU Coding Standards for command line interfaces as much as possible. Application using getoptsargs will feel "right at home" with other traditional tools in a Unix-like system.
The API in getoptsargs is imperative, not derivative as is found in the
more-popular clap or argh crates. This makes the code less magical,
albeit more verbose at times.
getoptsargs provides auxiliary test utilities to perform end-to-end testing of the executable, not just of internal APIs. These help ensure that the standard out and standard error of the program behave exactly as expected, which is important in offering high-quality, detail-oriented command line tools.
The interface exposed by getoptsargs intentionally mimics the getopts it inherits from, and getopts is not the cleanest Rust API. You'll notice some rough edges and terse names---but that's intentional to keep things simple and consistent.
There is no support for subcommand-based interfaces. This is currently out of scope for this library, but if there was interest, it could be added.
The basic structure of a getoptsargs application looks like this:
use getoptsargs::prelude::*;
fn app_setup(builder: Builder) -> Builder {
builder
}
fn app_main(_matches: Matches) -> Result<i32> {
Ok(0)
}
app!("Stylized App Name", app_setup, app_main);
The app_setup function is meant to use the builder to register supported
options and arguments whereas the app_main function is the entry point
that gets executed after parsing the user-supplied command line according
to what was specified in app_setup.
Consult the documentation at https://docs.rs/getoptsargs/ for the full API reference.
For functional sample programs, see the files under the examples
directory. These will tell you:
builder to define options and arguments, andmatches to access them after processing.