[HN Gopher] Linux Terminal Tools [pdf]
___________________________________________________________________
Linux Terminal Tools [pdf]
Author : ketanmaheshwari
Score : 139 points
Date : 2021-05-04 13:53 UTC (9 hours ago)
(HTM) web link (ketancmaheshwari.github.io)
(TXT) w3m dump (ketancmaheshwari.github.io)
| periheli0n wrote:
| This! Super helpful. Thanks! I have worked with the command line
| for 20+ years, still I've learnt a ton. Now if this could be
| compiled on one or two pages in small print, it would make an
| excellent cheat sheet!
| dafty4 wrote:
| Needs to add `apropos`.
| yazantapuz wrote:
| Very useful! The deletion commands are very handy (i only knew
| ^U).
| cerved wrote:
| pdf :(
| ketanmaheshwari wrote:
| Would you rather have it in HTML or any other formats? I could
| perhaps convert to HTML using Pandoc.
| sandreas wrote:
| I suggest markdown as base... can easily be converted to PDF,
| HTML and others.
| leephillips wrote:
| There is nothing wrong with the nicely formatted PDF file
| that you provided. Don't listen to these savages.
| anotha1 wrote:
| > use ctrl-y to paste back the deleted
|
| TIL
| TheCowboy wrote:
| Emacs yank. If you're familiar with Emacs or Vi then you might
| already know some shortcuts.
|
| https://unix.stackexchange.com/questions/85390/what-is-meant...
| snug wrote:
| The secret that I never see brought up on any of the linux
| command line tools is "esc + ." - It's by far one of the most
| valuable tricks I've learned, it will insert the last thing from
| the last command
|
| ls /foo/bar/this_is_the_file.txt
|
| cat "esc + ."
|
| which expands to
|
| cat /foo/bar/this_is_the_file.txt
| leephillips wrote:
| I've used !$ forever to substitute the last word from the
| previous command, but I never knew about this.
| pinkrobotics wrote:
| wow, thank you! I did not know this. It will be very useful!
| johnklos wrote:
| It's a shame that a whole generation of people who want to be IT
| literate think that this is "Linux". This is Unix.
|
| Would we name a map book "A Toyota Roadmap", as if we don't know
| that there are other cars, and that a map applies to cars, not
| just to Toyotas specifically? Sure, a map would be different for
| push scooters (Windows), but a map would be the same for cars and
| small trucks.
|
| It seems petty, but it becomes difficult to make a distinction
| between what's generally Unix and what's actually specifically
| Linux when we just call everything Linux.
| ansible wrote:
| > _It 's a shame that a whole generation of people who want to
| be IT literate think that this is "Linux". This is Unix._
|
| Is it though?
|
| _Disclaimer:_ I am an old Unix hand (a literal graybeard). I
| started using Unix back in the mid 1980s, when a dual VAX 11
| /780 was hot stuff. I've used most of the major Unix
| distributions that ever existed.
|
| In terms of server market share [1], Unix these days is, like,
| 95% Linux in various distros, with Windows, Free/Open/NetBSD,
| Illuminos, and a few others rounding out the top 10.
|
| We can and should honor the past, and the innovators that made
| today's compute environment possible. But in a sense, "Unix" is
| a historical legacy, and denying that isn't useful.
|
| [1] Because outside of some hobbyists, who is running
| traditional Unix on the desktop these days? Desktop "Unix" is
| really OSX and Linux these days.
| ketanmaheshwari wrote:
| I think by that analogy the title should have been "Computer
| Operating Systems Terminal Tools". The tools presented in the
| slides have been tested on a Linux System, which motivated the
| title name.
| generalizations wrote:
| That would be incorrect: it's too general. These tools don't
| apply to Windows; yet some do apply to MacOS, due to its
| BSD/UNIX (not Linux) roots.
| nathanwh wrote:
| I think the reason that it seems petty is that distinction is
| just not useful information for most people. It's at best a
| historical asterisk on whatever is being discussed. I don't use
| Unix, and I don't know anyone that uses Unix. Linux tools seems
| right to me because, I get the tools from whatever flavor of
| Linux OS I installed.
| dundarious wrote:
| This function will fail when given an argument with a space,
| which would be quite frustrating for a beginner, which is
| presumably the target audience for such a document:
|
| > mcd() { mkdir -p $1; cd $1 }
|
| It should be more like:
|
| > mcd() { mkdir -p "$1"; cd "$1"; }
|
| The trailing ";" is also required in bash for oneline blocks like
| this.
|
| Same goes for most of the other functions on page 70. "$@", etc.
|
| Just trying to make the learning experience less frustrating, not
| trying to tear down the effort :)
| fiddlerwoaroof wrote:
| I still do this reflexively but zsh doesn't word-split variable
| expansions, so the first version would work as expected.
|
| Little things like this have made me prefer using zsh whenever
| feasible: and, in the age of dockerized everything, there's few
| good reasons left to use bash.
| ketanmaheshwari wrote:
| Ah thank you! I will fix it.
| sandreas wrote:
| function mkcd() { mkdir -p "$@" && cd "$1"; }
|
| supports multiple dirs and cd to the first one
| mkcd a b c
| [deleted]
| enriquto wrote:
| a beginner would not likely quote the argument, so the point is
| moot...
|
| besides, what kind of savage wants a directory name with
| spaces?
| dundarious wrote:
| True, they'd have to learn how to use arguments with spaces
| in the shell -- but this won't necessarily happen near the
| time they add mcd to their .bashrc, which may lead to
| frustration with customization, and stifle the desire to
| learn. Something to be avoided when it is simple and easy to
| do so.
| hpcjoe wrote:
| (looks at all his directories which are written as phrases
| and ...)
|
| [raises hand] This type of savage?
| yjftsjthsd-h wrote:
| > a beginner would not likely quote the argument, so the
| point is moot...
|
| But a beginner _could_ still tab-complete file names and get
| them automatically backslashed.
| [deleted]
| pjungwir wrote:
| If we're being picky then you probably also want `mkdir -p --
| "$1"` in case they want to create a directory named `-m`, `-v`,
| etc.
|
| Surprisingly `--` isn't mentioned in the mkdir manpage on my
| system, but it works. E.g. `mkdir -- -p` does what you'd want.
| a1369209993 wrote:
| Strictly speaking you want `mkdir -p "./$1"`, although the
| failure modes of `--`-ing arguments aren't as immediately
| demonstratable as those of not deflagging them at all.
| je42 wrote:
| it probably makes sense to use "&&" instead of ";": if mkdir -p
| fails cd is still being executed.
| ammar_x wrote:
| I found the navigation shortcuts useful: ctrl-a, ctrl-e, etc.
| [deleted]
| SavantIdiot wrote:
| Should include CTRL-Q and CTRL-S, as I've encountered students
| who accidentally hit CTRL-S instead of CTRL-X and then stare at a
| hung terminal wonder WTF just happened.
| johnvaluk wrote:
| It's a learning moment for users who press Ctrl-s to save their
| work due to muscle memory from other environments. That's when
| they get a crash course in Ctrl-q and screen/tmux.
| SavantIdiot wrote:
| CTRL-S in a terminal command-line? That doesn't seem likely
| as you're never in a "save-mode thought" on the CLI.
|
| Funny, I used to have ctrl-s muscle memory, then 10 years of
| primarily developing on mac got me used to cmd-s since mac
| keyboards are so annoying. now when i switch between
| mac/win/linux it's just a constant mess of pressing the wrong
| special key combos. Almost as bad switching between scripting
| languages and forgetting if a function starts with func,
| proc, sub, def, etc... (yes, I know you can swap special keys
| on mac: i tried it and it creates way more headaches than it
| solves.)
| ansible wrote:
| I'm of the opinion that those should just be disabled these
| days.
|
| Aside from the occasional AMD motherboard that has a very slow
| scrolling non-text-mode framebuffer, Ctrl-Q and Ctrl-S aren't
| so useful with the GUI terminal programs or console terminals
| nowdays.
| gpvos wrote:
| I still use them. E.g., for build processes that scroll by
| just a little too fast.
| MR4D wrote:
| 103 pages of Linux commandline goodness! Nice overall reference,
| especially the parts on regex and awk.
|
| Table of Contents (for those who hate PDFs):
|
| Part 1: Overview and Logistics
|
| * Part 2: Basics
|
| * Part 3: Streams, pipe and redirection
|
| * Part 4: Classic Tools: find, grep, awk, sed
|
| * Part 5: Session Management: tmux
|
| * Part 6: ssh: config and tunneling
|
| * Part 7: Secure Communication with GnuPG
|
| * Part 8: Bash Tools
|
| * Part 9: Program Development Tools
|
| * Part 10: Miscellaneous Utilities
|
| * Summary
|
| * Practice and Exercises (if time permits else Offline)
| gpvos wrote:
| Good list. But when you write about xargs, you should absolutely
| warn that it has problems working with filenames with spaces in
| them, and the -0 option to fix that.
| nojito wrote:
| Linux shells are so unbelievably painful.
|
| I switched over to powershell and the quality of life
| improvements have been amazing.
| wooptoo wrote:
| Perhaps you haven't tried fish shell? https://fishshell.com/
| r0f1 wrote:
| Nice presentation. I have made my own list, if anyone is
| interested: https://github.com/r0f1/linuxhelp
___________________________________________________________________
(page generated 2021-05-04 23:02 UTC)