Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Art of Command Line

github.com

Post reply on HN
Print view View original

21–30 of 134 posts

Re: The Art of Command Line

#21

Post by zalzal »

thristian wrote: post #12
scrollaway wrote: post #5

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

Some environments support a locale named "C.UTF-8" - with the same familiar sorting and formatting rules as the C locale, but with proper UTF-8 support.

Using C locale is useful when processing very large data files in a shell, e.g. on a server. For example, uniquing or set difference will work many times faster (and doesn't require the slow/fancy collation calculations). But yes, it's a good point, of course it shouldn't be used on your desktop globally or apps will break. I'll clarify that.

Re: The Art of Command Line

#22

Post by cle »

binarycrusader wrote: post #6
scrollaway wrote: post #5

> 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 to reiterate this; don't do it -- sort order changes and you'll run into other mysterious issues. It's not worth the "performance improvement".

In some cases, it certainly is worth the improvement. Performance improvements translate into $$$.

Knowing that "LC_ALL=C can improve performance but cause UTF problems" is awesome information to base a design on. A blanket statement like "never use LC_ALL=C" is not.

Re: The Art of Command Line

#23

Post by karmicthreat »

So 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.

Re: The Art of Command Line

#25

Post by _jal »

jwcrux wrote: post #14

> 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".

Agree. I've been hearing people saying the command line is archaic since Windows 95, and probably before that. Yet somehow I (any everyone I work with, and have worked with over the past 25 years) still works in a shell daily. I don't understand how someone on the technical end of running large internet services could avoid it.

Sure, GUI tools have crept in here and there. And I understand that some toolchains mandate all-singing, all-dancing IDEs. I don't work in those areas (the closest I've come was doing Java work for about five years and I still lived in vi, because Eclipse makes me homicidal). And I still see our iOS developers using `find' and `sed'.

Which isn't to say GUIs can't improve on the command line for some things. For example, the MacOS tool "A Better Finder Rename" (despite its inability to rename itself something less clunky) is a great tool for mass-renaming, e.g., photos. I have written such critters before as shell/perl/python scripts, but pulling EXIF data and renaming files programmatically is ticky and potentially destructive enough that I tend to write it once and then not modify it unless it breaks. The GUI preview and regex capture display makes this much less annoying.

Re: The Art of Command Line

#26

Post by cmrx64 »

thristian wrote: post #12
scrollaway wrote: post #5

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

Some environments support a locale named "C.UTF-8" - with the same familiar sorting and formatting rules as the C locale, but with proper UTF-8 support.

Setting LC_COLLATE=C and leaving the rest to a proper locale can often win you what you want without losing much.

Re: The Art of Command Line

#27

Post by gchpaco »

stass wrote: post #20
scrollaway wrote: post #5

> 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 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 good North American names like Étienne let alone perfectly good older-than-the-country names like Þórr) b) it's unlikely to be true even for you as you will discover the first time you try to read a file written by somebody else c) it promotes intellectual laziness that makes later internationalization efforts difficult to impossible, because they're trying to convince people like you to care about stuff they find inconvenient but that is of vital importance to your customers.

I know of a man whose first name is Þórr who outright refuses to deal with any organization that will not let him write his name, and I have a hard time disagreeing with him.

Re: The Art of Command Line

#28

Post by School-Cotton »

cbd1984 wrote: post #4

There's no reason to learn vi if you know Emacs. If you claim that Emacs isn't installed everywhere, guess what: Neither is vi. If you want an "installed everywhere" editor, learn ed. If you're willing to take an editor with you (or otherwise make sure a specific editor is everywhere you are), there's no reason it has to be vi.

I can't remember ever encountered a unix-like system without "vi" installed. I've used (and set up) machines running FreeBSD, DragonflyBSD, OSX, Ubuntu, Debian, RHEL, ...

Plenty of those didn't have emacs, especially on first boot, when you're most likely to need to modify network configuration files in order to get online to install new packages in the first place...

Edit: By "vi" I mean that somewhere in the path there is a program called vi. Of course, usually this is nvi, vim, evil, etc; I don't mean the original UNIX vi binary.

Re: The Art of Command Line

#29

Post by elchief »

karmicthreat wrote: post #23

So 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.

Re: The Art of Command Line

#30

Post by endgame »

shabble wrote: post #13
kec wrote: post #9

Earlier quoted context omitted.

vi is a posix requirement, emacs is not. If the system you're working on has ed, it'll have some version of vi or vim as well.

and not having to know ed is an excellent reason to learn vi :) obCompulsoryEdJoke: https://www.gnu.org/fun/jokes/ed-msg.html

a

I learned ed for a joke and found myself actually liking some features so much that I started porting them to emacs.

.

w

Post reply on HN