The Art of Command Line

Depends on your circumstances, really. If you're in an environment with lots of VM's floating around, being created, destroyed, and so on, dealing with SSH's paranoia (why can't I just dismiss a warning about a host/key mismatch instead of having to edit .known_hosts?) quickly becomes an exercise in frustration for dubious security benefit. (If the enemy is on your LAN and able to manipulate your DNS, you've already lost)

On your home box, sure. But let's not pretend there's not a reason for the option to exist.

Can you share a little more info about this? I tried it but found it rather confusing.

Also, for more readline maneuvers: http://unix.stackexchange.com/questions/21788/how-to-delete-...

> if one does not expect to deal with UTF-8 data

This is a horrible assumption. UTF8 can show up just about anywhere. 99% of the utilities mentioned in the article support UTF8, which means they will output UTF8 if they think that's a good idea. And that can show up at any point. Exotic filenames, error messages, fancy boxing or indicative characters in the output...

Don't expect Latin-1, ever. Respect specified encodings, and default to UTF8. Never, ever think you'll be fine with Latin-1 when dealing with an UTF-8 output just because you speak english.

The trick the original article specified is a hack to get better performance in very controlled situations, it should never be put in a rc file like it recommends because it will break and you won't know that is what's causing it.

Edit: Here's a few examples of very real potential breakage, to show you how bad an idea this is: You're debugging a python script. You open a python shell and start pasting some of its lines to figure out what's happening. OOPS, there's UTF-8 in there.

    [4:08:48] adys@azura ~ % python -c 'print("I like the letter Š")' 
    I like the letter Š
    [4:08:54] adys@azura ~ % LANG=C python -c 'print("I like the letter Š")'
    Unable to decode the command from the command line:
    UnicodeEncodeError: 'utf-8' codec can't encode character '\udcc5' in position 25: surrogates not allowed

(The input doesn't even have to be explicit, by the way, it could even be in your filenames).

Should I keep going? See how "awk '{print tolower($0)}'" behaves when it's dealing with utf-8 input. Maybe that awk is deeply hidden in a 5000 line script. Maybe it deals with web data, filenames, anything. And suddenly you have unicode escapes in data that doesn't expect any.

Now how's that one line in your rc file, which you wrote maybe months or years ago, working out for you? Are you going to know the issue is your LC_ALL variable?

`set -o vi` allows us to use `vi` bindings instead of the default `emacs` bindings.

The way to think about it is that the prompt starts out in `vi insert mode` so whatever we type in will just be inserted at the prompt. However, we can hit the`Escape` key and move into `vi normal mode` where the keys are interpreted as normal `vi` commands. So, for example, once we hit `esc` we can navigate around the line using `h` and `l` and navigate history (previous lines) using `k` and `j`.

Commands I find very useful are:

`jk` : for history navigation

`bw`: for moving in the current line. These are word movement commands that are faster to navigate with.

`cw` : similarly, changing a particular word in the current line is also great. This works particularly well with history - retrieve a previous command and change a word or option

`dw` : for deleting the current word

`/` : is a fantastic command for searching history. `/cd` will bring up our last change directory command and just hitting `n` will cycle through all our change directory commands that are in history.

`AI` : to insert at the beginning/end of line

...and so on. If you have `vi` muscle memory it's a fantastic option for working on the shell.

(edit: Formatting)

> I can't remember ever encountered a unix-like system without "vi" installed.

Default Ubuntu install.