when do you usually use the man page for a complex command line tool to answer a question you have? (like git, openssl, rsync, curl, etc)
(edit: no need to say "i use --help then man")
when do you usually use the man page for a complex command line tool to answer a question you have? (like git, openssl, rsync, curl, etc)
(edit: no need to say "i use --help then man")
i'm very curious about everyone who says "I'd look there first", if I want to figure out how to do something new I think I'll usually google how to do it rather than look at the man page, and then maybe later look at the man page to look up the details
(I've gotten enough of these answers:
- "I like that man pages don't require changing context"
- "with the man page I know I have the right version of the docs")
@b0rk for me, I think it's a combination of an 'old people' thing and a 'highly suspicious of a lot of the modern Internet' thing.
When I learned to use computers, competent search engines and rich online resources like Stack Exchange were a long way off – even having the Internet in your home without paying per minute wasn't around yet. So you had to develop the skills of finding stuff out from the available local resources like manuals, because that was all you had.
Then good search engines came along, but I was always aware that there's a risk of depending too much on them and losing the ability to figure stuff out yourself. Even now, I sometimes find myself coding without the Internet (or effectively so – laptop on train with terrible connectivity) and it's useful that I can still get things done.
And now search engines are all getting enshittified, and/or monetised, and/or straight-up _worse_ (Google doesn't return the results I actually wanted nearly as often as it used to). And the less said about 2020s answers to this kind of question, the better. So I'm doubly glad I haven't abandoned my old approaches to things. More and more I feel it's important to keep external corporately-provided "do it for you" services at arm's length, and not base your whole workflow on them to the extent that you're a captive market or dependent on them not going down.
@b0rk @simontatham You've DEFINITELY given me something to think about.
In rsync's case in particular, I go to the HTML version of the man page on Samba's website and look it up there. I think if the man page was easier to invoke outside of a terminal window with browser/editor bindings (read: CTRL+F), I train my brain to use the local copy.
@cr1901 @b0rk @simontatham for certain tools that have a capital-M Manual—you know, the organized kind that you'd get an HTML or PDF render of—you'll sometimes find the HTML packaged in Linux distros (as a separate -doc subpackage if not in the main package itself). but to open such docs, you'll have to root around in /usr/share{,doc}, and that's if you know the manual exists in the first place; you might just as well find a bare-minimum README...
seems like there's an unfilled niche for making a system's heterogenous doc tree more discoverable. something with slightly more tailored UI than a directory tree view (let alone navigating to each one individually). a generated HTML page would be a good start, and a plugin for KHelpCenter and such would be really cool. it's entirely possible there's an existing solution here I'm just not familiar with, though
@rudi @b0rk yes, programming languages that have a strong culture of good docs are definitely a plus.
Still on the subject of decoupling myself from Internet dependence, I've been working hard on my Rust workflows recently so that I more often use local `cargo doc` or `rustup doc` instead of just going to docs.rs/foo or doc.rust-lang.org/bar. Partly that means I can still consult the docs if the Internet is out of reach, and partly it means I get the version of the docs that matches what I'm actually using.
("Working hard" in the sense that first I had to fix some annoying problems that meant those commands didn't even work for me, like Ubuntu wanted to open the rustdoc output in Abiword, or rustup put its docs somewhere that the apparmor restrictions on snap!Firefox didn't let it read.)