Hot answers tagged

394

LC_ALL is the environment variable that overrides all the other localisation settings (except $LANGUAGE under some circumstances). Different aspects of localisations (like the thousand separator or decimal point character, character set, sorting order, month, day names, language or application messages like error messages, currency symbol) can be set using ...


243

It forces applications to use the default language for output: $ LC_ALL=es_ES man ¿Qué página de manual desea? $ LC_ALL=C man What manual page do you want? and forces sorting to be byte-wise: $ LC_ALL=en_US sort <<< $'a\nb\nA\nB' a A b B $ LC_ALL=C sort <<< $'a\nb\nA\nB' A B a b


87

en_IE.UTF-8 English (Ireland) locale has all the things you're asking for: Measurements metric — yes 24-hour time format — yes Work week starts on Monday — yes Numeric date in (something at least resembling) ISO format, yyyy-mm-dd — no, it this locale it's dd/mm/yy. But that seems close enough to what you're used to Informal date is ...


84

Debian ships locales in source form. They need to be compiled explicitly. The reason for this is that compiled locales use a lot more disk space, but most people only use a few of them. Run dpkg-reconfigure locales as root, select the locales you want in the list (with your settings, you need en_GB and en_US.UTF-8 — I recommend selecting en_US and en_GB.UTF-...


70

Note that when using range expressions like [a-z], letters of the other case may be included, depending on the setting of LC_COLLATE. LC_COLLATE is a variable which determines the collation order used when sorting the results of pathname expansion, and determines the behavior of range expressions, equivalence classes, and collating sequences within ...


68

No, it doesn't consider them as equivalent, they just have the same primary weight. So that, in first approximation, they sort the same. If you look at /usr/share/i18n/locales/iso14651_t1_common (as used as basis for most locales) on a GNU system (here with glibc 2.27), you'll see: <U0065> <e>;<BAS>;<MIN>;IGNORE # 259 e <U025B>...


43

Ask locale: locale decimal_point This will output the decimal point using the current locale settings. If you need the thousands separator: locale thousands_sep


41

The same exact thing happened to me. Building on what Thomas said above, I was able to fix it by uncommenting en_US.UTF-8 UTF-8 in my /etc/locale.gen file (previously none of the lines had been uncommented), then running locale-gen.


34

locale-gen is not present in Centos/Fedora. You must use localedef: localedef -v -c -i en_US -f UTF-8 en_US.UTF-8 From man localedef: NAME localedef - define locale environment SYNOPSIS localedef [-c][-f charmap][-i sourcefile][-u code_set_name] name DESCRIPTION The localedef utility shall convert source definitions for locale cate‐...


32

Locale settings are user preferences that relate to your culture. Locale names On all current unix variants that I know of (but not on a few antiques), locale names follow the same pattern: An ISO 639-1 lowercase two-letter language code, or an ISO 639-2 three-letter language code if the language has no two-letter code. For example, en for English, de ...


32

You've tried to apply a recipe for Ubuntu under Debian. That usually works, but in this specific case it doesn't. Ubuntu is derived from Debian, and doesn't change much apart from the installer and the GUI. The locale-gen command is one of those few other things that it changes. I don't know why. Under Debian, the locale-gen command takes no arguments and ...


29

That's a consequence of those characters having the same sorting order. You'll also notice that sort -u << EOF ■ ⅕ ⅖ ⅗ EOF returns only one line. Or that: expr ■ = ⅕ returns true (as required by POSIX). Most locales shipped with GNU systems have a number of characters (and even sequences of characters (collating sequences)) that have the same ...


26

You can first remove all unneeded locales by doing: $localedef --list-archive | grep -v -i ^en | xargs localedef --delete-from-archive Where ^en can be replaced by the locale you wish to keep Then $build-locale-archive If this gives you an error similar to $build-locale-archive /usr/sbin/build-locale-archive: cannot read archive header Then try this ...


25

[A-Z] in bash matches all collating elements (characters but call also be sequence of characters like Dsz in Hungarian locales) that sort after A and sort before Z. In your locale, c probably sorts in-between B and C. $ printf '%s\n' A a á b B c C Ç z Z Ẑ | sort a A á b B c C Ç z Z Ẑ So c or z would be matched by [A-Z], but not Ẑ or a. $ printf '%s\n' A a ...


25

LANG sets the default locale, i.e. the locale used when no more specific setting (LC_COLLATE, LC_NUMERIC, LC_TIME etc.) is provided; it doesn’t override any setting, it provides the base value. LC_ALL on the other hand overrides all locale settings. Thus to override scripts’ settings, you should set LC_ALL. You can check the effects of your settings by ...


24

The top-rated solution didn't help in my case, so I used this one: export LC_ALL="en_US.UTF-8" sudo dpkg-reconfigure locales After that, I logged out and logged in and error was missing.


24

I also had this same issue (Arch XFCE). Basically what happens is it switches input methods whenever you press Shift+Space, which frequently accidentally happens when typing. To fix this, you have to change or remove this hotkey: In a terminal window, type uim-pref-gtk, which is the settings for the UIM input method. Go to the Global key bindings 1 section. ...


22

It seems that no locale is generated. Have you selected pl_PL.UTF-8 properly in dpkg-reconfigure locales by pressing space in the corresponding line? If yes, the line pl_PL.UTF-8 UTF-8 in /etc/locale.gen is not commented (= does not start with #). If you need to fix this, you need also to run locale-gen to generate the locales. Its output should be: ...


21

The char type in C is one byte, but it's intended for ASCII characters; there are variable-width encodings like UTF-8 that can take up many bytes per character. wc uses the mbrtowc(3) function to decode multibyte sequences, depending on the locale set by the LC_CTYPE environment variable. If you set the locale properly, you should get the same result for all ...


17

(a) An entity known as the Unicode Common Locale Data Repository seems to be the place that handles locales. The glibc wiki indicates that they will follow CLDR. (b) They have a locale known as "en_150" which seems to be intended to do what you want. I'm not sure glibc has implemented it yet. There's also a similar locale known as en_BE which is identical ...


17

Change the character translation in PuTTY to UTF-8.


16

At a guess, Your locale uses UTF-8 encoding, and About 10% of your file consists of characters which require more than one octet to encode into UTF-8. By the way, from man wc: -c, --bytes print the byte counts -m, --chars print the character counts


16

You can set any locale category independently. LANG applies only to the categories that are not explicitly set. LANG and LC_xxx are ordinary environment variables. They are not settings for the locale utility: the locale program isn't involved in any locale processing, it's just a small utility to report current and available locale settings. When you ...


16

en_DE doesn’t exist as a default locale, so you can’t select English localised for German-speaking countries as a locale during installation. (Why should one use update-locale instead of directly setting LANGUAGE? describes the checks involved in choosing a locale.) There are two approaches to achieve what you’re after. One is to create a new locale with ...


15

The primary issue here -- which accounts for why, e.g., $PS1 is not reported by env -- is that env is reporting from a non-interactive environment. Processes are executed from a fork of your interactive shell, but there's a subtlety involved in how their environment is set: It's actually inherited via a native C level external variable set for all exec()'d ...


15

The string comes from strerror(3), which maps error numbers to messages. In this case, it's mapping EACCES. The strings (and their translations) are contained in your C library.


15

man sort: *** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values. So, try: LC_ALL=C sort file.txt


14

All of: tr '[:lower:]' '[:upper:]' (don't forget the quotes, otherwise that won't work if there's a file called :, l, ... or r in the current directory) or: awk '{print toupper($0)}' or: dd conv=ucase are meant to convert characters to uppercase according to the rules defined in the current locale. However, even where locales use UTF-8 as the character ...


14

Never mind, I was just using it wrongly. From info localectl: ...this [command] takes one or more assignments such as LANG=en_US.utf8


14

ssh will forward "some" environnement var from mirind4-pc to raspberry, among them "locale" variable (which are use to print friendly date and number). According to misc link on Raspian and Ask Unbuntu you may need to generate local locale. From what I guess sudo locale-gen de_DE.UTF-8 sudo dpkg-reconfigure locales you can check immediatly afer using foo:...


Only top voted, non community-wiki answers of a minimum length are eligible