Linux Terminal Tools [pdf] | Hacker News Reader

Linux Terminal Tools [pdf]

ketancmaheshwari.github.io

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 :)

it probably makes sense to use "&&" instead of ";": if mkdir -p fails cd is still being executed.

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.

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.

You definitely don't want to universally add the "./" prefix because it breaks on absolute paths.

The only solution is for users to add the "./" prefix themselves when the path begins with "-", because many BSD userspaces don't support "--" as a marker to stop option parsing. Maybe that doesn't matter for a document with Linux in the title, but given the popularity of macOS for doing Linux development, I would still err on the side of supporting the BSDs for such things. Never mind that support for "--" outside GNU is very spotty, even on Linux.

There is no point, in my opinion, in trying to be smart in small shell helper functions. It should just do a simple, relatively foolproof series of commands, and usually, bail early on error. But the intersection of `mkdir -p` failures and `cd` successes is tiny, so I didn't even bother muddying the waters by suggesting another alteration to use `&&`.

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.

Ah thank you! I will fix it.

  function mkcd() {
    mkdir -p "$@" && cd "$1";
  }

supports multiple dirs and cd to the first one

  mkcd a b c

a beginner would not likely quote the argument, so the point is moot...

besides, what kind of savage wants a directory name with spaces?

> 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.

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.

(looks at all his directories which are written as phrases and ...)

[raises hand] This type of savage?

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)

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

I agree, and some days ago, in another thread, I got +10 on my comment detailing this shortcut.

Another no-brainer imho is editing you /etc/inputrc or your $HOME/.inputrc and bind keys (usually PgUp and PgDn) to history-search-backward and history-search-forward.

From there you can navigate your history like with the arrows, but it will only consider lines that starts with the string that is currently on the command line.

It is a MUST.

This is something that comes with oh-my-zsh, love that feature!

Alt + . does the same thing as well, with the added advantage that you can keep pressing Alt and then hit "." several times to go through all the "last arguments" in your history one by one.

Doesn't seem to work on mac :/

I haven't used a mac in years, but I know for sure that I had found a workaround. I would go insane without "Alt+." on the shell, I use it very, very frequently.

Try this: https://lorenzo.mile.si/macos-iterm2-use-linux-keyboard-shor...

Thanks, i'm using iTerm2, which seems to have an experimental feature for repeat previous character escape sequence enabled by default, but doesn't really work that well, I suspect it's the touchbar escape key that doesn't play too nicely to the hold

edit: I'm dumb, that was for iTerm, I got it working!

I’ve used !$ forever to substitute the last word from the previous command, but I never knew about this.

wow, thank you! I did not know this. It will be very useful!

ok this is going to sound stupid, but I don't care. learning time, for me.

do you type the literal characters "esc + ." or do you press CTRL+[ then period, or do you push the escape key, then period, or do you push escape and period at the same time?

I'm not at a terminal to try any of this and find out for myself.

I press and hold escape first then period

ESC isn't a control code like CTRL or SHIFT or ALT - so holding it while you press another key is weird, to me.

But pressing and releasing ESC and then pressing and releasing period works excellently. Thank you.

Ahh nice, yeah, that works, I always just assumed I needed to hit ESC first, but didn't know they didn't need to be held at the same time

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.

> 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.

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.

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.

there are many ways in which these do apply on Windows, these days.

please work on separating the semantics of someone's statement from the pragmatics. don't bother with the "how they phrased it" bit, and instead try to focus on the "what are they trying to say" part more. you may be, like I did all too often in my youth, over-emphasizing English correctness, missing the message being communicated entirely.

maybe you're not doing that! maybe you are. only you can know for sure. if you are, then try to work on that. it will help you communicate and it will help others communicate with you. we all grow as people over time, and no one is flawless, and that's fine. just try to be better every day.

Honestly? When you tell me what to think about and improve, you come across as condescending. Maybe you didn't mean to? Either way, you should try to work on that.

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.

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.

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!

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.

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.

I still use them. E.g., for build processes that scroll by just a little too fast.

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.

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.)

Nice presentation. I have made my own list, if anyone is interested: https://github.com/r0f1/linuxhelp

> use ctrl-y to paste back the deleted

TIL

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...

Needs to add `apropos`.

Very useful! The deletion commands are very handy (i only knew ^U).

I found the navigation shortcuts useful: ctrl-a, ctrl-e, etc.

pdf :(

Would you rather have it in HTML or any other formats? I could perhaps convert to HTML using Pandoc.

There is nothing wrong with the nicely formatted PDF file that you provided. Don’t listen to these savages.

I suggest markdown as base... can easily be converted to PDF, HTML and others.

Linux shells are so unbelievably painful.

I switched over to powershell and the quality of life improvements have been amazing.

Perhaps you haven't tried fish shell? https://fishshell.com/

Reply on news.ycombinator.com