docopt

docopt.rs

Rust2014–2024

docopt / docopt.rs · Archived

docopt.rs

Docopt for Rust (command line argument parser).

Command Line Languages & Compilers

Explore on GitHub Read Hacker News discussions

9Distinct people

12Mentions

1Explicit recommenders

747GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Docopt for Rust (command line argument parser).

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

I love docopt and I love rust. This thing written at [the docopt rust repo.] worries me > the wider docopt project is mostly unmaintained at this point. Consider using clap or…

jbaber used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year12 dated mentions

Observed mentions: 2014-07-07 21:54:53 UTC to 2024-08-08 07:30:31 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2014	2014-01-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	4	1	3
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	1	0	1
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	0	0	0
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	0	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	0	1
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	0	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	0	1
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	0	1
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	1	0	1
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	1	0	1

What Hacker News says

12 sources

clan·Aug 8, 2024

Yes, according to the archived Rust implmentation[1] which in turn refers you to either clap[2] or structopt[3]. Other implmentations does not mention this but those I looked at had not been touched for years. Either very stable or unmaintained. Unfortunately the latter according to the Rust crate. The dotNet implmentation had a very small version bump in the dependencies but the rest of the project does not seem to have been touched the past 2 years. [1] https://github.com/docopt/docopt.rs [2] https://docs.rs/clap/latest/clap/ [3] https://docs.rs/structopt/latest/structopt/

In Argdown, like Markdown for argument mapping

jbaber·Mar 18, 2023Recommendation phrase

I love docopt and I love rust. This thing written at [the docopt rust repo.] worries me > the wider docopt project is mostly unmaintained at this point. Consider using clap or possibly structopt instead. It's a lovely way to internalize the CLI argument cultural norms, decrease confusing and verbose argument parsing, make argument parsing work-free for the developer, and make argument parsing a copy-paste across languages. There's no greater pleasure than iteratively adding options to your program by just adding a line of text -n, --new-option Do something new I honestly think making a docopt parser is just very hard, which may limit its future prospects. [the docopt rust repo.]: https://github.com/docopt/docopt.rs

In Docopt.sh – Command-Line Argument Parser for Bash 3.2, 4, and 5

burntsushi·Jul 25, 2022

Ditto, I guess? :P (But obviously with the position on the Unlicense flipped.) To address your indictment head-on: you suggesting the 0BSD as a better alternative is really missing my point. The 0BSD is not an alternative for my use case. The Unlicense is one of the very few overt "political" acts that I inject into the software I produce. Its purpose is to make a statement. The 0BSD doesn't do that IMO, so it's not actually an alternative that meets my advocacy goal. You and Rick Moen seem to have the same apparent blind spot for this. See my conversation with him that started here (which might also clarify some aspects of my own position): https://github.com/docopt/docopt.rs/issues/1#issuecomment-42... And finally, note that my dual licensing scheme is exactly a response to the "problems pointed out by quite a few people": https://githu

Read the rest

b.com/BurntSushi/byteorder/issues/26

In [Fedora-legal-list] Change in classification of CC0

dbrgn·Dec 31, 2021

I like Docopt for quick scripts, used it both in Python and Rust projects. It is quite unflexible though. The Rust Docopt implementation¹ was deprecated this year, which is probably good because clap v3² is so awesome. In a project of mine (tealdeer), I noticed that docopt.rs was responsible for the huge majority of CPU instructions when running the binary: https://github.com/dbrgn/tealdeer/issues/106#issuecomment-59... I then switched³ to clap and shaved off almost a megabyte from the release binary⁴. Performance improved as well, time required for rendering a tldr page went down from ~15.9 ms to ~12.4 ms⁵. With the migration, we also managed to reduce a lot of custom validation logic and move this logic into the derive macro attributes. ¹ https://github.com/docopt/docopt.rs ² https://github.com/clap-rs/clap ³ https://github.com/dbrgn/te

Read the rest

aldeer/pull/108 ⁴ https://github.com/dbrgn/tealdeer/pull/108#issuecomment-9448... ⁵ https://github.com/dbrgn/tealdeer/pull/108#issuecomment-9448...

In Docopt

rnestler·Aug 10, 2019

For small utilities I prefer to use docopt (https://github.com/docopt/docopt.rs). With docopt you just write down the documentation how you imagine the tool to be used and the docopt magic generates the command line parsing for you.

In In Praise of Rust's Structopt for Command Line Parsing

roblabla·Jun 15, 2018

Well, everything I've said here are grounded in personal experience working on FOSS projects. They're also grounded in trust of the maintainers. In 5 years of full-time programming as a job and a hobby, I have found that to work to my advantage. I can understand that this might not be everyone's experience. I also understand that different projects have different needs - some might simply be too sensitive to depend on external code if they can help it. To answer your rhetorical questions: I would certainly depend on leftpad, as it allows me to free my mind to something more useful. I probably wouldn't depend about is-odd because I intuitively know how to make it work. That's pretty personal. The line is basically drawn at "do I need to think to figure this out." Yes, leftpad is trivial. But this is death by the thousand papercuts: When I

Read the rest

program something, I'm solving a problem. Having to solve a million other problems at the same time - no matter how trivial - is going to take me away from what I'm supposed to actually doing. It breaks my flow. I don't like that. > Copying/hand rolling some trivial code is often faster than deciding among a dozen libraries which do the same thing, reading their docs, their issue pages and open PRs, adding and integrating to my project. I have found this to not be the case. In the JS land, depending on a library is beyond trivial. Especially for those "simple" libraries that simply export a function. Yes, I do need to read the docs, but there isn't a million ways to do leftpadding, nor is there a million ways to do UUID generation. Copy pasting code might require playing with requires, figuring out transitive dependencies, and just some manual work that take time away from actually thinking about the code I'm working on - again, breaking my flow, forcing me to context switch. > I must keep the dependencies updated. I must read changelogs and hope nothing breaks. Semver takes care of that for you. And yes, I trust maintainers to follow semver. Again, that generally works. I only had a single case of semver-breaking release in my life, and that was in the Rust land - docopt.rs 0.8.2. https://github.com/docopt/docopt.rs/issues/235. Debugging the issue took me at most an hour, reporting it to upstream took seconds, and the fixed version was released literally 10 minutes later. In the meantime, my install still worked due to the lockfile pinning the previous docopt version. I could easily continue working normally. Breakage happen. I've found that breakage also happen internally. Sometimes I change my code and break my own invariants. Refactor and forget to fix an instance, which breaks the code in subtle ways. Bugs happen. I accept that. > I have full control & understanding of the code; I can adjust & trim so it fits as much as possible. If it breaks, I can fix it directly. This is where I totally disagree. Depending on a third-party package does not deprive me of the ability to fix code when it breaks. And in fact: it empowers me. Again, the major advantage of dependencies, in my view, comes from the community. And if it needs adjustment that could be beneficial to others, I can PR it. I can fork, and npm has tools to make it easy to inject a fork into the dependency tree, replacing all instances with my own. This lets me experiment with potential fixes with ease, as if it was my own code. Sure, sometimes, the library might not do exactly what I want it to, exactly how I want it to. Maybe what I want to do is incompatible with said libraries. In those cases, rolling my own might make sense. In the end, it comes down to this: I trust the community, and believe in taking and giving back. If that's a young point of view, then so be it. Maybe I'll learn the hard way that reality is not so forgiving, that my trust was misplaced.

In Critical vulnerability of NPM package macaddress

jmcomets·Feb 6, 2017

> Perhaps not quite as safe, but at least that they deliver the important parts of that safety without the cost of the learning curve. Sorry to say this but a lot of unsafe code has been written in Java or C#, putting aside the NPEs and such. In Rust safety isn't only about eliminating SEGFAULTs and buffer overflows, but also preventing data races and most concurrency issues. It's common to add threading to cpu-bound code, without worrying about deadlocks or race conditions. Rust also allows some very high-level code. Some of my favorite options out there: - option (std): https://doc.rust-lang.org/std/option/index.html - serde: https://github.com/serde-rs/serde - docopt: https://github.com/docopt/docopt.rs Some more features: generics (traits!), immutability by default, type inference, first-class functions, operator overloading, conversi

Read the rest

on between related types.

In What Rust Can Do That Other Languages Can't

burntsushi·Jan 13, 2015

CSV parsing: https://github.com/BurntSushi/rust-csv Arg parsing: https://github.com/docopt/docopt.rs

In Announcing Rust 1.0 Alpha

burntsushi·Nov 7, 2014

> A good (trivial) example was a great command parsing library just doesn’t exist yet. There is a Docopt implementation in Rust[1], which is used by Cargo. It tracks master and is regularly updated. Interestingly, I've found people either love or hate Docopt, so maybe you knew about it but don't like it. :P /shameless plug [1] - https://github.com/docopt/docopt.rs

In Rust and Go

wycats·Sep 27, 2014

Yes, compiler plugins. For a relevant example, check out the Rust docopt crate[1]. An identical technique could be used for yacc or protobufs. [1]: https://github.com/docopt/docopt.rs

In Go generate: A proposal for a Go preprocessor

dbaupp·Jul 16, 2014

Comparing a constant: string.as_slice() == "foo" "Parsing" command line args (it's not as slick as it could be, but it's not entirely horrible... for me as an experienced Rust user anyway): match std::os::args().as_slice() { [] => println!("need more arguments"), [ref x, ..] if x.as_slice() == "-h" => print_help(), [ref a, ref b] if a.as_slice() == "-f" => write_to_file(b.as_slice()) args @ _ => println!("unrecognised arguments: {}", args) } Of course, using a proper parser like getopts or docopt.rs would be better: - http://doc.rust-lang.org/master/getopts/ - https://github.com/BurntSushi/docopt.rs I think it gets smoother with practice (as in, with practice you're able to know intuitively when you need .as_slice and when a `ref` is required etc.), but yes, improving the ergonomics will be nice. Dynamicall

Read the rest

y sized types will allow for String to be treated implicitly as a &str in many cases, so, e.g., my_string.trim() will work (it currently requires `my_string.as_slice().trim()`). And there is some loose talk about overloading pattern matching via the same mechanism, which would allow proper pattern matching on String with literals `"..."`. > support generic pattern matching. There's some subtlety here, e.g. Haskell doesn't support pattern matching on Data.Vector.Vector or Data.Text.Text (which are some of the closest equivalents to &[T], Vec<T> and String).

In State of Rust 0.11.0

burntsushi·Jul 7, 2014Submission

Docopt for Rust

3 points · Open discussion