Rust: CLI library?

[Junilu Lacar]

Is there a library for Rust to process command line arguments?

I've worked with libraries in Go, Groovy, and Java and those have some really good abstractions for processing of Unix-like command line arguments, including displaying of usage messages, long and short options, automatic type conversion of arguments, etc.

If there are multiple such libraries for Rust, which one(s) would you recommend?

[D.J. Quavern]

Dearest Junilu,

Again, not the author but very eager to have a conversation.

The most popular CLI parsing crate I saw is clap. And those are the docs.

I wonder what more Ken will recommend us.

[Junilu Lacar]

I realized I should have said "crate" instead of library.  

Thanks for the tip. I'll check it out.

[Ken Youens-Clark]

Junilu Lacar wrote:Is there a library for Rust to process command line arguments?

I've worked with libraries in Go, Groovy, and Java and those have some really good abstractions for processing of Unix-like command line arguments, including displaying of usage messages, long and short options, automatic type conversion of arguments, etc.

If there are multiple such libraries for Rust, which one(s) would you recommend?

I exclusively used "clap" (command-line argument parser). It was the most similar to similar code I've used in Perl and Python, quite verbose and less "magic" than others. For the book, I wanted something with lots of documentation and very straight-forward usage. One problem is that I used v2.33 and they release v3 just after I published. (Rust moves very fast--the language itself updates *every six weeks*.) Some people don't like that clap can produce relatively larger binaries because it does so much. I don't personally care about that. To be honest, clap was the first crate I found that did what I wanted, so I didn't bother looking elsewhere.

I've seen some criticism that I used clap (both the older version and because of the binary size thing), but I've responded that each program I present clearly defines a section for parsing the arguments and a section for implementing the program logic itself. While I used clap, the reader is welcome to use any code they like so long as it passes the test suite (or they modify the tests to suite how they want to parse the arguments). Each chapter has a first section where I explain the goal of the challenge program and give lots of examples of inputs and behavior. This section always ends with a partially working version that shows how I use clap to parse the arguments, and the reader should complete the program using the test suite before moving to the solution section. Separating the code into the part that deals with the inputs and the part that does the thing means that programs can be use as CLIs/binaries or by other code.

[Ken Youens-Clark]

Junilu Lacar wrote:I realized I should have said "crate" instead of library.  

Thanks for the tip. I'll check it out.

This tripped me up the whole time I was writing the book. Old habits die hard. I had good Rustaceans checking my code and writing who kept me honest.

[D.J. Quavern]

Ken Youens-Clark wrote:

Junilu Lacar wrote:I realized I should have said "crate" instead of library.  

Thanks for the tip. I'll check it out.

This tripped me up the whole time I was writing the book. Old habits die hard. I had good Rustaceans checking my code and writing who kept me honest.

I did not mean that as a criticism in any way. I personally say "crate" and think "library".
Besides I am not a native English speaker so I needed to look up what crate even means.