On Sat, Jan 02, 2010 at 10:54:41PM +0300, Victor Wagner wrote:
On 2010.01.02 at 22:15:04 +0300, Stanislav Maslovski wrote:
И locale database запихать в ядро (для перекодировки ядру она
понадобится)? А для генерирования новых локалей ядро пересобирать,
А в ядре она УЖЕ есть. Для
On Sun, Jan 03, 2010 at 02:14:24AM +0300, George Shuklin wrote:
Видимо тем, что ядро запрещает часть файловых операций для файлов с
атрибутом 'd'. Даже для рута (что не типично для unix).
Поскольку каталоги _УЖЕ_ не совсем файлы, то никто и ничто не мешает это
не совсем адаптировать к
On Sun, 3 Jan 2010 15:06:58 +0300
Stanislav Maslovski stanislav.maslov...@gmail.com wrote:
On Sun, Jan 03, 2010 at 02:14:24AM +0300, George Shuklin wrote:
Видимо тем, что ядро запрещает часть файловых операций для файлов с
атрибутом 'd'. Даже для рута (что не типично для unix).
On 2010.01.03 at 14:39:22 +0300, Stanislav Maslovski wrote:
В ядре нужны две вещи - знание о текущей локали данного процесса и
таблицы перекодировки. Все остальное можно оставить в libc.
Э, нет. Ты предлагал сделать setlocale() системным вызовом. Это
потребует большего, чем имеющиеся
On Sun, Jan 03, 2010 at 08:15:57PM +0300, Victor Wagner wrote:
On 2010.01.03 at 14:39:22 +0300, Stanislav Maslovski wrote:
В ядре нужны две вещи - знание о текущей локали данного процесса и
таблицы перекодировки. Все остальное можно оставить в libc.
Э, нет. Ты предлагал сделать
On 2010.01.03 at 23:57:54 +0300, Stanislav Maslovski wrote:
Нет, не потребует. Потребуется только вызов
getlocale, который позволит интересующейся функции libc узнать что
думает про текущую локаль ядро.
Ты путаешь локаль и то, что зовется кодировкой локали. Просто из имени
Я не путаю.
On Sun, Jan 03, 2010 at 11:57:54PM +0300, Stanislav Maslovski wrote:
On Sun, Jan 03, 2010 at 08:15:57PM +0300, Victor Wagner wrote:
Например, из-за наличия case insensitive файловых систем в ядре не
лишними будут национальные правила upcase/locase.
Имхо, лишнее, так как на таких файловых
Yuri Kozlov wrote:
Для решения проблемы топикстартера достаточно заставить mount(2)
считаться с iocharset (только наоборот) и для rockridge.
fuse-convmvfs, как уже и посоветовали.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
On Mon, Jan 04, 2010 at 12:12:52AM +0300, Victor Wagner wrote:
On 2010.01.03 at 23:57:54 +0300, Stanislav Maslovski wrote:
Нет, не потребует. Потребуется только вызов
getlocale, который позволит интересующейся функции libc узнать что
думает про текущую локаль ядро.
Ты путаешь
Stanislav Maslovski wrote:
Если под удобством имеется ввиду обсуждаемая автоматическая
перекодировка имен файлов в локаль процесса, то сделать это прозрачно
для приложений, увы, невозможно. Уже приводился пример двух процессов,
запущенных в разных локалях и обменивающихся именами файлов через
On Mon, Jan 04, 2010 at 12:10:50AM +0200, Serhiy Storchaka wrote:
Stanislav Maslovski wrote:
Если под удобством имеется ввиду обсуждаемая автоматическая
перекодировка имен файлов в локаль процесса, то сделать это прозрачно
для приложений, увы, невозможно. Уже приводился пример двух
В Пнд, 04/01/2010 в 00:10 +0200, Serhiy Storchaka пишет:
Если под удобством имеется ввиду обсуждаемая автоматическая
перекодировка имен файлов в локаль процесса, то сделать это прозрачно
для приложений, увы, невозможно. Уже приводился пример двух процессов,
запущенных в разных локалях и
On Mon, 04 Jan 2010 00:05:44 +0200
Serhiy Storchaka storch...@gmail.com wrote:
Yuri Kozlov wrote:
Для решения проблемы топикстартера достаточно заставить mount(2)
считаться с iocharset (только наоборот) и для rockridge.
fuse-convmvfs, как уже и посоветовали.
Да, как-то более
13 matches
Mail list logo
