when do you usually use the man page for a complex command line tool to answer a question you have?
Uncategorized
272
Posts
207
Posters
0
Views
-
@fanf @tartley @b0rk TIL that Git's -h and --help do different things. What an unfortunate UI though :( It goes completely against the principle of long options and the established behavior of -h/--help in every other CLI tool, and even the git(1) man page claims that -h and --help are identical??
Very useful to know though. Previously, I used tricks like "git remote blarg" to get the short help, and was a little confused/surprised that there was no better way to see the short help text.
-
@fanf @tartley @b0rk TIL that Git's -h and --help do different things. What an unfortunate UI though :( It goes completely against the principle of long options and the established behavior of -h/--help in every other CLI tool, and even the git(1) man page claims that -h and --help are identical??
Very useful to know though. Previously, I used tricks like "git remote blarg" to get the short help, and was a little confused/surprised that there was no better way to see the short help text.
@fanf @tartley @b0rk Oh, it's actually even worse! `git remote -h` shows the short help, but `git -h remote` outputs the man page.
`git remote --help`, `git --help remote`, and `git help remote` also all show the man page. So the specific spelling `git <command> -h` seems to be a special case. This is extremely unhelpful behavior for an option that's meant to be used when you don't know how to use a program... :(
-
@simontatham yea i think part of the reason I'm newly interested in man pages right now is that search engines are so much worse than they used to be
@b0rk@social.jvns.ca @simontatham@hachyderm.io another aspect: the man page on your machine matches the software on your machine
the online docs are probably for the very latest version, which is probably not the one you're running
(I used to make this argument on IRC channels a couple of decades ago… so yes to the "old people" aspect, too) -
@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.
@simontatham @b0rk yes this - I’m old enough to remember man pages that were actually printed out in A4 ring binders. They do have the advantage of not needing to wade through a dozen HowTo articles that answer the most basic usage to find documentation that actually covers the options you actually need.
-
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 generally yes but there are exceptions. Looking up what a specific argument does is fine in 100% of the cases, but rsync and sudoers are the two examples that come to mind when it comes to obnoxiously inscrutable structure, if you came to the man page to learn how to use the thing specific way.
-
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 Not sure why, since I always look online for LaTeX documentation.
Possibly that was just how I was taught in the early 2000s when I first tried Linux? Possibly just it is RIGHT THERE and I don't need to open a browser or anything
-
@b0rk@social.jvns.ca @simontatham@hachyderm.io another aspect: the man page on your machine matches the software on your machine
the online docs are probably for the very latest version, which is probably not the one you're running
(I used to make this argument on IRC channels a couple of decades ago… so yes to the "old people" aspect, too)@dakkar @b0rk @simontatham Another problem with Googling the answer is that most of the content it finds is for Ubuntu, and I don't have Ubuntu.
-
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'm not sure how I choose, I _think_ I use man page first if I need just a specific detail like the name of an option I know is there. If I'm not sure of what I'm looking for, I go to Google. Man pages usually are not very good in introducing/explaining use cases, so not a good starting point, but for a specific detail, they tend to be predictably usable. -
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 Voted "other" as it depends highly on the context for me? Like, what tool, what kind of system am I running on, and so forth.
-
@simontatham yea i think part of the reason I'm newly interested in man pages right now is that search engines are so much worse than they used to be
@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.
-
@b0rk
It used to be --help, and I sometimes still use it (but frustrated from browsers etc. that don't comply to the convention) - no need to state that, but I found something more interesting:
Many tools come with bash completion when installed through a package manager.
So the first thing I really try nowadays is:
- type a few promising characters
- hit TAB
- if unsuccessful, delete some, type some new.
If this won't work, I might try the man page - or a google search, it depends.@b0rk
Now that I read your second question, I must also mention "tldr".
It often has a useful selection of those use cases that most users only ever use. If I want to something more advanced I have to research it somewhere else, anyway. -
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 man is my go-to tool when I sorta already know what I'm trying to do but can't quite remember what the arguments look like
-
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 So, this is a conditionalized problem, my P(man page first | man page exists) is high – because if it's a new tool, and it has a man page, usually the man page is *actually quite good*, and actually fulfills the role of "manual" better than most (say, GNU coreutils) manpages, which just are slightly more in-depth versions of `tool --help` (without the actual structural difference that would make them manuals, as opposed to CLI option references).
Lots of tools don't ship with manpages… -
@b0rk So, this is a conditionalized problem, my P(man page first | man page exists) is high – because if it's a new tool, and it has a man page, usually the man page is *actually quite good*, and actually fulfills the role of "manual" better than most (say, GNU coreutils) manpages, which just are slightly more in-depth versions of `tool --help` (without the actual structural difference that would make them manuals, as opposed to CLI option references).
Lots of tools don't ship with manpages…@b0rk … anymore (`man mlr` doesn't work, `mlr --help` directly links to its docs website). And for more complex tools, that's probably fair – you're not going to learn how to use a massive tool from man pages (examples of "this should not be one man page" is `man gcc`,`man bash, `fish-doc`, `libuv` or `man mplayer`), but for smaller things, authors who sit down to write a man page for modern tools typically actually *think* about what is a sensible thing to put in that format.
-
@b0rk … anymore (`man mlr` doesn't work, `mlr --help` directly links to its docs website). And for more complex tools, that's probably fair – you're not going to learn how to use a massive tool from man pages (examples of "this should not be one man page" is `man gcc`,`man bash, `fish-doc`, `libuv` or `man mplayer`), but for smaller things, authors who sit down to write a man page for modern tools typically actually *think* about what is a sensible thing to put in that format.
@b0rk In fact, that's been so often the case for me that I tend to think "OK, for 5 minutes of reading instead of 30 s of searching, I can actually learn how this generally works, is that worth 4min 30s? yes!" and then read the man page.
-
@b0rk In fact, that's been so often the case for me that I tend to think "OK, for 5 minutes of reading instead of 30 s of searching, I can actually learn how this generally works, is that worth 4min 30s? yes!" and then read the man page.
@b0rk (Neither "not changing context" nor "same version" are good arguments, imho. I *want* to have the documentation in a different thing than the terminal I'm currently working in. What use is modern screens else. Tools rarely change so rapidly that the things I need to learn to get started would immediately outdate, and if they do, it's usually a good sign for that tool being pretty specialized and me probably needing to read more)
-
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 --help output, but I've never known how to write a man page.
-
@aburka that's what fish does! Well it just opens the HTML file in the browser, no need to start a local web server for those docs
-
@b0rk the mentioned utilities, mostly man page. ffmpeg? Straight to search.
@danlyke @b0rk FFmpeg options and arguments are a language in their own right. Knowledge about video formats is more trade knowledge than conceptual knowledge, and I've always had difficulty getting motivated to study that kind of stuff, so I look to the web for information about how to use ffmpeg, and yeah, I use it as cargo cult code. I bookmark them under "ffmpeg-recipes".
-
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 "That depends..." Isn't a great answer, but that's the case. Reference for command line options? Man page first. Example usage and reference applications? Google search, AI tools. Project website first, man page examples after. Except if it's a bash question, then man page first.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
and followed @team@protocolsforpublishers.com
-
😅 subscribed!
-
-
@miles
Io pensavo che significasse Arancia, Carota Ellimone 🤣
-
D21
non è facile capire come si salva la democrazia
gli esperti non possono dire di saperloqui ci sono considerazioni che consigliano di evitare di lasciare campo libero alla tecnocrazia
https://piudemocraziaintrentino.org/2026/02/12/quo-vadis-democrazia-cronaca-di-un-confronto-necessario-a-roma/
-
ACE (Arbitrary Code Execution) on an ace (asexual) robotgirl
-
Il ghiaccio di Milano.
https://www.ilpost.it/2026/02/21/indagini-omicidio-rogoredo-milano-polizia/
-
"The protocol [ATProto] doesn't distribute value across the network. It concentrates it. Developers are building features on top of Bluesky's infrastructure for free, making it more indispensable with every app that ships.
And Bluesky gets to claim the moral high ground the whole time. "We're open! We're decentralized! You can leave whenever you want!" Meanwhile, the switching cost goes up every day.
Email is an open, federated protocol. Anyone can run a mail server. In practice, running your own mail server is painful and everyone just uses Gmail. The protocol being "open" didn't prevent centralization.
ATProto might be worse. [...] The open protocol is actually a centralization flywheel."
