when do you usually use the man page for a complex command line tool to answer a question you have?
-
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")
@b0rk the mentioned utilities, mostly man page. ffmpeg? Straight to search.
-
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 I have two hopes when looking at the man page.
- There will be an EXAMPLES section that shows how to do what I'm trying to do (or an example similar enough that I can adapt it to what I'm doing)
- Looking over the argument list in th eman page will impart clue about the problem space so I can better navigate it to my desired destination.If there's nothing in the man page (or if I've already been there and know it's wont' be fruitful), I plug in `<tool> <operation> example` and hope I'm not living in https://xkcd.com/979/
-
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 use the `tldr` CLI to get the gist of things first and if more is needed, then I dig into the `man` page for the specifics I need.
-
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 I usually check it first and `/` search in there for keywords related to what I want to do, then if I don't see anything useful, I switch to duckduckgo.
Basically, I am already in the terminal, and there's a chance that I could find my answer in 5-15 seconds, so I try, and then move on if not.
Now, when I have successfully done that for a command before, the next time I have an issue with that command I will waste 15 minutes in the manpage because it was so easy the last time and I shouldn't give up. 😅
-
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 The Unix User's/Programmer's Manual is the *reference* documentation, but was never intended to provide introductory guides or conceptual overviews — as originally distributed those were separate documents. The man page should tell you how to do the thing when you already know what you want and that there's a command/function to do it, and you just need the invocation details. Unfortunately the higher level conceptual documentation has fallen by the wayside.
-
@sgharms @b0rk
Agree, but there is a significant gap in the quality between BSDs, Illumos/Solaris and likely other Unixen mans versus Linux ones, especially in a way to provide a useful usage examples for common use cases.In case of a Limux man I may scroll through pages of options to find nothing on how to combine them correctly, thus I switch to a search engine to get what I need (if I don't have time to experiment).
That's why to me Illumos mans are gold, that's why the FreeBSD handbook is _the_ handbook, and so on.
-
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 muscle memory from having learned Linux/BSD in the mid 90s. Web search wasn’t nearly as effective then, so there wasn’t much choice.
That it has worked well enough and doesn’t require context switching to a browser is probably why I still prefer it today.
-
i think part of the reason I'm feeling interested in man pages right now even though I rarely use them is that search has gotten so much worse, it's frustrating, and it makes it feel more appealing to have trustworthy sources with clear explanations
also it just occurred to me that the one time I wrote a command line tool (https://rbspy.github.io/) I didn't write a man page for it, I made a documentation website instead. I don't remember even considering writing a man page, probably because I rarely use man pages
(not looking to argue about whether command line tools "should" have man pages or not, just reflecting about how maybe I personally would prefer a good docs website over a man page. Also please no "webpages require internet")
-
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 I personally found that doing a complete read of the manpage of a new tool gives me a fairly good idea of what sort of problem the authors wanted to solve, even if I don't recall specific parameters later. Also whenever i run into a weird command somewhere, I look up what all the flags do, both to understand the subtleties and to "prime the cache", so to speak.
Also-also, at least on Debian, a _lot_ of things have manpages, like file formats or some helper scripts. And they have neat references to one another at the end. It's basically a proto-web.
-
@b0rk The Unix User's/Programmer's Manual is the *reference* documentation, but was never intended to provide introductory guides or conceptual overviews — as originally distributed those were separate documents. The man page should tell you how to do the thing when you already know what you want and that there's a command/function to do it, and you just need the invocation details. Unfortunately the higher level conceptual documentation has fallen by the wayside.
@b0rk The broadening of the programming environment has also taken its toll. The manual covers C and shell programming, but a lot of work today is in different language environments that have their own documentation, some good and some bad. Even in the standard utilities, something like awk or sed is very difficult to learn from the reference manual. Perl at least was always good at making manual pages for every installed package, but they depend on authors to get the information structure down.
-
also it just occurred to me that the one time I wrote a command line tool (https://rbspy.github.io/) I didn't write a man page for it, I made a documentation website instead. I don't remember even considering writing a man page, probably because I rarely use man pages
(not looking to argue about whether command line tools "should" have man pages or not, just reflecting about how maybe I personally would prefer a good docs website over a man page. Also please no "webpages require internet")
@b0rk there's also the aspect that man pages are stored on my system when the tool is installed, whereas websites inevitably disappear over time and can be temporarily inaccessible for any number of reasons
-
also it just occurred to me that the one time I wrote a command line tool (https://rbspy.github.io/) I didn't write a man page for it, I made a documentation website instead. I don't remember even considering writing a man page, probably because I rarely use man pages
(not looking to argue about whether command line tools "should" have man pages or not, just reflecting about how maybe I personally would prefer a good docs website over a man page. Also please no "webpages require internet")
@b0rk i've begun to feel more strongly that i need manual pages for everything, and good ones at that. the problem is manpages are stupidly hard to write, and duplicate a lot of stuff from --help. i always solve this by converting from markdown, and generally failing at DRY
-
@b0rk The broadening of the programming environment has also taken its toll. The manual covers C and shell programming, but a lot of work today is in different language environments that have their own documentation, some good and some bad. Even in the standard utilities, something like awk or sed is very difficult to learn from the reference manual. Perl at least was always good at making manual pages for every installed package, but they depend on authors to get the information structure down.
@wollman this all makes a lot of sense to me, personally I've never been a C programmer and so the classic "unix reference manual" style always feels like a bit of an alien life form and like it came from a different time.
-
also it just occurred to me that the one time I wrote a command line tool (https://rbspy.github.io/) I didn't write a man page for it, I made a documentation website instead. I don't remember even considering writing a man page, probably because I rarely use man pages
(not looking to argue about whether command line tools "should" have man pages or not, just reflecting about how maybe I personally would prefer a good docs website over a man page. Also please no "webpages require internet")
@b0rk I suppose that adding a man page requires extra hurdles of not just creating the man page itself, but packaging your tool such that the man page gets installed along with it. Now you have to make a .deb and and .apt and whatever else, instead of just saying "download this script or executable and run it."
-
@karabaic I've never used openbsd but I'm so curious about the openbsd man page culture because of how people talk about it
do you know if there's anywhere that I can read about the documentation philosophy or about how people relate to it?
@b0rk The FAQ on posting to the openbsd.misc group is a good place to start. after reading man intro. I'd then check the contribution standards on the project.
It's considered incomplete to try to check in code with user-visible functionality that's not explained in the accompanying man page so it can be tested with by reading that page.
-
also it just occurred to me that the one time I wrote a command line tool (https://rbspy.github.io/) I didn't write a man page for it, I made a documentation website instead. I don't remember even considering writing a man page, probably because I rarely use man pages
(not looking to argue about whether command line tools "should" have man pages or not, just reflecting about how maybe I personally would prefer a good docs website over a man page. Also please no "webpages require internet")
@b0rk I've written a few command line tools over the years that launch a web broswer to display stuff.
I'll keep the idea of having a docs subcommand spawn a local web server and broswer to view guides, could be useful.
-
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 The man page is closer to the source of information, rather than some random website one found via web search. Plus, given differences between OSs/distro releases, how do you know what you get from a web search matches up with what you have actually installed?
-
@b0rk there's also the aspect that man pages are stored on my system when the tool is installed, whereas websites inevitably disappear over time and can be temporarily inaccessible for any number of reasons
@b0rk do we need a --help that starts a local web server hosting a doc page which is way easier to read and navigate than a man page? 🤔
-
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")I always go to --help first to get an idea of what my options are or to scope my question better, then I can search for examples using whatever option vs searching "how to X" if that makes sense
-
@b0rk I suppose that adding a man page requires extra hurdles of not just creating the man page itself, but packaging your tool such that the man page gets installed along with it. Now you have to make a .deb and and .apt and whatever else, instead of just saying "download this script or executable and run it."
@tartley yea I'm not sure if anyone's ever packaged rbspy for Debian because (at least at the time) packaging Rust projects for Debian was hard or maybe impossible