Обновлён скрипт для pip'а, который дружит его с KOI8-R

Угадал автора по заголовку.

Ник nenuzhno свободен. Чего ждут модераторы? Пора уже называть героев своими именами.

Назови 3 причины зачем это нужно.

gopher://sdf.org/9/users/saahriktu/saahriktu.org/patches/patch_any_pip_for_koi8-r-0.1.sh.lzma (248 байт)

В браузере не открывается.

Я же написал одну, но вескую причину: это нужно чтобы собрать и установить Python с pip'ом при локали KOI8-R.

В браузере не открывается.

Качать так:

curl gopher://sdf.org/9/users/saahriktu/saahriktu.org/patches/patch_any_pip_for_koi8-r-0.1.sh.lzma > patch_any_pip_for_koi8-r-0.1.sh.lzma

а в апстрим приняли?

В апстриме UTF-8 во все поля.

понятно

Зачем тебе python 3.7, если есть прекрасный 2.6?

curl -O ты не используешь, тоже то-же из-за UTF-8 ?

Я же написал одну, но вескую причину: это нужно чтобы собрать и установить Python с pip'ом при локали KOI8-R.

Вот это зачем?

Я собираю коллекцию Python'ов:

> ls -1 /usr/bin/python?.?
/usr/bin/python1.6
/usr/bin/python2.7
/usr/bin/python3.7
>

Это нужно юзерам локали KOI8-R.

Суть не меняется.

Это нужно юзеру локали KOI8-R.

Поправил.

Отпишись, если тебе кто пришлёт «спасибо» за скрипт.

Как это. Байтов в строке меньше, это же ты их экономишь.

Зачем локаль KOI8-R? Это что за дистрибутив, где это – суровая необходимость?

Почему сразу «необходимость»? Это может быть свободный выбор юзера потому, что ему так удобнее.

У однобайтных кодировок много плюсов, а у юникода много минусов.

óÐÁÓÉÂÏ, ÐÏÌÅÚÎÙÊ ÐÁÔÞ!

Зачем локаль KOI8-R? Это что за дистрибутив, где это – суровая необходимость?

это сто раз обсуждали уже.

не, понятно что есть куча всего ненужно, сустемдики всякие, эмоджи и джаваскрипты и весь современный говновеб, потому что это не приносит ничего нового, никаких вопросов не решает, зато создает целую говноиндустрию. но понять почему юникод не нужен, который решает проблемы, а я помню как с этими локалями в лялихе в 90х были проблемы, с шрифтами и прочим, не важно, короче мне не ясен смысл пользовать кои8, героически преодолевать 33 трудности и тд и тп.

в если говорить про память - да говновеб вне конкуренции, открыл банк клиент и похеру что ты там 50kb поэкономил на ядреной консоли.

Как_я_троллю_ЛОР_на_протяжении_четырёх_лет_после_ухода_эдички.lzma

А я сейчас на полном серьёзе опять пишу из ядерной консоли с локалью KOI8-R.

Развернул LFS в честь починки ядерной консоли в ядре 4.19.2. Сижу сейчас с этим самым ядром. И думаю что делать со своими проектами дальше.

Может и ну его их пересматривать. Юзать ядерную консоль всё-таки у меня получается лучше всего. Надо подумать...

http://saahriktu.org/tmp/scr1542217028.png

чем «скриншоты» делаешь в консоли-то :)

koi8-r

gopher

Двойное трололо!

fbgrab жи есть

И ещё fbdump. Я вот делал:

http://esxi.z-lab.me:666/~exl_lab/screens/qbittorent_fb0_console.png

Своими скриптами. Этот конкретный скрипт использует fbdump.

Теперь в новом более универсальном формате

В формате UTF-8?

В ASCII. Но, теперь с детектором версии pip'а. Раньше была вписана конкретная версия.

А, ладно, признаю, что однобайтные кодировки устарели, и без юникода и графических сред сегодня никуда.

ВОТ ЭТО ПОВОРОТ

Не буду говорить о нужности самого скрипта, но скажу, что

cd ../../..

В конце скрипта не нужно точно, ибо по выходу тебя всё равно выплюнет в cwd, который был до запуска.

А что, Эдик четыре года назад ушел? Как время летит... Кажется только недавно это было.

http://saahriktu.org/tmp/scr1542217028.png

Не боишься полной потери зрения?

gopher://sdf.org/9/users/saahriktu/saahriktu.org/patches/patch_any_pip_for_koi8-r-0.1.sh.lzma (248 байт)

gopher://
patch_any_pip_for_koi8-r
.lzma

Не чокаясь...

Зелёный на чёрном, наоборот, менее яркий для зрения вариант. Этот вариант предпочитают и те, у кого глаза слишком чувствительные, чтобы читать на мониторе чёрный текст на белом фоне (яркий белый фон бьёт таким людям по глазам).

Я, собственно, уже давно понял, что мои проекты полезны хорошо если нескольким десяткам людей. Однако, меня это ни разу не огорчало. В соответстии с логикой «если вкусы большинства не совпадают с моими, то это проблемы большинства».

Просто он нищий и ему не хватает на ещё один гигабайт (Это очень с избытком!) памяти.

$ free -g
              total        used        free      shared  buff/cache   available
Mem:             15           0          14           0           0          14

Однобайтные кодировки просто удобнее. У них много плюсов, а у юникода много минусов. И количество байтов здесь ни при чём. Даже если бы это были не однобайтные кодировки, а, например, тридцатидвухбайтные кодировки, то они бы были всё равно удобнее юникода.

Есть, конечно, например, UTF-32, который устраняет один из серьёзных минусов UTF-8 - разный вес в байтах разных codepoint'ов. Однако, другой значительный минус юникода - модификаторы - есть и в нём. Из за модификаторов тексты для 100% поддержки юникода нужно предварительно разбирать чтобы понять из каких codepoint'ов что на какие знакоместа складывается.

Гораздо удобнее когда можно просто отсчитать заранее определённое количество байтов (пусть и значительно больше чем 1) чтобы перейти к следующему символу у которого тоже фиксированный вес в байтах.

Да и даже локали UTF-32, к сожалению, пока ещё нет.

Несмотря на то, что saahriktu для меня выглядит довольно странным, используя KOI8-R, gopher, и так далее, именно то, что это возможно — является той красотой мира GNU/Linux, которую мы постепенно теряем.

Красотой возможностей выбора для каждого.

Гораздо удобнее когда можно просто отсчитать заранее определённое количество байтов (пусть и значительно больше чем 1) чтобы перейти к следующему символу у которого тоже фиксированный вес в байтах.

Гораздо удобнее не париться о таких вещах вообще. И пользоваться тем, что является стандартом по-сути.

Что значит «И пользоваться тем, что является стандартом по-сути.» в контексте побайтного низкоуровневого разбора текста?

Вот читаем по одному байту и собираем из прочитанного символы/кодепоинты.

Что в этом контексте удобнее? KOI8-R, UTF-8 или UTF-32?

Чтение текста в KOI8-R как раз и входит в дефолтный стандарт и осуществляется через побайтное чтение. Один байт - один символ. И наоборот.

С UTF-32 чуть сложнее:

        // BE/LE mode guess
        if (MODE_BELEG) {
                rcharrb = 0;
                for (rcptr = 0; rcptr < 4; rcptr++) {
                        if ((rcbuf = getchar()) == EOF) {
                                printf("Error: broken stream\n");
                                return 1;
                        }
                        rcharrb += (1 << 8 * rcptr) * rcbuf;
                }
                if (rcharrb == 4294836224) {
                        MODE_BE = 1;
                        printf("[UTF-32BE]");
                } else {
                        MODE_BE = 0;
                        printf("[UTF-32LE]");
                }
...
        }
        // stream process
        rcptr = -1;
        while ((rcbuf = getchar()) != EOF) {
                rcptr++;
                if (rcptr == 0)
                        rcharrb = 0;
                if (MODE_BE == 0)
                        rcharrb += (1 << 8 * rcptr) * rcbuf;
                else
                        rcharrb += (16777216 >> 8 * rcptr) * rcbuf;
                if (rcptr == 3) {
                        rcptr = -1;     // Reset pointer
...
                }
        }

int sizeoffatc(int headbyte)
{
    if (headbyte >= 0 && headbyte <= 0x7f)
        return 1;
    else if (headbyte >= 0xc0 && headbyte <= 0xdf)
        return 2;
    else if (headbyte >= 0xe0 && headbyte <= 0xef)
        return 3;
    else if (headbyte >= 0xf0 && headbyte <= 0xf7)
        return 4;
    else if (headbyte >= 0xf8 && headbyte <= 0xff)
        return -1;              // error
    return -1;                  // error
}
...
int decodefatc(int fcdt0, int fcdt1, int fcdt2, int fcdt3, int fcmaxk)
{
    if (fcmaxk == 1)
        return (fcdt0 & 0x3f) << 0x6 | (fcdt1 & 0x7f);
    if (fcmaxk == 2)
        return (fcdt0 & 0xe0) << 0xc | (fcdt1 & 0x7f) << 0x6 | (fcdt2 &
                                                                  0x7f);
    return ((fcdt0 & 0xf0) << 0x12) | (((fcdt1 & 0x7f) << 0xc) +
        ((fcdt2 & 0x7f) << 0x6)) | (fcdt3 & 0x7f);
}

int fgetfatc(FILE * fatstream)
{
    int cdbuf, cdt[4];
    int cdindx = 0, maxk;
    for (;;) {
        cdbuf = fgetc(fatstream);
        if (cdindx == 0) {
            if (cdbuf == -1)
                return EOF;
            if (cdbuf < 0x80)
                return cdbuf;   // ASCII
            else
                maxk = sizeoffatc(cdbuf) - 1;
            if (maxk == -2)
                return -2;
        }
        cdt[cdindx] = cdbuf;
        cdindx++;
        if (cdindx > maxk)
            break;
    }
    return decodefatc(cdt[0], cdt[1], cdt[2], cdt[3], maxk);
}

в контексте побайтного низкоуровневого разбора текста

В контексте побайтового разбора, оно может и уместно. И только.

С другой стороны это всё как-то ресурсозатратно, да (речь о человекоресурсе; кол-во ручной работы от всех этих юникодов и графических сред в целом резко увеличивается).

Плюсы UTF-8: поддержка большинства языков и не только; Поддержка большинством современного софта как дефолта из коробки; Лолиссимо: из-за мейнстримности - наличие тонны библиотек, которые скрывают повседневную рутину взаимодействия со строками напрямую, в Rust вшит намертво, попоболи я не ощутил.
Плюсы KOI8-R: экономия на спичках и получение N-ого символа за O(1).

Полезно, чтобы разработчики не забывали, что в мире есть разные языки и кодировки.