[HN Gopher] How to Learn Unix Tools
___________________________________________________________________
How to Learn Unix Tools
Author : nindalf
Score : 155 points
Date : 2021-04-26 08:22 UTC (14 hours ago)
(HTM) web link (blog.nindalf.com)
(TXT) w3m dump (blog.nindalf.com)
| jll29 wrote:
| 1. read the manual pages in book form.
|
| 2. play a man page quiz with a friend: - read a random command
| and ask for the description - read a random description and ask
| which command it is for.
|
| I've done both as an undergraduate. The HP-UX manual set remain
| on the shelves right next to me. Over the years, I found letting
| candidates compose a pipeline of commands to solve a problem is a
| great way to make interviews more fun ("How would you solve this
| problem without writing a program, by combining existing ones?").
| Raineer wrote:
| I did the "man pages in book form" when studying for my LPIC.
| Also flashcards. Both approaches worked excellently :)
| rodiger wrote:
| That's useful, but as someone with an unreliable memory having
| to recall specific commands under pressure doesn't sound too
| fun :)
| Tsiklon wrote:
| I don't think absolute precision regarding specific commands
| or flags therein would be required because when you're in the
| chair and dealing with a problem you're going to have access
| to the resources you need to get that precision (man pages,
| vendor documentation etc).
|
| Though being able to explain the mental model of how you want
| to go about manipulating the output, extraction of the
| information or data you need, be it through json
| manipulation, regex, line/column parsing etc is valuable.
| narwally wrote:
| Exactly, the man pages are there so I don't have to remember
| every command perfectly.
| crazypython wrote:
| I use tldr-pages: https://github.com/tldr-pages/tldr
| yiyus wrote:
| Plan 9 man pages are also much more manageable than their
| respective GNU versions.
|
| The tools in Plan 9 are also much simpler, with fewer options
| (and also a few differences), but it's a very useful subset,
| you will rarely need anything else.
| jasonladuke0311 wrote:
| I like tldr, but I find about half of the time it doesn't cover
| the use case I am looking for. I do find it useful for
| remembering arg order and such.
| mraza007 wrote:
| Honestly I have forced my self to use a terminal and now I can't
| even go without using it.
|
| I have made my workflow very minimal such as I use firefox for
| browsing and terminal for pretty much everything
| blumomo wrote:
| Try Qutebrowser [0] instead of Firefox as it has a terminal-
| like command line interface (while staying graphical), no mouse
| required.
|
| [0] https://qutebrowser.org/
| enriquto wrote:
| Still, after almost 40 years, Kernighan and Pike's book is a
| great reference
|
| https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...
|
| It may be a bit dated in some inconsequential details, but it is
| an extremely refreshing and fun read.
| bear8642 wrote:
| the yacc and lex tutorial to build hoc is also excellent
| samuel wrote:
| The best way is being restricted to dumb terminals for compiling
| and running university assigments.
|
| I don't know how younger people force themselves to learn to use
| the command line. I had a windows 98 at home at the time and the
| university enviroment seemed primitive in comparison, but I had
| no choice.
|
| And were lucky, we had X-terminals!
| the_only_law wrote:
| I have a few dumb terminals connected to my machine. I wanted
| to get an X-terminal but I'm holding off because I'm worried
| about the incompatibility between modern X-clients with
| whatever extensions they may use and the old X-servers
| typically running on the terminals.
| dsr_ wrote:
| You're most likely to have problems with video playback. Most
| other things should work quite well.
| the_only_law wrote:
| That sounds good, I had a hunch video playback wouldn't
| work. My only other hesitation is that the particular ones
| only connect over 10Base5, which would involve some extra
| networking work and SLIP, which I'm not sure is even
| support on modern Linux given PPP seems to be the go to for
| that sort of thing now.
| Hjfrf wrote:
| The default options for shadow-IT are VBA and Powershell, since
| you don't need to ask permission or install anything to make a
| mvp.
|
| I guess there will be many Powershell users in future for that
| reason alone.
| ethbr0 wrote:
| I've worked with a client that blocks cmd, but not Powershell
| or VBA. God, I hate security-by-explicit-requirement.
| robaato wrote:
| <yorkshire_accent>Luxury!!</yorkshire_accent>
|
| When I were a lad we had a teletype terminal in Pollock Halls
| (Edinburgh) to complete our assignments (well there were some
| VT100s but with deadlines coming up you had to take what was
| free!).
| ajross wrote:
| Yeah, it helps to have better equipment. My initiation
| consisted of getting stuck in emacs on a VT220 connected to a
| MIPS DECstation.
| bigbillheck wrote:
| I don't remember if it was a VT220 or VT320 that did it but
| I had to use one in undergrad computer lab (also connected
| to some kind of DEC running ultrix) where whenever emacs
| did a screen redraw (for example if you did a page down
| with C-v) it would go into I-search mode because something
| in the terminfo had a C-s to freeze the screen (before some
| more commands and then a C-q to un-freeze), and this was
| visible to emacs.
|
| Anyway what I'm trying to say is just as I'm glad I didn't
| have to use punch cards, I'm glad that the youth don't have
| to deal with that kind of nonsense.
| patrickdavey wrote:
| Teletype ! Luxury!
|
| Why when I was a lad had to get up 10 minutes before we went
| to sleep, mill our own paper AND punch the cards, and if you
| left an instruction out it was no supper for a week.
| bonaldi wrote:
| Over at Heriot-Watt we had SGIs and Windows boxes aplenty and
| I still found myself working in a little office on a VT100
| hooked up to a Sun 3 (which ran a forgotten line printer). At
| first just because there was never any demand for the room,
| then later because it was just more fun.
| koolba wrote:
| For even faster learning make sure the remote machine is far
| enough away that network lag is a factor. It's amazing how fast
| the student will learn I/O redirection, tailing files, and
| grepping for needles, and of course automating the entire build
| / test lifecycle.
| agumonkey wrote:
| And compression
| ASalazarMX wrote:
| Having used a 3270 terminal in an extremely saturated system,
| it's amazing how much your way of working changes. Typing a
| full page of code, checking for typos, doing a test run in
| your head, then finally pressing Enter and sipping your
| coffee while the system took 1-2 minutes to process the
| screen.
|
| As soon as it was upgraded, we reverted to the normal
| workflow of pressing Enter first, the correcting typos,
| paginating instead of searching, debugging live instead of in
| our heads, etc. I don't think we were more of less productive
| either way, they're just different ways of working.
| nerdponx wrote:
| I first learned not only the Unix CLI but _Vim_ under these
| conditions.
|
| I typed the HTML for my student website by hand in a minimal
| and ancient Vim build, because student websites were hosted
| on some kind of Unix mainframe.
|
| It probably took me 2 hours to write 5 sentences! I was so
| proud of myself that I added a footer to the effect of:
|
| > This page was typed painstakingly in Vim. "What doesn't
| kill you makes you stronger."
|
| I'm sure I would have eventually forced myself to learn Vim
| anyway if I never had access to this Unix system, but it was
| definitely important and formative to start off this way.
| soheilpro wrote:
| Shameless plug: mann helps your remember command line args.
|
| https://github.com/soheilpro/mann
| narwally wrote:
| This is awesome and so simple that I can't believe I haven't
| done it for myself already. It would be really useful to have
| your personal mann page displayed as the header or footer of
| the official man page.
| kerblang wrote:
| I often look at web versions of man pages because it's just plain
| easier to deal with when researching mega-commands like curl or
| openssl. The green-screen-text-only bastard in me argues
| vehemently against this, but the pragmatist in me doesn't care.
| It's just plain easier.
| enriquto wrote:
| How so? You can navigate much more easily inside the less pager
| that displays manpages than inside a browser. Moreover, it is
| easier to copy/paste (or simply read) snippets of the manpage
| into your terminal, after all everything happens in the same
| window. Opening a web browser and finding the man page also
| seems much more cumbersome than typing "man". I would never
| have thought that it would seem easier to anybody!
| jonseager wrote:
| This post definitely contains some good general advice, to me the
| most important step is really simple:
|
| Just use them. And keep on using them.
|
| Resources like those suggested are good, but each will suit
| people differently - the one thing that all people who are expert
| at these tools have in common is that they've all used them a
| lot!
| zoomablemind wrote:
| > Just use them. And keep on using them.
|
| The last bit is very crucial. Be prepared to relearn it after a
| prolonged break. So taking notes may be of some practical help.
|
| I wish *NIX land had some uniform convention for options naming
| and a targeted help system to go with it, so one could lookup
| an option directly (preferrably in shortened form, no need to
| spell out the whole word). OpenVMS HELP was a good example of
| user-friendly command-line help system, well, but that's
| another story...
| jonseager wrote:
| And, to be fair, give yourself a safe enough space to
| experiment.
|
| Use Docker, libvirt, Digital Ocean, multipass, Virtualbox, or
| whatever you want, but find a place where you can use the stuff
| without worrying too much about the consequences :)
| hnlmorg wrote:
| > _Most of these tools come with a --help or -h switch, that
| tells you the options available, with a short explanation of what
| each does._
|
| Please don't do this by default unless you're sure such a command
| supports that flag otherwise you're literally just running
| unknown commands with unknown consequences.
|
| The first port of call should always be `man` and not `--help`
| like the article suggests. Aside from that, the article looks
| good.
| pfarrell wrote:
| For example, the Postgres interactive client, psql:
| -?, ---help -> help info -h -> set the host you are
| connecting
| thinkmassive wrote:
| If `--help` does anything besides display usage info or fail,
| the author of the tool is to blame.
|
| Many applications that are installed outside the scope of a
| package manager, especially tools distributed as a single
| binary, lack a manpage.
| 2OEH8eoCRo0 wrote:
| This is my reasoning.
|
| There are almost no man pages at my job and the software is
| very old so good luck Googling. I practically default to
| --help here. I figure if --help somehow screws something up
| then they deserve it.
| hnlmorg wrote:
| > _If `--help` does anything besides display usage info or
| fail, the author of the tool is to blame._
|
| No they're not. Not every command line tool uses flags, some
| use ordered parameters. So parameter 1 might be a file name
| to write to rather than a flag. Just look at how messy it is
| working with tools like `cp` and the `--` flag to get an idea
| of the problems some programs face differentiating between
| files and flags.
|
| Other tools might not take any command line parameters at
| all. So it's entirely forgiveable for them not to check if
| any parameters were supplied.
|
| Then there is the issue that some programs accept `-h` and
| others `-?` as a shorthand. Some programs have `-h` as short
| for `--host`.
|
| Plus even if I were to agree with your point, which I don't,
| it's entirely moot because it's not the author of the tool
| that is the one who has to fix any issues that might happen
| to a host system due to someone blindly running commands.
|
| So whichever way you cut it, blindly throwing flags at
| executables and expecting a favourable outcome every time can
| be risky.
|
| > _Many applications that are installed outside the scope of
| a package manager, especially tools distributed as a single
| binary, lack a manpage._
|
| That point wasn't forgotten by me. But if you've downloaded
| an application outside the scope of the package manager then
| you should at least have some idea how it functions and thus
| know whether it's safe to run `--help`. If not, you probably
| know where to look online to find that information out.
|
| Like I said in my OP, I've got nothing against people using
| `--help` et al. I use them myself. But it shouldn't be the
| _first_ thing you recommend UNIX newbies to do when they 're
| figuring out a command. It's usually something you do when
| you're already familiar with what a command does but need a
| nudge as to what flags you need to supply.
| sweeneyrod wrote:
| What is a program where `--help` is dangerous?
| hnlmorg wrote:
| For starters, anything that's a shell script. Maybe add
| Perl to that equation too (I've seen all too many Perl
| scripts that didn't properly check parameters).
|
| I've also seen plenty of enterprise UNIX era software not
| follow GNUisms (which '---help' technically is). It's all
| good and well if your just running GNU/Linux with modern
| DevOps tooling but don't expect '---help' to work on
| every Solaris or BSD application. Not to mention relics
| like Informix and it's tools.
|
| Also anything hacked together in house should be treated
| with caution too. Open those files in $EDITOR and/or
| examine the README (if you're lucky enough to have one)
| first because there's no telling how lazy your
| predecessor might have been.
|
| So yeah, over my career I've ran into _numerous_
| instances where '---help' might have had unforeseen
| consequences.
| jonsen wrote:
| "Trial and error is the way to go." I hate it. And that's why I
| never made it far into unix land.
| enriquto wrote:
| > "Trial and error is the way to go." I hate it.
|
| Errr... isn't _all_ of science is based on trial and error?
| hulitu wrote:
| Unix has a manual, you know.
| petr25102018 wrote:
| I have recently published an ebook about the introduction to the
| Linux command line, for anyone interested:
| https://gumroad.com/l/moderncommandline
| wodenokoto wrote:
| In terms of getting started with the command line and getting an
| understanding of what you are doing (rather than a handful of
| "memories these commands" as some beginner tutorials sadly end up
| being) I've found "Learn enough command line to be dangerous" to
| be absolutely amazing.
|
| It's free, even though the webpage makes it look you might need
| to buy a subscription (edit: you need to pay beyond chapter 2).
| It takes half a day to a whole workday to work through, but for
| me it was a great investment of time.
|
| https://www.learnenough.com/command-line-tutorial
| drowntoge wrote:
| The tutorial looks neat. It asks me to start a $5 subscription
| to get past Chapter 2 though.
| wodenokoto wrote:
| My bad. It used to be free and I just clicked through to the
| second chapter and that convinced me it was still the case.
| rovr138 wrote:
| At the bottom it says continue reading and it took me to
| chapter 2 and from there to 3,
|
| https://www.learnenough.com/command-line-
| tutorial/manipulati...
| trymas wrote:
| Chapter 3 is locked - at least for me.
|
| Though 3$ is probably a small price to pay for standalone
| version.
| nateweiss wrote:
| Looks like they also offer the book for $3 "la la carte"
| (without a subscription) which sounds reasonable.
| throwaway823882 wrote:
| > I've never read a man page from start to finish, and I'm not
| sure you're meant to.
|
| When I was 16 and just starting to get into Linux, I got a tiny
| little paperback, "reference to Unix programs" or something. It
| was literally just a list of every single Unix program and a
| shortened version of its man page. I read it cover to cover.
| After that, if I needed to do something on the command line, I
| knew there was a program to do it and what its capabilities were.
| After a couple weeks I didn't need the reference anymore.
|
| I can't remember the book anymore, but this is basically what it
| was like: https://dspinellis.github.io/unix-v4man/v4man.pdf See
| if you can find a version newer than 1973, though... O'Reilly's
| _Unix In A Nutshell_ isn 't bad.
|
| Read your man pages cover to cover. It's for the same exact
| reason you learn a bunch of "useless BS" in school: to save you
| time down the road because you'll know where to go for the
| solution.
| conjectures wrote:
| `tldr` program seems useful to know about, thanks.
| bennyp101 wrote:
| Yep, I've just installed it - looks like it will be perfect for
| when I have to do things that I rarely do (and just want to
| quickly know how to do something)
| jackdawed wrote:
| You might be interested in the Rust implementation
| dbrgn/tealdeer. There is also denisdoro/navi which can use both
| cheat.sh and tldr, and you can also write your own cheatsheets.
| Raineer wrote:
| I never knew about tldr. That tip alone is phenomenal. I'm
| embarrassed to say I've been doing this 20 years and never seen
| it. Trying to pull out several common usage examples from man
| pages has always been my difficulty.
| alex_smart wrote:
| Try this:
|
| man man | awk '/^[A-Z]+/ { begin = 0 } /^EXAMPLES|^NAME/ {
| begin = 1 } (begin == 1) { print }'
| hivacruz wrote:
| man is missing some concrete examples about how the tool could be
| used. tldr seems a good thing to fix that. cheat.sh is also a
| great alternative to tldr, I use it a lot.
| monkeycantype wrote:
| I regularly google man {x} : man grep, man curl... and a couple
| of times a year I absentmindedly google : man find. there's no
| linux in the first 30 pages of results
| dredmorbius wrote:
| DDG bang searches:
|
| manpage !manpage
|
| Debian Manpages !debman
|
| manpages. org !mnp
|
| MirBSD Manpages !mbsdman
|
| Ubuntu Manpage !uman
| mmcgaha wrote:
| For users, The UNIX Programming Environment by Kernighan and Pike
| is the book that got me going. There are a few things in there
| that don't exist now but it is the most concise easy-to-read book
| for new *nix users.
|
| For administration the UNIX System Administration Handbook by
| Nemeth, Snyder, Seebass, and Hein is how I got started. Newer
| editions of this book cover Linux specifically.
| Tsiklon wrote:
| The UNIX System Administration Handbook was the bible when I
| got started out. A tremendous book with a sizable legacy.
| ephaeton wrote:
| how I learned UNIX tools:
|
| (on a NetBSD,) alphabetically went through /bin, /usr/bin, /sbin,
| /usr/sbin, /usr/games and read each of the program's man pages.
| Yeah, took a while. Also read POSIX.2
|
| The things you do with your free time ...
| scbrg wrote:
| Sucks to not learn about zsh until the very end though ;)
| ephaeton wrote:
| Haha! I understand the sentiment :)
|
| But it was ok, NetBSD doesn't have zsh installed by default
| (and neither bash, only csh, sh and (pd? m?)ksh). When I did
| that, I was primed to use tcsh at $WORK. Switched to ksh
| later (and remained on there for a loooong time).
|
| Anyways. I failed to make an actual point. My point was the
| following: The BSD manpages are _excellent_. IMO way better
| than the linux/GNU manpages (or info pages) of comparable
| utilities. It shows, again IMO, that the BSDs are a complete,
| single-tree distribution where documentation, userland and
| kernel go hand in hand and are equally well groomed.
|
| So maybe, for learning "UNIX", go get yourself a nice little
| {Net,Free,Open}BSD install and toy around with the elder
| ways.
| abhayhegde wrote:
| I did not know about `cmatrix`. Looks so cool. I wonder why does
| its CPU usage shoots beyond 40% though.
| dspillett wrote:
| Is it choosing the CPU resource, or is it your terminal app
| doing so to make many individual changes per frame? Many
| terminal emulators are far from efficient in that sort of use
| case as they simply aren't optimised at all for it as it is
| relatively rare.
|
| It could be a mix of both, of course.
| yiyus wrote:
| There are irc channels that can also be of help.
|
| I used to spend my time in #sed and #awk, and try to answer any
| short question that came up in the channel. They came up at a
| good pace, I don't know if this is still the case.
|
| It was a really good exercise, and it has an additional social
| aspect you will not get from reading books (which is a great
| resource too).
| sgt wrote:
| It's almost bizarre how cmatrix takes up 100% CPU on my computer.
| I suspect it will be more efficient in xterm rather than
| Terminal.app though.
| nindalf wrote:
| 100% CPU is a small price to pay to look like a hacker. :)
| enriquto wrote:
| > I suspect it will be more efficient in xterm rather than
| Terminal.app though.
|
| Indeed. I get 3% CPU usage on my xterm, 5% when in full screen.
| Still too much for a barely 6 year-old laptop, but nothing to
| worry about.
|
| EDIT: if you add the "-a" option (asyncronous scroll), CPU
| usage falls below 1%. I wonder what Terminal.app does to be so
| outrageously inefficient.
| sgt wrote:
| I think it's a combination of a larger window, antialiased
| text, arguably better font, semi transparent background,
| terminal being 256-color (or more), and so on. By passing -a
| I get it down to 80% CPU. This is progress, guys!
| enriquto wrote:
| It can't be that.
|
| I have all of this except the transparent background. But
| that should be a compositor thing, independent of the
| window contents. That's bizarre, pushing a few thousand
| characters to the screen shouldn't, by far, reach 80% CPU
| usage. There's something in your system that's really
| botched up.
| sgt wrote:
| I tested again, it's Terminal.app doing something! I
| tried with iTerm and CPU usage is negligible. Wonder what
| it is doing. My system is otherwise very fast.
| alex_smart wrote:
| Wow, no love for info?
| chousuke wrote:
| What does info add over plain old manual pages? I honestly
| don't really know, since I usually forget that info even
| exists.
|
| I feel like the effort the GNU project put into creating a
| competing standard for documentation would have been better
| spent improving the tooling around the standard man page
| mechanisms instead.
| alex_smart wrote:
| >What does info add over plain old manual pages?
|
| I feel like info pages are more suitable for explaining the
| features of larger pieces of software. Can you imagine what a
| mess the man page for emacs would be, if it were to try to
| explain all its functionality? Instead the man page of emacs
| only gives a brief description of the software and explains
| the command line options and all the functionality is
| explained in an info document.
|
| I think of info as an alternative to /usr/share/doc, not man
| pages.
|
| The most import features of info that are missing from man:
|
| 1. pagination 2. cross-referencing 3. structure
| dredmorbius wrote:
| There is some truly great info-based documentation. The GNU
| AWK User Guide comes to mind:
|
| https://www.gnu.org/software/gawk/manual/gawk.html
|
| There's alot of information in there that is _not_ in the
| manpage.
|
| (I'm painfully aware of this as I tend to rely mostly on the
| manpage, and learn things every time (which is rare) I read
| the GNU docs.)
|
| At the same time, the info interface and navigation remain
| completely opaque and nonintuitive to me.
| dredmorbius wrote:
| The genius of man is that it uses any standard system pager,
| and so the navigation semantics (admittedly simple) are clear.
|
| Info uses a _dedicated_ document viewer, which, _unless you use
| that frequently_ is novel and ideosycratic when used.
|
| (This can be changed, but more painfully than with man.)
|
| Info is a _hypertext_ documentation system admittedly. It
| happens to have been invented pretty much simultaneously with
| another you may have heard of, the World Wide Web. A system
| with slightly greater user familiarity. And Free Software
| implementations.
|
| Debian's 'dwww' is an interesting marriage of multiple
| docuentation formats. It presents manpages, info pages, Debian
| package information, and additional documentation, all
| categorised and indexed, and accessible through a web browser
| from your local system.
|
| Including, as it happens, _console mode_ browsers (lynx, w3m,
| elinks, links2, etc.). Which tends to amp up _and_ standardise
| access to all of the above.
|
| dwww is the one thing which makes info actually useful. Which
| is a shame as there really _is_ some quite good info
| documentation, it 's just buried under what is for most people,
| an impenetrable interface.
___________________________________________________________________
(page generated 2021-04-26 23:02 UTC)