LINUX.ORG.RU

Как в ядро Linux передаются строки?

 , ,


0

1

Всегда ли там кодировка utf-8 или можно что-нибудь с ядром сделать, чтобы при работе с конкретной программой, строки из неё принимались в другой кодировке?

Мне не важно, к чему там привыкли glibc и gtk+, я спрашиваю про некий абстрактный рантайм, в котором я бы хотел иметь возможность свою кодировку запихивать в ядро.

★★★★

Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от vbr

А, да, для файловых систем не похрен (для реализации регистронезависимых имён файлов в них имеет значение кодировка). Но это явно не то, что интересует ТС.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

Ну ты же о нём тоже в первый раз в жизни читаешь?

как, например, терминалу сказать, что для одной программы используй эту кодировку, а для другой - другую?

Shushundr ★★★★
() автор топика
Ответ на: комментарий от vbr

Say Y here to enable UTF-8 NFD normalization and NFD+CF casefolding support. If you say M here the large table of case foldings will be a separate loadable module that gets requested only when a file system actually use it.

Ну я прочитав это не понял, что такое NFD, что такое case folding.

casefolding based on unicode’s canonical normalization (NFD) with slight modifications.

всё равно непонятно.

http://www.unicode.org/reports/tr15/

Normalization Form D (NFD) Canonical Decomposition

Case folding in Unicode is primarily based on the lowercase mapping, but includes additional changes to the source text to help make it language-insensitive and consistent. As a result, case-folded text should be used solely for internal processing and generally should not be stored or displayed to the end user.

https://www.w3.org/TR/charmod-norm/#definitionCaseFolding

Case folding is the process of making two texts which differ only in case identical for comparison purposes, that is, it is meant for the purpose of string matching. This is distinct from case mapping, which is primarily meant for display purposes. As with the default case mappings, Unicode defines default case fold mappings («case folding») for each Unicode code point.

A few characters have a case folding that map one Unicode code point to two or more code points. This set of case foldings are called the full case foldings.

Данунафиг. Зачем мне знать такие детали враждебной кодировки?

Shushundr ★★★★
() автор топика
Ответ на: комментарий от CrX

для файловых систем не похрен

Тоже интересует.

Итак, есть гипотетически программа, которая знать ничего не хочет о локалях и кодировках и всё в ядро передаёт в такой кодировке, в какой умеет.

Я так понял, что linux тут не справится.

Может в Wine что-нибудь против таких программ есть?

Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

Итак, есть гипотетически программа, которая знать ничего не хочет о локалях и кодировках и всё в ядро передаёт в такой кодировке, в какой умеет.

Давай мы тут определимся, что это «всё» она передаёт. В целом ядру пофиг, для него все эти строки — просто последовательности байт, завершающиеся нулём.

Для файловых систем с регистронезависимыми именами файлов да, ядру нужно понимать кодировку, чтобы понимать, один и тот же файл «б.zip» и «Б.zip», или два разных. В обычном для линуксовых ФС случае это не требуется. Только ни ко всем остальным строкам, ни к терминалу, ни тем более к wine это отношения не имеет — это касается только ФС.

CrX ★★★★★
()
Ответ на: комментарий от Shushundr

как, например, терминалу сказать, что для одной программы используй эту кодировку, а для другой - другую?

Никак. Если речь о локалях, то есть, ты задаёшь, например LC_ALL=de_DE.UTF-8 или LC_ALL=ru_RU.KOI8-R, то за это отвечает glibc, а не ядро.

CrX ★★★★★
()
Ответ на: комментарий от CrX

за это отвечает glibc

Ну то есть, сама наша программа, российская, суверенная,
должна подстраиваться под кодировки, которые нам навязывают враги.

А ядро прикидывается нейтральным,
но на самом деле разбирает пути по слешам.

Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

Ну так запускайте свою, исконно русскую ОС с исконно русским ядром на исконно русском железе. Чего вы на вражеском сидите-то?

PPP328 ★★★★★
()
Ответ на: комментарий от Shushundr

Вклинюсь напоследок

Вычислительная техника работает по спецификациям, спецификации нужны для того чтобы программы могли полагаться на какие-то договорённости. Иначе бы было у одного /home/user/Докуменнты, а у другого ★хомяк★★ИмЯ★★★/Документы, а у иного лица 😊дом😊имя😊файлы и как программам работать? Так исторически сложилось.

Хочешь всё своё, пиши всё с нуля, но сначала свои спецификации на кодировки, спец символы, имена путей, регистрозависимость и так далее и так далее, сотни и тысячи разных мелочей. На RFC погляди сколько там всего, тонны всякой всячины описаны именно для того чтобы если делать то совместимо.

Даже с теми же путями сейчас не всё так хорошо, файлы с винды показываются кракозябрами, текст неправильно отображается в терминале при выводе ибо там \r\n а тут просто \n и глазами это в редакторе не видно,а в старых макосях вообще тупо возврат каретки. Пути файлов в виндах такие \ а в юниксах / такие. Можно пропатчить и вместо слеша пихать звёздочку ★, но это значит что нужно многие вещи на что полагается ПО пересмотреть, а потом переписать всё это ПО. Я вот полагаюсь что если пользователь в пути указал в начале точку перед слешем то это относительный путь текущего pwd, а не имя файла. И у тебя тоже самое, ты ожидаешь что все вещи будут вести себя и означать собой что-то определённое.

Либо ты пишешь свои спецификации и всё с нуля по ним (или переписываешь имеющееся ПО), либо ты интегрируешься с тем что уже написано. Иного пути нет. От слова совсем.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от PPP328

на исконно русском железе

Денег его купить нехватает, а вражеское было любезно предоставлено.

Shushundr ★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

переписать всё это ПО

Если оно не следует принципу DRY (код должен существовать в единственном экземпляре и не дублироваться), то это всё равно плохое, негодное ПО. Грех не переписать.

Shushundr ★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

Я вот полагаюсь что если пользователь в пути указал в начале точку перед слешем то это относительный путь

../ну_да.конечно

две точки перед слешом - это уже в таком определении не относительный путь.

Shushundr ★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

у тебя тоже самое, ты ожидаешь что все вещи будут вести себя и означать собой что-то определённое.

Я использую константы:

String fileSeparator = FileSystems.getDefault().getSeparator();
Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

две точки перед слешом - это уже в таком определении не относительный путь.

Относительный, но уже не до текущего каталога, а выше него. Но да, это другое :)

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от Shushundr

Относительный. Абсолютные пути начинаются со слеша. Остальные — относительные.

CrX ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Ну так каталог выше тоже относительно текущего каталога ;)

Здесь одно на другое не влияет. Две точки — это просто «на уровень выше» — их можно использовать как в относительных путях, так и в абсолютных. В абсолютных практического смысла в принципе маловато, но вообще путь /usr/share/../bin/sh, например, валидный.

Путь ../что_то точно такой же относительный относительно именно текущего каталога. Просто в нём используются две точки, так же как и где угодно ещё.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от Shushundr

переписать всё это ПО

причём ради несоответствия стандартам — это вредительство в духе M$. Именно они таким промышляли в стародавние времена. И в путях сделали обратный слеш вместо прямого, и в веб-стандарты специально палки в колёса вставляли, и для офиса свои собственные пропихивали, и т.д. и т.п. Так что за лучшими практиками подобного — это к ним.

До сих пор вот расхлёбываем.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

«Macintosh OS used : as its path separator until MacOS X introduced POSIX APIs»
https://retrocomputing.stackexchange.com/questions/4695/slash-versus-backslash-as-directory-separator-what-who-caused-this-rift

«: and . as path separators predating UNIX’s use of /»

«designs were using : and . in the mid-60s, half a decade before UNIX decided on /, and UNIX broke from Multics’s > because they wanted to use it for shell piping.»

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 3)
Ответ на: комментарий от Shushundr

Я в курсе. Но эти потом исправились.

Эппл не сильно лучше МС, они тоже пропихивают собственные ни с чем не совместимые стандарты, до сих пор. Но у эппла есть большой плюс — они их не навязывают окружающему миру и варятся в своём болоте. Напротив, они стараются, чтобы остальные в них особо и не лезли. То есть, если ты не пользователь эппловских продуктов, ты можешь достаточно спокойно закрывать глаза на их существование вообще и жить так, будто никакого эппла нет. M$ же пытается пропихнуть свои «стандарты» всеми миру, а потом внезапно поменять. Ну и классическое EEE.

CrX ★★★★★
()
Ответ на: комментарий от Shushundr

В RISC OS (не путать с risc/os) разделителем каталогов является точка, а отделителем расширения файла – слэш.

В общем, какого только маразма за историю айти не случалось.

Но о чём ваши разговоры, всё равно непонятно)

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от CrX

Это был не микрософт:
«the decision to use backslash was requested by IBM: Microsoft had been originally intending to use forward slash, and the change happened late in the development process»

The reason / was not used is that MS-DOS 1.0 (which did not support directories at all)

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от wandrien

о чём ваши разговоры, всё равно непонятно

Можно ли в ядро linux впилить работу с путями по другому символу? насколько это сложно?

Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

MS вообще любило Unix платонической любовью и несколько раз пыталось сделать DOS более Unix-like.

Но межделмаш имел свои планы на это.

wandrien ★★
()
Ответ на: комментарий от wandrien

Всё паламаеца

Главное, что моя прога будет работать.

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

Shushundr ★★★★
() автор топика
Ответ на: комментарий от wandrien

Насколько я понимаю, DOS мог бы быть чем-то вроде Unix для бедных, если бы MS имела возможность сломать совместимость с первоначальной наколенной версией-поделкой.

wandrien ★★
()
Ответ на: комментарий от Shushundr

Ну да, тогда они ничего ещё не решали. Но они и потом не заменили слеш на нормальный, когда, например, переходили с DOS на Windows, или ещё при каком-нибудь случае. Да и слеш не самый показательный случай.

CrX ★★★★★
()
Ответ на: комментарий от CrX

До сих пор вот расхлёбываем.

Чё уж тут говорить, я в своём интерпретаторе браифака (уж где где не ожидал) вчера весь день провёл рвя волосы на жопе. Проверял на разном коде, некторый код не работал, но должен, стучался головой об клавиатуру пока не понял что программа ожидает ввода заканчивающегоня на \n а в тестах которые видимо были написаны на винде всё на \r\n заканчивается, а я то блин всё переколупал. Ладно понял принял добавил ключи приведения ввода к разным EOL, затем другой код опять блин не работает, а он явно ожидает \r вместо \n и его выводит потом переврдя каретку и переиспользует для вычисления следующей ячейки блин, ну здрасти пришлось ещё делать ключи для принудительного преобразования конца строки так как это поведение вшито в brainfuck программу. И уже вот такая говня в ключах интерпретатора

 Some brainfuck programs expect different behavior for
   end of line. Setting bottom transparent fix input for
   different behavior end of line. LF , CR, CRLF. You can
   enable only one variant. If set more last disable other
   By default enabled -eof_lf if input no have '\n' in line end
   force added '\n' in last input data. Use -dn for disable it

   -eol_lf        Enable check end of line and force set LF == '\n'
                  if input have '\r' or '\r\n' this option
                  change it to single '\n'. (*nix way)

   -eol_cr        Enable check end of line and force set CR == '\r'
                  if input have '\n' or '\r\n' this option
                  change it to single '\r'. (old osx way)

   -eol_crlf      Enable check end of line and force set CRLF == '\r\n'
                  if input have '\n' or '\r' this option change
                  it to two end of line symbols '\r\n'. (windows way)

   Some brainfuck programs expect different behavior for end of file
   some expect write '0' in memory cell, some need save cell value
   and skip write other value in cell and some needed write -1 in cell
   Options bottom can enable one of varians. By default enabled -eol_zero
   You can enable only one varian. If set more last disable other.

    -eof_zero      If no have data to read, write 0 in memory cell m[i]=0

    -eof_eof       If no have data to read, write -1 in memory cell m[i]=-1

    -eof_skip      if no have data save cell value m[i]=m[i] (it like clamp)

    -eof_same      same as -eof_skip, just alias, it's easier to remember :)

Тут все хвалятся, а ййяяяааа написах браинфук интерпреатор в 200 байт! А ййя в три строчки.

А я в 1200+ говнострок модуля Lua + 500+ утилиты командной строки. Я конечно говнокодер тот ещё. Но всё же. Всякую херню учитывать приходится то там то сям, буквально на ровном месте. :(

Бесит блин :)

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от Shushundr

Можно ли в ядро linux впилить работу с путями по другому символу? насколько это сложно?

Можно. Очень легко. Просто заменить слеш на любой другой однобайтный в исходниках, внезапно. Но ЗАЧЕМ?

Естественно, пути со слешами работать перестанут, как и все программы, полагающиеся на них. Но можно и легко.

CrX ★★★★★
()
Ответ на: комментарий от CrX

Просто заменить слеш на любой другой однобайтный в исходниках

Ньет, мне хочется символ из своей кодировки. Там он для разнообразия не будет однобайтным.

Но ЗАЧЕМ?

Чтобы API ядра стал более правильно спроектирован.

Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

Ньет, мне хочется символ из своей кодировки. Там он для разнообразия не будет однобайтным.

Тоже можно. Будет сложнее и сломается ещё больше всего. И ненужность поделия повысится ещё на один порядок. Но, конечно, можно. И не то чтобы прям так уж сложно.

Чтобы API ядра стал более правильно спроектирован.

🤡

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

Зачем вообще ядро парсит строки? Сложно было массив массивов сразу в спецификации прописать?

Мне, кстати, ещё не ясно, почему есть разница в передаче параметров - в винде командная строка это одна строка, а в линуксе - массив строк, где один параметр может передаваться несколькими кусками.

Сделали бы единообразно - чтобы и пути тоже кусками передавались. А то тут так, там эдак…

Shushundr ★★★★
() автор топика
Ответ на: комментарий от Shushundr

Зачем вообще ядро парсит строки?

Тебе весь тред пытаются объяснить, что оно их не парсит. Почти. Для регистронезависимых ФС приходится.

Сложно было массив массивов сразу в спецификации прописать?

Да, сложно. Зачем усложнять, если можно не усложнять?

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

Для ядра имя файла это просто набор байт

Не всегда. К примеру в ZFS есть опция utf8only, которая проверяет, что этот набор байтов является валидной UTF-8 строкой.

vbr ★★★★
()
Ответ на: комментарий от CrX

Так мы выяснили факт, что
ядро разбивает пути по слешам или нет?
Если да, значит парсит. И слеш точка. «Чуть-чуть» считается!

Shushundr ★★★★
() автор топика
Ответ на: комментарий от CrX

Процитировал криво, но в твоём сообщении суть та же - что ядру пофиг. В целом - да, пофиг, но есть ситуации, когда не пофиг.

vbr ★★★★
()
Ответ на: комментарий от vbr

есть ситуации, когда не пофиг

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

Shushundr ★★★★
() автор топика
Ответ на: комментарий от vbr

В целом - да, пофиг, но есть ситуации, когда не пофиг.

Ну да. Но в моём сообщении примерно так и написано в принципе. С «это касается только ФС». То есть, что не во всех ситуациях пофиг. Про эту опцию у ZFS я не знал, кстати, поэтому привёл как пример регистронезависимые имена файлов — там тоже надо понимать кодировку.

Ну и ZFS не часть ядра Linux так-то ;) Сторонних модулей, где будут парситься строки и делаться сколько угодно всякого разного ещё, можно сколько угодно понаписать ;)

CrX ★★★★★
()
Ответ на: комментарий от Shushundr

Ладно. Не буду больше кормить тролля. Ответы на свои технические вопросы ты вроде более-менее получил, и ладно.

CrX ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.