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";
}
mkcd a b c103 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...
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!
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.
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
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.