I'm attempting to write a strictly POSIX-compliant shell, but [the standard](https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap01.html) doesn't make it clear how to go from bytes to characters. It says to use [LC_CTYPE](https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap07.html#tag_07_03_01) , which further links to the concept of a [charmap file](https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap06.html#tag_06_04) , but nowhere is it stated where these charmap files are located and how to read them. man 5 charmap says they are _usually_ located in /usr/share/i18n/charmaps, but that isn't enough for me. Also, on my Linux system, the files in that directory are gzip-encoded, which I think might be non-compliant, but I haven't found anything about it anywhere. I'm thinking that there must be some standard C utilities to get the details of the current character encoding (otherwise how could anyone ever use it?), but I wasn't able to find anything of the sort in my web search. There are the [setlocale](https://pubs.opengroup.org/onlinepubs/9799919799/functions/setlocale.html) and [nl_langinfo](https://pubs.opengroup.org/onlinepubs/9799919799/functions/nl_langinfo.html) functions, the latter of which can give you the _name_ of the currently used character encoding, but that doesn't help me with decoding it.\ Or am I supposed to know and implement all of them in advance?

I used to use the somewhat whimsical en_DK.UTF-8 locale when installing a new system because that would produce (roughly) the locale results I wanted, even though I am not in Denmark. * Measurements metric * Sensible date and time formats, but day and month names in English * 24-hour time format * Work week starts on Monday * Numeric date in (something at least resembling) ISO format, yyyy-mm-dd * Informal date is dd/mm, not the other way around * A4 paper size * Euro currency * System messages in English Alas, Ubuntu and Debian no longer seem to support the en_DK locale. I have been thinking there should be something like en_EU for "Euro English". Every place I have worked has had this sort of requirement -- the official language of the organization is English, but we want continental European defaults for everything else. I am imagining I am not the first person to think that a "location agnostic" English locale would benefit both me personally and the organizations I work for. So why does it not exist, and where do I look for further discussions and rationale? ... Or should I go ahead and propose it? To whom?

How can I configure the **environment** of a systemd based Linux system to display the date system-wide in the format yyyy-mm-dd? This date format adheres to the specifications defined ISO 8601 and RFC 3339 .

I have a few directories that I downloaded from an IMAP server. Example:

$ find . -maxdepth 1
.
./&BCEEPwQwBDw-
./&BCMENAQwBDsENQQ9BD0ESwQ1-
./inbox
./&BCcENQRABD0EPgQyBDgEOgQ4-
./&BB4EQgQ,BEAEMAQyBDsENQQ9BD0ESwQ1-
./&BBgEQQRFBD4ENARPBEkEOAQ1-
./Archive

These are Cyrillic names encoded in UTF-7. As far as I understand, utf-7 encoding units are all valid Unicode codepoints <127, at the same time valid ASCII. This means that I can copy, paste, pipe and cat them wherever I want. Let's do a conversion:

$ ls | iconv -f utf7 -t utf8
&BB4EQgQ,BEAEMAQyBDsENQQ9BD0ESwQ1-/
&BBgEQQRFBD4ENARPBEkEOAQ1-/
&BCEEPwQwBDw-/
&BCMENAQwBDsENQQ9BD0ESwQ1-/
&BCcENQRABD0EPgQyBDgEOgQ4-/
Archive/
inbox/

Wat? No effect? iconv -l lists both utf-7 and utf-8. What's wrong?

I am trying to grow GPT table for enlarged QEMU virtual disk. But when running

, it throws:

~ growpart /dev/sda 2
unexpected output in sfdisk --version [sfdisk，来自 util-linux 2.36.2]

Where is it wrong?

I switched my system from Debian 10 to 11 (new computer), so I'm trying to revert to my normal settings. I have installed with en_US locale, which I do want for UI texts, but I need to revert to ISO formats, like "normal" dates with 4-digit years, 24 hours, millimetres, centimetres, A4 page format etc. I open the Gnome "Region & Language" settings, but I can't seem to be able to install a new format. IIRC, I had used en_DK before, which is basically a neutral English but good date, time, and unit formats. How do I add en_DK in my new system for Gnome - only the formats part of Region & Language?

I'm seeing a weird behavior of the sort command when I sort by en_US.UTF-8. I'm trying to sort this file (LC_COLLATE=en_US.UTF-8 sort testdata): >㐀 > >㐃㐄 > >▼▽◢ > >㎏㎜㎝ > >ｂｑｚ > >ㄠㄨㄩ─┃┆ > >◆□■△ > >ぁあぃい > >┻╋┠┯┨ > >꓃꓄꓆꒺꒻ > >々—～‖…‘” > >龷𡗗龸𢦏龹龺𤇾龻 > >𠀀𠀁𠀂𠀃𠀄𠀅𠀆 > >⺁⺄⺈⺋⺌⺗⺧⺪⺮⺳⺶⺷⺻⻊ > >mario > >david > >且 > >丁 > >㐀丁 > >㐂 > >㐀且 > >嗄 > >阿 What happens is that the "mario" and "david" strings are sorted in the correct order, but the other characters are left in place. I would expect to see "david", "mario" and after them all the other strings. Is this the expected behavior?

I'm trying to produce translation files from C sources with translation entries coming in the exact same order as they appear in the sources. I do **not** want them sorted alphabetically, or coming in random order, as some strings are sorted in a domain-specific order which must be kept. I have the following test file: char * elements[] = {gettext("Hydrogen"), gettext("Helium"), gettext("Lithium")}; I'm using xgettext -F test.c, which according to the [documentation](https://linux.die.net/man/1/xgettext) is supposed to sort by location: >-F, --sort-by-file

sort output by file location

However, the output appears to be sorted alphabetically:

#: test.c:1
msgid "Helium"
msgstr ""

#: test.c:1
msgid "Hydrogen"
msgstr ""

#: test.c:1
msgid "Lithium"
msgstr ""

Could someone explain how -F (and -s, which is supposed to sort alphabetically) work, exactly? Did I miss a flag which sorts by location inside a single line?

I'm looking for a Hindi transcription tool in Linux. For English, VOSK is pretty good since it recognizes both Indian and US English. Is there anything that any agency (like C-DAC) under the Govt. of India has developed? Please help me.

I am using Manjaro Linux with everything up to date. In my taskbar, I have the following: Is there a way I can change the flag associated with a language selection? I want to keep the language but only change the flag. I'm not sure if this is doable, but I thought I'd ask.

I have found a number of questions on various forums where Mac users complain about locale errors when they log in to Linux systems over SSH which complain that the LC_CTYPE=UTF-8 setting is incorrect. In some more detail, the shell on MacOS seems to set this value, and then (if you have the option enabled in Terminal, or etc) your local LC_* variables get exported to the remote system when you SSH in. Linux insists that LC_CTYPE needs to be set to a valid locale (sometimes you can fix this with localegen as admin on the Linux system) but UTF-8 is not a locale in the first place. My _primary_ question is, is this a bug in MacOS? Or is Linux wrong in insisting that the variable needs to be set to a fully specified locale name? Secondarily, in order to be able to argue which one is correct and why, where is this specified? Tertiarily, is there something these Mac users (myself included) could or should do differently? The obvious workaround is to put something like LC_CTYPE=en_US.UTF-8 in your .bash_profile, but this obviously only solves it for your personal account, and hardcodes a value which may or may not agree with your other locale settings.

My language, Guarani, uses G̃/g̃ to denote the nasalized velar approximant. I thought I'd be able to type it by combining a dead tilde with g, but this does not work. Why doesn't it, and how can I fix it? My main suspicion is that this has to do with the fact that there is no separate Unicode character for g̃, just g with the combining tilde. I can type ỹ and ṽ just fine, but not j̃, r̃, m̃, which seems like good evidence that therein lies the problem. So one way I could get around this would be to map a key to 0x1000303 (which is U+0303, or ◌̃ ), the combining tilde, instead of to dead_tilde. However, this creates several problems: - If I switch to using the combining tilde in all cases: - I end up typing e.g. n + ◌̃ in many cases where the single character ñ is expected, and they have different results. For example, I've noticed that certain websites won't display the same search results if I type one vs. the other (obviously that's on them, but I want a keyboard layout that works with the world as it exists now). - It's annoying that I have to backspace twice to delete characters with the combining tilde, which I can accept if it's only for the g̃, but it's a little much with every nasalized character. - If I add both, which is what I'm currently doing, this becomes really hard for usability, because: - I have to think in each case about which key to use, when my brain thinks of them as the same - The mechanics of typing the two are different, since dead_tilde is pressed before a character, whereas ◌̃ goes after. My poor little brain will never get used to that. It seems like in the ideal scenario I'd have X notice that dead_tilde + g doesn't work and just process it as if I'm typing g + ◌̃, and enter the two characters for me together, as it does for ñ, ã, ẽ, ĩ, õ, ũ, ỹ, etc. It's worth noting that it's not possible to get around this by adding the g̃ directly to my keyboard layout, as xkb doesn't seem to support mapping a key to a combined Unicode glyph (though see the answer to https://unix.stackexchange.com/questions/43073/custom-xkb-layout-in-which-one-key-creates-two-unicode-code-points for a hacky workaround). If I could fix that, I suppose this would be much less of a problem. I'm running Ubuntu 18.04, not sure what other background info would be helpful, but I assume this is a problem for anyone running X. ### Edit 1: Editing Compose mappings doesn't work Another thing I've tried, which also did not work, is editing the Compose mappings to add a composed g̃. I wrote an .XCompose file as follows: include "%L" : "g̃" gtilde : "G̃" Gtilde But this also did not work, I assume for the same reason above: X expects a single character, and g̃ is technically two. Incidentally, I noticed a number of mappings shipped in my locale's default Compose file also don't work, presumably for the same reason. The following mappings for en_US.UTF-8, and perhaps many more, actually do nothing: : "ã́" # LATIN SMALL LETTER A WITH TILDE AND ACUTE : "ã̀" # LATIN SMALL LETTER A WITH TILDE AND GRAVE : "Ã́" # LATIN CAPITAL LETTER A WITH TILDE AND ACUTE : "Ã̀" # LATIN CAPITAL LETTER A WITH TILDE AND GRAVE : "ẽ́" # LATIN SMALL LETTER E WITH TILDE AND ACUTE : "ẽ̀" # LATIN SMALL LETTER E WITH TILDE AND GRAVE : "Ẽ́" # LATIN CAPITAL LETTER E WITH TILDE AND ACUTE : "Ẽ̀" # LATIN CAPITAL LETTER E WITH TILDE AND GRAVE : "ĩ́" # LATIN SMALL LETTER I WITH TILDE AND ACUTE : "ĩ̀" # LATIN SMALL LETTER I WITH TILDE AND GRAVE : "Ĩ́" # LATIN CAPITAL LETTER I WITH TILDE AND ACUTE : "Ĩ̀" # LATIN CAPITAL LETTER I WITH TILDE AND GRAVE : "õ̀" # LATIN SMALL LETTER O WITH TILDE AND GRAVE : "Õ̀" # LATIN CAPITAL LETTER O WITH TILDE AND GRAVE : "ũ̀" # LATIN SMALL LETTER U WITH TILDE AND GRAVE : "Ũ̀" # LATIN CAPITAL LETTER U WITH TILDE AND GRAVE : "m̀" # LATIN SMALL LETTER M WITH GRAVE : "M̀" # LATIN CAPITAL LETTER M WITH GRAVE As a matter of opinion, I do not think this is what we should fix: adding an extra line to Compose files for every possible diacritic just seems wasteful, and is not taking advantage of the simplicity of the nice combining diacritics Unicode wants us to use. An interesting thing I noticed before I removed this .XCompose is that launching GTK programs from the terminal would result in the following errors: (gedit:7229): Gtk-WARNING **: 23:03:04.848: GTK+ supports to output one char only: "g̃" gtilde: : "g̃" gtilde So presumably this is a GTK issue? I'll continue trying to track it down, but would appreciate any help. ### Edit 2: Relevant GTK issue It seems like my solution would be to fix this: https://gitlab.gnome.org/GNOME/gtk/-/issues/186