I don’t think length is necessarily the problem. Personally I find curl(1) (and bash(1), a similarly long man page) to be very legible; but it helps to have internalised some rules for jumping to particular sub-sections.
I very rarely use curl, so have never internalised their commands, it every time I use it I am able to quickly find what I want the answer in the man page for what I want to do with a quick search for a relevant term.
It sounds like you’re looking for a more introductory or tutorial style of documentation? If that’s the case, that’s totally fair. Man pages are great as a reference, but awful as a way of learning something from the ground up.
This is something many more projects need to take seriously. I am glad Daniel is doing this now, while he has no plans of leaving, and I hope others follow his lead.
Thank you, Daniel. You’re a load bearing member of society.
I read the article as being about how he doesn’t want to be load-bearing and the steps he’s taking to avoid it.
Agree, and those steps are also load-bearing. Very responsible the whole way around.
While libcurl(3) is well-documented, I find curl(1)’s documentation to be a huge dump of detail and difficult to read:
I don’t think length is necessarily the problem. Personally I find
curl(1)(andbash(1), a similarly long man page) to be very legible; but it helps to have internalised some rules for jumping to particular sub-sections.I very rarely use curl, so have never internalised their commands, it every time I use it I am able to quickly find what I want the answer in the man page for what I want to do with a quick search for a relevant term.
It sounds like you’re looking for a more introductory or tutorial style of documentation? If that’s the case, that’s totally fair. Man pages are great as a reference, but awful as a way of learning something from the ground up.
This is something many more projects need to take seriously. I am glad Daniel is doing this now, while he has no plans of leaving, and I hope others follow his lead.