TLDR pages: Simplified, community-driven man pages
11–20 of 179 posts
Re: TLDR pages: Simplified, community-driven man pages
#12Typical man pages are well, like learning a language by studying a dictionary, alphabetically. It may contain all information, but a clear F on UX. Some packages get slightly better with starting from the most common use cases, with examples (and digestible errors).
However, I would be even more interested to see what is the actual usage pattern (e.g. from .bash_history / .zsh_history). Do you know any datasets with longer such?
Re: TLDR pages: Simplified, community-driven man pages
#13Re: TLDR pages: Simplified, community-driven man pages
#14Re: TLDR pages: Simplified, community-driven man pages
#15FWIW, can be installed on macOS with brew: brew install tldr EDIT to add: and so can the faster (caching) Rust version (note: install one or the other, not both, since they use the same `tldr` command) brew install tealdeer
Re: TLDR pages: Simplified, community-driven man pages
#16I would be happy to see such a thing taking off. Typical man pages are well, like learning a language by studying a dictionary, alphabetically. It may contain all information, but a clear F on UX. Some packages get slightly better with starting from the most common use cases, with examples (and digestible errors). However, I would be even more interested to see what is the actual usage pattern (e.g. from .bash_histor…
Re: TLDR pages: Simplified, community-driven man pages
#17Re: TLDR pages: Simplified, community-driven man pages
#18 curl cht.sh/trRe: TLDR pages: Simplified, community-driven man pages
#19I would be happy to see such a thing taking off. Typical man pages are well, like learning a language by studying a dictionary, alphabetically. It may contain all information, but a clear F on UX. Some packages get slightly better with starting from the most common use cases, with examples (and digestible errors). However, I would be even more interested to see what is the actual usage pattern (e.g. from .bash_histor…
tldr caters to an entirely different heuristic: I have this use case, give me a list of use cases and the corresponding combination of switches, options and arguments for each respective use case. tldr won't explain to you what each individual switch, option or argument does, turning the provided commands into black boxes.
Here's the trade off:
The former has a steep learning curve and figuring out how a tool works doesn't solve your immediate problem. But if you commit the meaning of switches, options and arguments for common tools such as awk, sed, tar, ls,... to memory, you will become proficient at solving any problem with a few tools over time.
The latter has a low learning curve and you just have to copy/paste a command to solve your problem. But tldr won't tell you how those switches and options work. And you will just use them as incantations that magically help you to solve a limited number of cases. If you end up with a use case that isn't listed, you are left in the dark as far as tldr is concerned.
So, is tldr a bad tool then? No! If you are confronted with the command line sparingly, then tldr helps to lower the bar and solve your immediate problem. But if you hope to grow into a proficient shell user, then you're still going to have to grok the man pages one switch, option and argument at a time.
I'm a polyglot. Studying a language by opening a dictionary and starting alphabetically, is arguably, the worst way to get there. You would start with learning a set of common words and basic grammatical rules, and then expand over time through practice and instruction: speaking, reading and writing.
The same applies to command line tools and man pages: they are reference materials first and foremost.
Re: TLDR pages: Simplified, community-driven man pages
#20Earlier quoted context omitted.
tldr has a better name.
Having skimmed the endless discussion about the "bro" name, I have to agree.