I also find myself using https://man.archlinux.org/ a lot. It's much more readable/user-friendly than https://man7.org plus it contains man-pages from their `extra` repo which contains a lot of popular oss tooling.

unfortunately there's a trend lately where many newer cli tools don't have a man page. they put up a --help and think it suffices

even though there are tools to automatically generate man pages those days

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.

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".

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.

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)

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.

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.

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

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

> 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.

It doesn't need root if you set MANPATH.

That's great! I didn't know that Arch had online manpages too. I frequently use https://manpages.debian.org/ for similar reasons.