> Fluency on the command line is a skill that is in some ways archaic... I don't see this to be the case at all. Plus, having this be the opening line may cause people to equate archaic=I don't need this. I'd suggest (would pull request but afk) that you remove "is a skill that is in some ways archaic".
The Art of Command Line
31–40 of 134 posts
Re: The Art of Command Line
#32So this is tangentially related by why do people seem to push Vi? Nano is a perfectly serviceable editor. If I need to do extensive editing I always end up loading it into Atom, Sublime or some other editor anyway. I've never really had to use a console editor for more than 10s of lines.
vi keybindings are ubiquitous, so familiarity with the editor is beneficial outside the editor. Just offhand, both ncdu and tig (which I have used in the past hour) respond to vi keystrokes.
It's not as hard as it first seems to learn, either. Well worth the time spent, vi is worlds more powerful than nano.
Re: The Art of Command Line
#33So this is tangentially related by why do people seem to push Vi? Nano is a perfectly serviceable editor. If I need to do extensive editing I always end up loading it into Atom, Sublime or some other editor anyway. I've never really had to use a console editor for more than 10s of lines.
"I don't understand why everyone doesn't do things exactly like I do using only tools I like" is a really stupid way to look at the world.
Re: The Art of Command Line
#34The author should prepare to catch some hell for advocating 'ForwardAgent=yes' in ssh configs.
I had meant to take another look at ProxyCommand (http://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-cons...), so thanks for the reminder!
Re: The Art of Command Line
#35> To disable slow i18n routines and use traditional byte-based sort order, use export LC_ALL=C (in fact, consider putting this in your ~/.bashrc). Do not. Having a non-utf8 locale means you won't be able to handle utf-8 sanely ("that's why it's faster") and it will break at the most inexplicable times. Any non-latin1 character appearing in your prompt or command line with this will mess its spacing up for example. Do…
I have the following set in my .cshrc:
setenv LC_ALL en_US.UTF-8
setenv LC_COLLATE C # use the ASCII sort order
Re: The Art of Command Line
#36So this is tangentially related by why do people seem to push Vi? Nano is a perfectly serviceable editor. If I need to do extensive editing I always end up loading it into Atom, Sublime or some other editor anyway. I've never really had to use a console editor for more than 10s of lines.
nano is super easy to use, I agree. I tried vim and gave up. Will try again.
I find it a bit irksome that when discussing command line editors, the dichotomy appears to be be "nano vs vim".
There are other CLI editors. I'm quite partial to ne (the Nice Editor), which has more manageable shortcuts than emacs, a command line (it's still a non-modal editor, to be clear), macros and syntax highlighting. Also jed is not bad. While vim (and nvim) have advantages, and certainly benefit from being ubiquitous and having ther shortcuts replicated in other programs, users should shop around, even on the command line.
Re: The Art of Command Line
#37Earlier quoted context omitted.
The question is, do you need to handle UTF-8? In most cases of sever management having LATIN1 would suffice, or appropriate localized 8-byte encoding. You can apply the same argument to any other obscure encoding scheme, not just UTF-8. The answer is really to pick the encoding which will suite the most usecases and won't be painful to use.
How is ASCII or Latin-1 somehow not an obscure encoding scheme by your parlance? Latin-1 is less common by quite a bit on the web than UTF-8, and ASCII might be if UTF-8 wasn't a superset. Fact of the matter is people have to get out of the habit of going "oh, that will never be relevant for me", because a) that's unlikely to be true for everybody (for example in a server environment you can't even write perfectly go…
The original question was about the command line. When managing servers it's perfectly accessible to use LATIN1 if one does not expect to deal with UTF-8 data (examining processes, VM states, changing configuration, etc). If that's not the case, one can use UTF-8 or some other encoding for that matter (i.e. I routinely have to deal with non-UTF non-ASCII filenames and text, using UTF-8 won't cut here either).
Re: The Art of Command Line
#38If you learn bash, and you learn vi, then the next most glorious addition is: set -o vi Then you have vi keys in your shell. And it is marvelous.
Learning about this was a revelation for me. I can't live without it now.
Re: The Art of Command Line
#39So this is tangentially related by why do people seem to push Vi? Nano is a perfectly serviceable editor. If I need to do extensive editing I always end up loading it into Atom, Sublime or some other editor anyway. I've never really had to use a console editor for more than 10s of lines.
Nano is fine for 10s of lines, but Vim is great for much much more than that. It's also nice to have the same keybindings for every console app (gosh I love readline), and it's repeat commands make editing text an absolute breeze. Why open another editor on my host if I can edit the file in my console on a remote server?
Re: The Art of Command Line
#40 cat hosts | xargs -I{} ssh root@{} hostname
echo y | xargs -Ix echo x