[HN Gopher] I didn't learn Unix by reading all the manpages (2022)
___________________________________________________________________
I didn't learn Unix by reading all the manpages (2022)
Author : goranmoomin
Score : 68 points
Date : 2023-05-24 16:04 UTC (6 hours ago)
(HTM) web link (www.owlfolio.org)
(TXT) w3m dump (www.owlfolio.org)
| mickeyp wrote:
| Man pages are generally not always that great. I recommend people
| instead digest the GNU `info' manuals, as you'll come away with a
| much deeper understanding of all the userspace binaries you're
| likely to interact with on many common Linux systems today.
|
| I'll make this iron clad promise: if you sit down and read the
| coreutils manual end-to-end (it'll take a couple of hours) you'll
| come away brimming with new ways to optimise your CLI workflow.
|
| If you're allergic to the `info' program itself, you can of
| course read the manuals on GNU's website or, better still: use
| Emacs's info viewer (`C-h i' or M-x info), which is far superior.
| tpoacher wrote:
| Info has some really crap defaults. I invested some time to
| make a nice custom config and now I wish more things had info
| pages, because they're a joy to read.
| 13of40 wrote:
| I've always found reference books a lot easier to get my head
| around than instructional textbooks. One of my favorite finds as
| a kid was a book about the Apple II that covered topics like the
| memory map and hardware registers, and my least favorite format
| was the 300-page book where you start with writing "Hello World"
| and twenty chapters in you're following instructions on how to
| schedule asynchronous messages or something. I don't think I've
| ever gotten past chapter three in a book like that, and I've had
| a reasonably successful, decades-long career in development.
| jbaber wrote:
| Honestly manpages with and without an `EXAMPLES` section are
| completely different types of documents.
| [deleted]
| [deleted]
| valbaca wrote:
| I start with tldr then move into help or manpages as necessary.
| Then when I understand, I still come back to tldr to remember.
|
| https://tldr.sh/
|
| in browser: https://tldr.inbrowser.app/
| the-alchemist wrote:
| Tangential, but can someone explain the dichotomy of man pages vs
| info pages? Are they competitors, complements? Seems like many
| tools, like find, have sections for both.
|
| Seems like man pages get all the love. Google searches often
| result in man page results, but not info pages.
|
| Can someone educate me? Thank you :)
| bombcar wrote:
| GNU tried to push everything to info pages (a simple hyperlink
| browser) and it backfired spectacularly. Because man was
| simple, info was confusing and complicated and annoying.
| raspyberr wrote:
| Something I don't understand. Everyone talks about how they wish
| man pages had examples. What's stopping people from
| making/copying some examples and making a pull request to the
| maintainers of the man pages?
| xboxnolifes wrote:
| The people asking for examples aren't exactly in the position
| to be suggesting good examples.
| smackeyacky wrote:
| The correct order of learning Unix commands is: get a copy of
| Kernihan/Pike[0] and read that, do the examples.
|
| Then the man pages make more sense.
|
| [0]https://en.wikipedia.org/wiki/The_Unix_Programming_Environme..
| .
| LordShredda wrote:
| Manpages aren't all the same quality. Look at the manpage for
| find(1) https://linux.die.net/man/1/find
|
| 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.
| jbverschoor wrote:
| I learned Unix by reading the FreeBSD handbook.
| msravi wrote:
| I've found tldr (https://tldr.sh/) very useful for quick
| lookups - basically gives examples with short descriptions,
| which is very often mostly what's needed.
| epiccoleman wrote:
| My favorite is cheat.sh, which is a similar thing to tldr,
| but the best part about cheat is that you can just `curl
| cheat.sh/ln` (or whatever command) and get the cheat sheet on
| any system. I use this _all the time_.
| mjw1007 wrote:
| That's because find's principal documentation is in info.
|
| https://www.gnu.org/software/findutils/manual/html_mono/find...
| jonnycomputer wrote:
| And that points to another problem.
| m463 wrote:
| I disagree - the find manpage is significantly better than the
| grep manpage because of one aspect:
|
| EXAMPLES
|
| Examples are critical to comprehension, are immensely
| practical, yet are often viewed as fluff.
| jerf wrote:
| "An enormous page full of switches and options, yet if you're a
| beginner it's basically useless."
|
| 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.
| markus_zhang wrote:
| Yeah man! Scenarios! Those documentations rarely bother with
| scenarios, which is all newbies need!
| robohoe wrote:
| tealdear and tldr seems to do "top 10 most useful things you
| can do with this command"
| shrimp_emoji wrote:
| Man pages are pre-Internet Age help
|
| StackOverflow is Internet Age help
|
| ChatGPT is post-Internet Age help
|
| In ascending order of helpfulness (modulo LLM confabulation)
| bombcar wrote:
| ChatGPT will not be able to hallucinate options to find and
| grep and ls because they all use every single letter of the
| alphabet.
| ilyt wrote:
| And in descending order of correctness.
|
| ChatGPT inherited "confidently wrong" and "misunderstanding
| question and then answering to question they misunderstood"
| from stackoverflow
| xg15 wrote:
| > _(modulo LLM confabulation)_
|
| 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.
| libele wrote:
| the openbsd manuals usually have examples. you can see how
| compact https://man.openbsd.org/grep.1 is compared to the gnu
| grep manual.
|
| 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.
| paulddraper wrote:
| grep's prerequisite is to understand regexes.
| m463 wrote:
| This goes deeper, since understanding grep regexes involves
| understanding quoting.
|
| 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...)
| yoyohello13 wrote:
| One thing I love about the Sway Window Manager is how awesome
| the man pages are. They are clearly written and contain great
| examples.
| nvy wrote:
| find(1) is a classic example. The first two or three pages are
| of essentially zero practical use. I open the manual, skim the
| first page, no obvious clues about how to actually use `find`,
| so my next step is always to go to web search.
|
| 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.
| meinersbur wrote:
| Do you mean the other way around? The manpage of find contains
| examples, including searching for files by name. This alone
| make the manpage somewhat usable for beginners. The grep
| manpage does not have any examples.
|
| 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?
| JdeBP wrote:
| Or:
|
| 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...
| ilyt wrote:
| NetBSD doesn't look all that more helpful, you just get to
| examples sooner because it has far less options
|
| 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.
| ilyt wrote:
| Software documentation is an art.
|
| 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
| tzhenghao wrote:
| I've used tldr (https://github.com/tldr-pages/tldr) if I'm a
| beginner to a specific tool, then read up the manpages and/or SO
| if I need more flags.
| photochemsyn wrote:
| Here's how people will learn Unix from here on out - they'll ask
| the chatbot to teach it to them:
|
| Q "Please provide an outline and course syllabus for a ten-week
| course on Unix, aimed at undergraduate students in a college-
| level computer science program, as taught by an expert in Unix
| operating systems who has comprehensive historical knowledge of
| their development."
|
| E.g. > "Week 4: Process Control; Process creation and
| termination; Process states and signals; Job control and
| background processes"
|
| Need more? Q: "What are the most popular and useful process
| management tools for a Unix operating system?"
|
| As far as how to read the man pages for any command, for
| beginners:
|
| Q: "Provide a synopsis of the ps command's man page in a format
| suitable for a student who is just beginning to learn about
| process management."
|
| Yes, you still should double-check those commands against the man
| reference - but think of all the benefits - students can get
| answers to their questions without having to pay private tutors
| or run the gauntlet of online forums where their ignorance will
| result in ridicule and similar unhelpful behavior, e.g. 'just
| read the man pages and think about it!', and they can ask as many
| dumb questions as they need to to figure things out, with no fear
| of embarrassment or humiliation (as long as the ChatGPT logs
| don't get leaked, I guess...)
| mkl95 wrote:
| I would have a hard time believing someone who learnt Unix at
| some point in the previous 20 years did so by reading some
| manpages.
| ilyt wrote:
| I remember how many distros come with a package of Linux HOWTOS
| about varios topics, I did learn a lot from those
| richardjam73 wrote:
| The Linux Documentation Project https://tldp.org/
|
| Is where those came from it started circa 1992.
| leed25d wrote:
| I remember when you could print out all of the manpages and put
| them in a 3-ring notebook. Yes, in those days I did read them
| all.
| koolba wrote:
| But how could you have done that before you read the man page
| for lpr?
| TehCorwiz wrote:
| Call the nearest grey-beard.
| pndy wrote:
| Admin the Grey?
| aksss wrote:
| Man-dolf the Grey
| jdbernard wrote:
| I agree with the author's broader point about being more open to
| alternative paths into UNIX/hackery/etc. However, I'm not sure
| that I agree entirely with this statement at the end:
|
| > I'm pretty confident that someone who practices programming
| strictly as a hobby, less than ten hours a week, will eventually
| get just as good at it as one of these "fledgling hackers" who
| doesn't do anything else with their spare time.
|
| I'm not sure. Maybe, if the fledgling hacker isn't able to use
| their time effectively and the hobbyist is. But that assumes that
| very thing the author discussed in the beginning: the hobbyist
| has some prior foundational experience that allows them to be
| more effective with their time than the fledgling.
|
| In my experience if you want to excel in any discipline, you have
| to spend some time at some point deeply-focused on it. If we
| assume the path to mastery is linear, 10 hrs/week for 10 years
| (~5000 hours) leaves less time for mastery than 60 hrs/week for 2
| years (~6000 hours). In my experience mastery is not linear and
| makes this calculus even worse for the casual learner. Learnings
| compound and not all hours of practice are equal in efficacy. The
| more experience practitioner is likely to be getting more out of
| the time that they spend.
|
| I do believe, emphatically, in the value of consistent effort
| over time. I've spent a few years picking up piano, but its 4
| hrs/week. My goal with piano is to "be good in 10 years." But
| still, this to me highlights the gap between casual progress and
| dedicated effort. One of the main reasons I feel like I'm able to
| actually make progress with only 4 hr/week is because I have the
| prior experience of reaching a fairly high level of proficiency
| playing bass after 20+ years. There were times earlier in my
| musical study where I spent 30+hrs/week with the bass and built a
| foundation of musical knowledge and discipline that allows me to
| be more effective with a lesser time investment on piano now.
| Even with that prior foundation I don't expect that with 10 years
| of 4 hrs/week effort that I will be comparable in skill or
| knowledge to a professional pianist.
|
| I think, based on my experience, that immersing yourself in a
| subject and making it a major pursuit in your life, taking up a
| large portion of your waking hours, is qualitatively different
| than the same amount of time invested over a longer horizon. You
| make connections faster when the study is top-of-mind. You notice
| patterns and build up intuitions that you miss when it's more
| spread out. The path of learning is extremely non-linear, in my
| experience. Slow and steady is effective, but let's not kid
| ourselves. If it is sustained, fast and steady is more effective.
| sergiotapia wrote:
| What I don't understand is why don't manpages have clear example
| of common usages? I imagine there's many many people that want to
| contribute that to the manpages, are they not there because
| leadership doesn't allow them for some reason?
|
| Take grep for example
| https://linuxcommand.org/lc3_man_pages/grep1.html - it has
| everything and the kitchen sink but hell bro tell me how to find
| something is the 99% use case most people will use it.
|
| For cases like this ChatGPT has been helpful.
| JdeBP wrote:
| They do have. You're just looking at the manual from one
| particular source of utilities, GNU, and overgeneralizing.
| Aside from the well-known antipathy to man pages, with every
| GNU manual page telling you at its foot to go and use a
| different tool to read a different doco format, it is not
| representative of manual pages in general.
|
| The Illumos manual page for grep(1) has an examples section:
|
| * https://illumos.org/man/1/grep#examples
|
| So has the FreeBSD manual page for grep(1):
|
| *
| https://man.freebsd.org/cgi/man.cgi?query=grep&sektion=1#EXA...
|
| Not everything is written like GNU man(1) pages.
|
| Even the Linux Documentation Project has a novice's approach to
| grep with several basic examples in its _Introduction To
| Linux_:
|
| * https://tldp.org/LDP/intro-
| linux/html/sect_03_03.html#sect_0...
| sergiotapia wrote:
| Interesting, I thought grep was grep and period. I didn't
| realize every Linux had their own version of grep with their
| own man pages.
|
| Is this like a youtube-dl / ytp-dl situation?
| markus_zhang wrote:
| From my experience most manuals actually don't have scenarios.
| Is git or docker better? I need to check and see, but from
| memory their manual pages mostly list all switches but a couple
| of examples at best. I could be wrong and need to double check.
| [deleted]
| [deleted]
| jacooper wrote:
| Ai chatbots are perfect for this
| tomwheeler wrote:
| I also didn't learn Unix this way, but I sure learned a lot more
| once I did.
| tomwheeler wrote:
| In addition to being informative, they're also sometimes funny.
| I remember that the HP/UX tunefs man page said, "You can tune a
| filesystem, but you can't tune a fish."
| jasomill wrote:
| The inability to tune a fish was first documented in the
| original 4.2BSD man page for tunefs(8),
|
| https://www.tuhs.org/cgi-
| bin/utree.pl?file=4.2BSD/usr/man/ma...
|
| and is still present in most BSD-derived tunefs
| implementations, e.g.,
|
| https://man.freebsd.org/cgi/man.cgi?query=tunefs&apropos=0&s.
| ..
|
| AFAICT, this restriction does not apply to versions of tunefs
| provided by System V and its derivatives, e.g.,
|
| https://docs.oracle.com/cd/E86824_01/html/E54764/tunefs-1m.h.
| ..
|
| As with many things in UNIX, the ability to tune a fish is
| implementation-dependent, and testing is recommended before
| using it in production on any given platform.
| pierrebai wrote:
| I learned Unix through its manpage. I learned abotu sh, awk,
| grep, I learned about sockets and tcp, I learned about semaphore
| and shared memory. When I started working on Unix, in the early
| 90s', it was on a true-to-form physical VT220. I quickly learned
| to run make in the background so I could read the manpage while
| compiling.
| markus_zhang wrote:
| From my experience some manpages glaringly miss examples or
| explanations. Hint: all manpages that you don't need to move down
| for more contents probably fall into this catalog.
|
| I completely agree that they are only useful if you know what you
| are looking for, and nothing else.
|
| Although I'm still a newbie, but I'll never tell a complete
| newbie to RTFM, considering there is not many high quality manual
| out there. Actually most hottie open source tools we happened to
| introduce into our workflow have half-assed doc at most. I'll
| just teach him to Google stuffs efficiently and let himself
| figure out the rest. Sometimes it's surprisingly difficult to
| know what exactly to put into that search box.
|
| I'm not a hacker. I'll never be even close to Ritchie, Carmack,
| whoever write state of art malwares. I know the pain.
| JdeBP wrote:
| Too many people think that GNU manual pages are what _all_
| manual pages look like. Not everyone has the GNU tradition of
| telling you to switch to a different doco format for better man
| pages. (-:
|
| The thing to remember is that for many systems there are both
| _guides_ and _handbooks_ , _tutorial_ style doco, in addition
| to the _reference_ doco, the manual pages. Linux-based
| operating systems come up a bit short in comparison to the old
| commercial Unices which had specific user guides, and in
| comparison to the BSDs, all of which have handbooks. Even
| Debian only has an admininstrators ' guide, not a users' guide.
|
| But The Linux Documentation Project is oft forgotten. It's
| stale. It's unfashionable. It's oddly chock full of how-tos for
| things that one wouldn't dream of wanting to do this century.
| But it also has longer format stuff, and _it 's still there_.
|
| Consider the _Introduction To Linux_ for example:
|
| * https://tldp.org/LDP/intro-linux/html/sect_05_01.html
|
| Or the _Linux Command-Line Tools Summary_:
|
| * https://tldp.org/LDP/GNU-Linux-Tools-Summary/html/working-
| fi...
|
| Or the _Bash Guide for Beginners_:
|
| * https://tldp.org/LDP/Bash-Beginners-
| Guide/html/sect_04_03.ht...
| markus_zhang wrote:
| Thanks! I did find tldp extremely helpful and entertaining to
| read sometimes.
| h2odragon wrote:
| Sounds like "you can't learn _true_ Judo without traveling to
| some mountain temple and eating nothing but rice and punching a
| brick wall all day for 3 years "
|
| Furthermore, it's another case of some old Usenet hyperbole being
| taken as Gospel (or taken down as Gospel, which is ore the style
| now). One of the most important lessons the Jargon file has for
| "how to become a hacker", is "don't take anything too seriously."
| jmclnx wrote:
| I learned it from 2 sources:
|
| * IN/ix (16 bit UNIX) Documents. The Docs were the old UNIX
| documents, most were man pages
|
| * Later I got Coherent for my 286, the book that came with it was
| awesome.
|
| FWIW, OpenBSD's man pages are very good, much better that what
| Linux has.
| pmontra wrote:
| I remember that I read a book with the main UNIX commands plus a
| vi tutorial and then a lot of manpages. That was in the second
| half of the 80s.
| JdeBP wrote:
| Only one? (-:
|
| I read Foxley's Unix for Superusers, the Unix Text Processing
| book, and a couple of other books.
| brycewray wrote:
| > This is how we get monstrosities like the Git documentation,
| that are only of any use to someone who already knows how it
| works and just needs a bit of a reminder.
|
| Preach.
| xg15 wrote:
| Git is seriously weird in that regard. It reads like someone
| just really wanted to build a content-addressable file system
| and a generic append-only graph data structure on top, and
| then, to their mild annoyance, people were starting to use it
| as a version control system...
___________________________________________________________________
(page generated 2023-05-24 23:01 UTC)