Live data from Hacker News

The Art of Command Line

github.com

61–70 of 134 posts

Re: The Art of Command Line

#62

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

Raised https://github.com/jlevy/the-art-of-command-line/issues/22

Re: The Art of Command Line

#63
post #49

Earlier quoted context omitted.

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

Ubuntu 14.04, the default Ubuntu on EC2, definitely comes with vi.

Yeah, I'm guessing cbd1984 is confusing it with 'vim'.

Re: The Art of Command Line

#64
Unix tools are very powerful, but they are not as intuitive as I would like. It would be nice if we can have an httpie for process management, one for text manipulation, another for system stats, and so on.

Re: The Art of Command Line

#65

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

The discussion here has tended to focus on either one or the other of two different facts:

You absolutely need to be aware of and manage language and locale settings diligently. This is a big topic, but generally, whenever possible, use UTF8. And you generally don't want to change your desktop OS or applications' locale or language settings other than that.

However, if you are processing data files and are aware of the implications, and can get away with treating data as binary instead of character streams -- for example, any of the command sequences that use sort/uniq for uniqueness or set union/intersection/difference -- then using C locale is way faster. As in, the difference between doing something in an hour on a big machine and rewriting a whole pipeline in Hadoop. A good fact to know.

It's obvious I (the author) didn't make the simultaneous truth of both these points clear. I'll rewrite.

Re: The Art of Command Line

#66

> To locate a file by name in the current directory, find -iname something . (or similar). To find a file anywhere by name, use locate something (but bear in mind updatedb my not have indexed recently created files). I think this will glob unless you escape the asterisks. Also on my system (debian 8) I need to put the directory to search first, or not at all: find . -iname \ something\ find -iname \ something\ edit:…

  edit: hackernews ate all my asterisks
Well that solved the mystery.

Re: The Art of Command Line

#67
I'd never even thought about commenting a line I was half way through writing, when suddenly realising I'd forgotten the correct arguments.

I normally end up opening another terminal and using man there.

Re: The Art of Command Line

#68

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

Raised https://github.com/jlevy/the-art-of-command-line/issues/22

Thanks! Didn't think of filing it as an issue.
Post reply on HN