Maybe 30 years ago you could learn through manpages but today that's how all the man pages of all the useful commands look. If you think grep is nice it would be the exception; for me it is indeed short, simple and easily searchable, but too terse for a beginner to learn with easily. (Plus even the regex documentation only documents grep mode, not egrep or pgrep or anything else.) Very useful in its own way, but most man pages are useless for learning.
I am disappointed at how few man pages take the opportunity to have a useful selection of "the 10 most popular things to do with this command" but web search has filled in reasonably decently. You do still have to understand the basics of how shell works, though, because most of them aren't quite what you want today and honestly a fair number of them aren't even what the poster thought they were. I am also in the habit of making sure that I understand every command line switch before I copy & paste a command off the internet, again, because many of them aren't what you need today. I don't always mean in a malicious manner, but things like either do or do not follow HTTP redirects in curl may or may not matter to you today, but the poster may be in the habit of setting it one way or another for no reason relevant to you.
there are not enough of them now, they used to be more prevalent
StackOverflow is Internet Age help
ChatGPT is post-Internet Age help
In ascending order of helpfulness (modulo LLM confabulation)
ChatGPT inherited "confidently wrong" and "misunderstanding question and then answering to question they misunderstood" from stackoverflow
Actually, this seems to be a case where chatgpt is smarter than the humans.
As of now, there is no LLM without confabulation, so your third item is effectively "hypothetical fantasy ChatGPT that we hope will be available some time in the future", not the actual tools we have right now.
The resulting command looked good at first sight, something like „mkvmerge -o output.mkv first.mkv —-no—video -s 1 -a 2 -a 3 -a 4“. The problem here is that there can only be one -a flag, so it should have been „-a 2,3,4“ instead. But mkvmerge didn’t really care and just discarded every -a flag except the last one. So I ended up with only one of the audio tracks copied over. I only noticed when I actually checked the resulting file that it had less audio tracks than it was supposed to.
This would not have happened to a human after studying the man page - the documentation is very clear about the -a flag and I have no idea what led ChatGPT to come to the conclusion it did.
Learning to program for example Perl. I had the learning book, the reference book and the cookbook. learning I did once, the reference had post its on it and was on my work desk. The cookbook was more the facebook type you read it on the toilet.
They had books on everything that were the industry standard. DNS, Apache, Javascript, ... The revised them regularly. For Js had the 1st, 2nd, 3rd edition. I know this sounds all ancients like real paper books. But even work had O'reilly subscription so you could order what you need.
For me it was O'reilly books, man pages. But lets not forget when you installed Linux like RedHat (not fedora yet) you could install the linux howtos. Oh boy did I learn a lot from them too: https://tldp.org/HOWTO/HOWTO-INDEX/howtos.html
Finally there was IRC if you were stuck but this was off course the internet stage. I just went online to ask a question, dialup was expensive ;)
i've been using https://git.causal.agency/exman/about/ to compare linux and bsd manpages, and it has saved me an incredible amount of time looking things up.
Ironically, this sort of stuff -- the basic conventions like qhjkl0^$G + CRFFBSSPC keyboard navigation and :/? prompt modes -- is exactly what one initially learns from guides, tutorials, other people in IRC, and whatnot, long before coming to reference doco. The _Introduction to Linux_ book at TLDP covers the bare essentials of these conventions, q, b, and SPC, in the "quickstart" chapter 2.
For emacs stuff, yes, it's very convenient. I remember once upon a time, Python docs were available in info as well. When you have good documentation available in info, it's very nice.
While this attitude made sense pre-internet, reading about every switch for common use cases is just not realistic today. Maybe if the number of command-line programs were less, and the complexity of each command was significantly less, I could see how it would be done, but not today.
This means not only how regexes distinguish between literals and control characters, but how the shell distinguishes and passes on characters to the regex that grep receives as an argument.
I think regex quoting is one of the major stumbling blocks of comprehension.
Even after decades using regexes, I still stumble (especially when my regexes are used in the shell, in emacs, in python re.match, etc...)
I suspect that the author is right that most people started with guides/handbooks/tutorials, even the ones who later on convince themselves that they only read reference doco.
The grep manpage spends much explaining regex and environment variables, find more on options.
Both manpages are searchable, what makes the grep manpage more searchable?
https://www.gnu.org/software/findutils/manual/html_mono/find...
info some-tool
some-tool --help
just help me dammit some-tool
I've got a thousand things to do that are better uses of my time than reading 20 pages of arcane documentation that may or may not answer my question.
Manpages aren't all the same quality. Look at the manpage for util-linux find(1):
* https://manpages.debian.org/bullseye/findutils/find.1.en.htm...
Contrast with the manpage for NetBSD find(1), where something similar to what you mention is in fact the very first example in the EXAMPLES section:
* https://man.netbsd.org/find.1
Compare with the manpage for Illumos find(1), where like util-linux it leaps into -exec and expressions in brackets with the second example:
* https://illumos.org/man/1/find
Then remember that some operating systems come with handbooks and guides, and if one wants a tutorial for beginners, reference doco is not the place to start at all. So next contrast with the SCO UnixWare users guide, which also starts off with find file by name and print:
* http://uw714doc.xinuos.com/en/FD_files/Moving_and_managing_f...
Then remember that GNU has a long-standing antipathy to man pages, and that actually one should have magically known the name "findutils":
* https://www.gnu.org/software/findutils/manual/html_node/find...
And there's also this thing that someone decided to call The Linux Documentation Project which has a book titled _Introduction to Linux_:
* https://tldp.org/LDP/intro-linux/html/sect_03_03.html#sect_0...
The NetBSD examples also only document what command do, while the util-linux sometimes go into details of why, like when describing how exactly the time directive works and why `-mtime 0` shows files from last 24 hours.
"file hierarchy" - Something to do with my file organization?
"walk" - Most programmers are familiar with trees.
Oh, we are walking through the file tree!
EXAMPLES
Examples are critical to comprehension, are immensely practical, yet are often viewed as fluff.
The same style extends to library documentation, where you have functions and arguments with types and no other context. It's basically for posterity.
Right balance of exact operation of software and examples, put in order that's useful in normal usage, and explanation for the more complex parts
InFILE In*
fopen(Inconst Inchar In* Inrestrict Inpath, Inconst Inchar In* Inrestrict Inmode);
FILE *fopen(const char *, const char *mode);
I learned a lot from man pages in the 80's and 90's, and if I had to try to learn now from something like this, I'd likely just throw up my hands and choose another career.
.I is the "an" macro for italics, after all.
* https://tty0.social/@JdeBP/110427220635184435
It even prettifies those ``'' quotes, notice. This is vanilla older FreeBSD man, using groff, but actually allowing groff to do the things that it is capable of.
What terminal are you using? I just tested on Terminal.app and iTerm2.app -- `man fopen` looks correct on both.
TERM=xterm-256color and LESS_TERMCAP_us=In
you've got some typos here, it's not mentioned because... that's not how find works.
find has no -i like grep ; to ignorecase you use -iname ; and for name regular expression matching you need to use
find . -iregex <regex> # (or -regex)
find . -iname <pattern> # (uses wildcards ? \*)
> Commands are listed alphabetically so that they can be quickly located. However, new users may find it easier to start by reading the descriptions of spawn, send, expect, and interact, in that order.
An enormous page full of switches and options, yet if you're a beginner it's basically useless. You're just looking for a simple example of how to search for a file. find . -i -name <regex> is NOT mentioned anywhere, you have to figure it out yourself. And if you mess it up, your terminal gets flooded.
Contrast with grep(1) https://linux.die.net/man/1/grep which is short, simple, and easily searchable with keywords
Manpages are very useful, having offline documentation is great. But it is more of a specification reference than a manual.