I should write a tool that converts help output to troff, even if the result wouldn't be as detailed and nice to read as a good man page it would save me the frustration of having to stab at "will i get usage docs with a -h, a --help, a -help, or running it with no args at all".

Then again, the built-in help can not be seperated from the binary and be missing at run-time.

For Rust programs there's https://docs.rs/clap_mangen/0.2.31/clap_mangen/ that will generate a man page out of the help. (I am sure most programming languages have something like this). However, that's only useful if you are compiling the program (maybe distros could patch Rust programs to generate the man page during the build process)

A more general tool would be pretty good. Either for distros to call during build, after building the program proper; or for users to call.

If users are calling directly, it would be useful to, by default, show the regular man page if it exists, and only if it doesn't exist generate and display one out of --help. Also give it the same flags as man etc. In this case, we could do alias man=better_man and pretend this problem is already solved (but it's still better if distros generate it, so that they can display the man page on the web, etc)

This already exists: https://man.archlinux.org/man/extra/help2man/help2man.1.en

It does expect quite particular format for --help though iirc if you want a good result. It predates the AI craze by a good 20 years, so it reliably either works or doesn't.

This reminds me of go cli being pretty anal about this: you type `go fmt —help`, and it recognises you want help, but instead of showing the help, it tells you to use the totally non-standard cli pattern of `go help fmt` instead.

Reminds me of the rage of doing `man gnutool` and getting something complaining about how GNU info was where to go.

c-x alt-meta-shift eat-flaming-death

As others have mentioned, such tools exist. However, I believe they do more harm than help. Good --help output does not make for good --man output. In particular, while man pages are terse, good ones are more than just lists of command line options, and the part of them that are a list of command line options will usually have more detail than --help. The writing of documentation is a place where I often see programmers employ automation inappropriately.

It always struck me as a missed opportunity not to set a standard of `--man` for man page output from everything. GNU could have done that instead of their `info` nonsense.

I agree. If it can be launched from the command line, it deserves a man page.

Because installing a man page requires root and a writeable root fs for that matter

It doesn't need root if you set MANPATH.

> Because installing a man page requires root and a writeable root fs for that matter

That's not true. The user-equivalent of the man pages directory on Linux and BSDs is `~/.local/share/man`. You can have your mandb index it too. You can achieve more complex manpath indexing setups using the `~/.manpath` file.

I suspect a significant amount of that is due to requiring more than one file (the binary itself) and having to learn about multiple packaging and distribution systems. That's a gigantic wall to climb compared to "put a binary on github"

A lot of developers today want to play the maintener role as well. Where the idiomatic way is to publish source, docs about building and let other people take over distribution. Software like emacs and vim just publish a tarball.