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

121–130 of 134 posts

Re: The Art of Command Line

#121

Post by binarycrusader »

cle wrote: post #22
binarycrusader wrote: post #6

Earlier quoted context omitted.

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.

Short of a bug or other pathological issue, if you resort to messing with locale just to avoid a performance problem, you're likely to hide other issues that will cause problems whenever another user attempts to do the same thing and it breaks.

Again, not worth it -- if only for performance sake, generally speaking.

Re: The Art of Command Line

#122

Post by MachinaX »

tomaac wrote: post #83
MachinaX wrote: post #8

The Linux Command Line (free pdf): http://linuxcommand.org/tlcl.php

Hosted on Sourceforge which is now blocked almost everywhere.

You're exactly right tomaac. Thank you for your comment.

The reason: http://arstechnica.com/information-technology/2015/05/source...

Re: The Art of Command Line

#123

Post by stass »

scrollaway wrote: post #45
stass wrote: post #37

Earlier quoted context omitted.

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

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

There are multiple issues you are dealing with here. First, no tools "will output UTF8 if they think that's a good idea". All properly designed application are required to respect the LANG setting (or equivalent LC_XXX environment variables) and use character encoding specified in them. This is the basis of character encoding support in most (all?) modern UNIXes. There's no risk running with LANG set to something other than en_EN.UTF-8 when using properly implemented software (most of it), and as a matter of fact a lot of UNIX variants has C as default (actually, the only two I know which don't are Linux and OS X). I have been running with LANG set to C (or KOI8-R on OS X) on FreeBSD, Linux and OS X for more than 10 years, and yet to hit the problem. Now, there are always issues with dealing with UTF-8 data (or different 1 byte encoding to a lesser extent), but see below.

Second, you keep treating UTF-8 as some special encoding (ein OS, ein encoding?), but it's certainly not. Even if you are using UTF-8 as a system encoding, you are going to have problems dealing with non-UTF8 data, and it's actually going to be worse than dealing with UTF-8 when using LATIN1. Mind you, most systems don't use UTF-8 as default encoding: most Linux distributions do, but Windows uses UTF-16, Mac OS X has it's own somewhat incompatible version of UTF-8, Java is UTF-16, and so on. One will have problems dealing with all these systems if his encoding is set to UTF-8.

Lastly, the Python example is not really representative. Some language implementations have better support for multi-byte encodings, and some worse. Ruby, for example, has a very good support for dealing with UTF-8 data even when not using it a system encoding.

Re: The Art of Command Line

#124

Post by scrollaway »

unhammer wrote: post #94
Wonnk13 wrote: post #19

pretty good writeup. Learning nohup was a life changing experience for me.

there's also disown. It's a bash builtin, so you'll have to type "help disown" ("man disown" gets you nothing). E.g. to run touchegg and close your terminal, keeping touchegg running: touchegg & disown; exit

I use an alias for it:

    function launch {
    	type $1 >/dev/null || { print "$1 not found" && return 1 }
    	$@ &>/dev/null &|
    }
    alias launch="launch "

Re: The Art of Command Line

#126

Post by unhammer »

scrollaway wrote: post #124
unhammer wrote: post #94

Earlier quoted context omitted.

there's also disown. It's a bash builtin, so you'll have to type "help disown" ("man disown" gets you nothing). E.g. to run touchegg and close your terminal, keeping touchegg running: touchegg & disown; exit

I use an alias for it: function launch { type $1 >/dev/null || { print "$1 not found" && return 1 } $@ &>/dev/null &| } alias launch="launch "

why the alias as well as the function?

Re: The Art of Command Line

#127

Post by anc84 »

natch wrote: post #112
willthames wrote: post #102

Earlier quoted context omitted.

Or seq -f %04g 1 10

Sure seq is OK, but jot does everything seq does and more, so I prefer jot. # generate 10 random numbers between 1 and 1 million jot -r 10 1 1000000

I meant to go all "just use coreutils, there is shuf available already, no need for some third-party tool" but then I realised that jot is an integral part of BSD. Rock on! :)

For us Linuxers: shuf -i 1-1000000 -n 10

Re: The Art of Command Line

#128

Post by scrollaway »

unhammer wrote: post #126
scrollaway wrote: post #124

Earlier quoted context omitted.

I use an alias for it: function launch { type $1 >/dev/null || { print "$1 not found" && return 1 } $@ &>/dev/null &| } alias launch="launch "

why the alias as well as the function?

https://wiki.archlinux.org/index.php/Sudo#Passing_aliases

Re: The Art of Command Line

#130

Post by wodenokoto »

gchpaco wrote: post #27
stass wrote: post #20

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

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

How does he fly? All flights I've ever been on have required me to ASCII-fy my name.

Post reply on HN