Previous significant discussions:

* https://news.ycombinator.com/item?id=19988548 (597 points | May 23, 2019 | 169 comments)

* https://news.ycombinator.com/item?id=9720813 (466 points | June 15, 2015 | 133 comments)

I say this as someone who has been heavily using the command line for the last decade, even if you "know" how to use a CLI decently well, go read this if you haven't. From only a couple minutes of reading I found not one, but two new tidbits that I never even considered looking up. This information will completely change my daily levels of frustration when using a CLI. Very, very high ROI link.

Nice write-up. Useful information even if you've been on the CLI for centuries.

I’ve been using the command line for almost 3 decades. This is really great! I found it covers basically everything I ever had to care about. Strikes a good balance in level of detail. Well done!

It's interesting how dev tools went from text-based 80s to GUI 90s and then back to text-based. As well as the terminal, think about Markdown vs WYSIWIG, Visual Studio/XCode vs Ruby on Rails, YAML config files vs XML with visual editor, etc.

Terminal is good because its unconstrained. But most of the time I would prefer a GUI interface.

We just need to blend the two approaches better and always have a terminal fallback.

> Use grep . * to quickly examine the contents of all files in a directory

I prefer to use grep '' * since grep . * omits empty lines.

> tail -f (or even better, less +F),

While “less +F” is useful, it will also eat all of your memory if left running.

Nice and short collection of useful commands. I am really surprised that there is only one very brief mention of GNU parallel.

Working at the Command Line is a superpower especially when combined with auto-suggestions from tools such as zsh + oh-my-zsh.

I would be completely lost if I didn’t have the auto suggestions as my “second brain” !

One problem though — to run a variant of an existing previous command, I find myself editing super long command lines, I.e bring up a previous command by accepting the auto-suggestion, then Ctl-b thru it and make an edit to run a new variant. This made me wonder: is there some tool that presents a TUI type of 2-dimensional interface that lets me navigate through the various options using arrow keys etc ?

> Learn basic Bash

In a way, true, but if you want to work in the corporate world, should be "learn ksh". Very little difference between them, and will force you to write portable scripts. Using bashisms will make things a bit harder for you.

Most proprietary software companies like to buy uses ksh. I support a few of them now where I work, all uses ksh.

Since the list mentions grep -o (--only-matching) and regex. Here is my preferred trick to extract a specific part of a line and circumvent the lack of capture groups in grep.

Imagine you have a line containing

  prefix 1234 suffix

and want to only grep the number but need to match prefix and/or suffix to not grep another unwanted number.

Can be solved with

  grep --only-matching --perl-regexp 'prefix \K\d+(?= suffix)'

The magic is '\K' which kind of resets the 'matched buffer'. [1] So anything before \K is matched but not outputted with -o (or without -o anything before \K would not be highlighted).

And for the suffix: (?=) is a positive lookahead [2] which checks if, in this case, ' suffix' is found after the number but also does not include it in the 'matched buffer'.

So the output for

  echo "prefix 1234 suffix" | grep --only-matching --perl-regexp 'prefix \K\d+(?= suffix)'

is only

  1234

PS: instead of \K the prefix could also be wrapped in a positive lookbehind (?<=prefix )

[1] https://perldoc.perl.org/perlrebackslash#%5CK

[2] https://www.rexegg.com/regex-lookarounds.html

In connection with history, you can use !$ for the last argument, but you can also use escape-dot. I use that quite a bit (and escape-dot is slightly easier to type than !$).

Also worth pointing out that you can modify the command in the history list before running it, by typing !xxx:p (adding :p instead of !xxx that just re-runs the command). Then I use arrow-up and then modify it before running it.

https://henrikwarne.com/2018/08/11/my-favorite-command-line-...

I look forward to reading this, but

> Bash is powerful and always available

As someone who often works with Alpine Linux, this is an annoyingly popular myth.

vimdiff can be quite cool when combined with <() bash feature (which presents command output as file).

e.g. see color difference of installed packages on local and remote server

    vimdiff <( dpkg -l | grep -w ii | awk '{print $2}' | sort -V ) <( ssh REMOTE_SERVER dpkg -l | grep -w ii | awk '{print $2}' | sort -V )

Please, can anyone provide guidance for making Win10 CLI UX tolerable? After more than 2 decades on macOS, very comfortable w/ customized zsh in iTerm, I'm now unavoidably working in Windows and hating it. Sad to discover my vague perception of Windows as a 2nd-class citizen (or 3rd-world country) is all too accurate. Running git-bash in Terminal, surfacing any meaningful git status in my $PS1 incurs multisecond latency. Surely there's a better way. Right?