sgfault

Кавайки - это то, что надо. Большего и не потребуется. Забудьте про пыхи, сайты, андроиды.. Снесите винду и поставьте линукс. Xmonad вместо ДЕ. И тогда.. придет Haskell! (ну ладно, винду можно оставить - в конце концов, играть и смотреть японские мультики на ней лучше; да и даже линукс не обязателен - все будет работать и на винде, просто, xmonad может стать практической задачей, решение которой будет сразу отражаться ээ.. на вашем рабочем столе) Взаимо-зависимые выражения, бесконечные структуры данных, монады, стрелки, продолжения, линзы, зависимые типы и еще бессчетное множество теорий (и математики), которые компилируются и работают, - разве встретишь это когда-нибудь при написании сайтов на "любимой" пыхе? Да даже в С++.. Но если когда-нибудь очень захочется написать сайт, или кроссплатформенную прогу (или даже под openwrt), или просто устанете исправлять очередной скриптик на народном языке bash - Хаскель может все это. Он безграничен и бесконечен.

Что вы! Это лишь означает, что я попал если и не в 10-ку, то в 9-ку уж точно. И, как видите, Nulex-а, что называется, понесло. Хех, на это и был расчет, в конце концов. Единственное о чем я забыл: что и мне придется тратить много времени на ответы. Сейчас, задним числом, я это уже понял, поэтому хоть ответ и все еще длинный, в нем мало примеров, нету многих ссылок, и вообще не хватает конкретики. С другой стороны, зачем стараться ради очередного витка вечного холивара "Винда вс ЛинАкс" ? Дефрагментатор господина Kolivas-а - это шелл скрипт, который дефрагментирует с помошью cp/mv. Иногда это сработает. Но это нельзя назвать полноценным дефрагментатором, который работает на уровне фс, хотя бы потому, что когда диск почти заполнен, свободные блоки как были разбросаны, так и останутся, сколько ни перезаписывай. Shake - как я понял с ихнего сайта, тоже просто перезаписывает файлы. Может немного умнее, чем упомянутый выше шелл-скрипт, но это все равно не на уровне фс. Кроме того, мне не нравится, что shake что-то пишет в xattr файлов. Он должен просто перемещать блоки чего-то там (неважно), а не устраивать БД у меня на фс. А вот e4defrag - да, это что-то похожее на полноценный дефрагментатор. Я про него забыл, спасибо, что напомнили. Что ж, браво, наконец-то у ext появился дефрагментатор. Прошло какие-то 10 лет с релиза ext3.. А также, к слову, раз уж вы привели ту ссылку, то может вы заодно ответите мне на вопрос: зачем запускать git, configure и make из-под sudo? Насчет того, падает ли производительность - не сомневайтесь, еще как падает. Надо всего лишь подождать нужного количества фрагментов, разбросанных по всему диску. Это более, чем реально, если диск почти всегда заполнен под 100%. Не сразу, конечно, но результат гарантирован. При хорошей фрагметации (несколько кб на фрагмент) скорость чтения упадет до 5-10мб/с. Примеров не будет. В качестве доказательства я вам только скажу, что как бы вы не размещали файлы на пустом диске, последующие удаления, и записи все равно сделают свободное место фрагментированным. А значит, когда появится достаточно большой файл, он соберет все эти фрагменты в себе. Это невозможно предотвратить при создании файлов, тк будущие действия пользователя просто неизвестны. Что-то вам везде утята мерещатся. Травка? Или валидола объелись? Я ждал этого вопроса. Открою вам большой секрет - в винде также, как и в вашем любимом линуксе, большинство проблем решается без переустановки. Но меня не интересуют ни переустановки, ни обновления. К сожалению, сказать, что вы делали не так, я не могу, тк я не знаю, что вы делали. Зато я предлагаю вам ответить на обратный вопрос: исправить то, что я делал не так. И, я вам гарантирую, пары часов не хватит. Итак, начнем, пожалуй, с терминала. Видимо, это общая фича всех терминалов, написанных VTE-виджете, но если в tmux-е разбить окно вертикально на два, то копипаст мышкой из правой половины останавливается, не доходя до конца строки, либо сразу выделяет все до конца. Одним словом, выделить одну строку почти до правого края экрана невозможно. Думаю, не стоит говорить, что это исключительно неудобно, и делает вертикальное разбиение почти бесполезным. Но в xterm все отлично работает. Вот только проблема в том, что настройка xterm-а немного сложнее, чем потыкать в графических настройках гномо-терминала. И тут, в связи с появлением xterm-а, возникает вопрос про X resource. Точнее, про вывод команд listres и viewres: $ listres Object WidgetClass Instance Class Type ----------- -------- ----- ---- object: Object Object destroyCallback Callback Callback здесь все более-менее понятно. А если вот так $ listres -variable object Variable Instance Class Type -------- -------- ----- ---- object: object object destroyCallback Callback Callback то уже непонятно: что такое variable ? Это объект соответствующего класса? Тогда кто его создал? Ведь listres показывает иерархию классов доступных виджетов, те здесь нету никакого приложения (типа xterm), которое могло бы создать объекты. Если это не объект, то что это? Продолжение следует.. Теперь перейдем совсем к другой теме: когда-то я пользовался Thunderbird-ом. Он был вцелом ничего, только запуск внешнего редактора для написания письма там работал как-то "криво" (не помню точно, но то ли какой-то полузаброшенный плагин, то ли какой-то полухак). Кроме того, я не нашел (не очень искал, если честно) способа, отметить ветку сообщений (в рассылку мейллиста), как "неинтересную", чтобы все новые письма _этой_ ветки автоматически помечались как "прочитанные". Зато я услышал, что в claws-mail все это есть в "стандартной" поставке. Я его попробовал - и правда, все есть. Казалось бы, вот оно счастье, но не тут-то было. Я заметил, что письма не "приходят" в claws-mail пока я не нажму кнопку "Get mail". Видимо, причина этого в том, что он не поддерживает IMAP IDLE. И разработчики отказались добавлять эту возможность, несмотря на многочисленные просьбы пользователей. Там есть таймер, через который он может запрашивать сервер о новых письмах, но это все-таки не то. Может быть, это все еще можно исправить с помощью каких-то дополнительных программ. Продолжение следует.. И снова сменим тему. Есть старая "фича" гномовского power-manager: изменять яркость сразу на несколько делений. Как я понял, это происходит из-за того, что при нажатии кнопок яркость изменяют сразу несолько "программ": одна из них это ядро (acpi?), вторая - собственно power-manager. В результате получается на 2-3 деления. Это очень неудобно, тк из 16 делений у меня остается 5. Где-то в багзиле гнома был непринятый патч. Говорят, в power-manager-е xfce для этого бага сделали workaround в виде "холостого хода": когда power-manager только показывает "менюшку" изменения яркости, но не изменяет ее сам, надеясь, что этот "второй кто-то" все сделает. В первом случае, патч должен быть применен (или переписан) под текущую версию гномовского power-manager и пакет пересобран, во втором - гномовский менеджер в гномо-сессии заменен на xfce-шный. Продолжение следует.. Есть старый "баг" X-ов: переключение раскладки при _нажатии_ кнопок, а не при их отпускании (как в винде). Это становится исключительно неудобно, если вы сделали переключение раскладок, допустим, Alt+Shift, а потом сделали в каком-нибудь гномо-терминале перключение вкладок Alt+Shift+цифра. В таком случае, при переключении вкладок у вас будет еще и язык переключаться. В багзиле xorg был патч. Его не приняли, потом.. в общем, не буду пересказывать, скажу лишь, что чтение комментов этого бага доставляет. В багзиле убунты тоже есть соответствующий багрепорт. Там патч приняли. Не знаю, вошел он в пакет убунты или нет, но, даже если вошел, то вряд ли он есть в других дистрах (например, в Дебиане). Это значит, что патч надо найти, применить, пакет пересобрать.. Продолжение следует.. И, напоследок, например, вот такое. Снапшоты lvm-а иногда можно использовать, чтобы сохранить предыдущее состояние фс (если она не поддерживает снапшоты внутри фс, как zfs). Проблема в том, что сделав таким образом "временный" бекап, можно случайно записать на origin LV данных больше, чем размер CoW-устройства снапшота. Тогда снапшот станет invalid, и "временный" бекап будет потерян. Возможная идея заключается в том, чтобы когда CoW-устройство почти переполнено послать suspend (см. dmsetup(1) suspend) на origin LV и снапшот. Тем самым, возможно, дав пользователю возможность увеличить CoW-устройство снапшота до того, как оно переполнится. Это лишь идея, может быть так сделать нельзя. Кроме того, suspend на origin LV - не очень хорошая идея сама по себе, но тем не менее, возможно, добавив какие-нибудь таймеры, из этой идеи можно сделать что-то пригодное хотя бы для домашнего использования. Продолжение вряд ли следует.. Ну, думаю, хватит. Этот список можно продолжить в бесконечность (по крайней мере, пока что мне так кажется). Не хотите ли довести до _конца_ решение предложенных выше задач? Впрочем, я вам дам совет: если вам не совсем нечего делать, то вы должны отказаться. И это будет абсолютно правильный ответ. Вот именно, что нет! Для уровня чайника или мартышки чтение документации должно быть либо вовсе не нужно, либо сведено к нескольким строчкам. Если это не так - это плохая программа (точнее с плохим интерфейсом). Конечно, есть и исключения, но программы, расчитанные на "всех", явно не относятся к этим исключениям. Почему "порог начала использования" должен быть низким? Очень просто: чтобы я смог начать использовать программу как можно быстрее. От этого преимущества получают все: я, не тратя много времени на изучение программы, могу ее сразу попробовать и, возможно, понять, что это вообще не то, и продолжать не имеет смысла. Если же это "то самое", то я всегда могу постепенно, когда будет время и желание, увеличивать свою "квалификацию" в использовании данной программы. Разработчик же получает преимущество в том, что пользователь уже пользуется его программой. Для сравнения, если даже для базового использования требуется изучение большого количества документации, то пока пользователь все это читает, он использует какой-то _другой_ аналогичный продукт. Это не говоря уже про то, что кто-то, взглянув на объем документации, сразу откажется от программы. Кому нужны ваши вопросы! RTFM - и это весь ответ на 99% всех вопросов на всех форумах. И, самое главное, это абсолютно правильный и совершенно бесполезный ответ. Его правильность делает бессмысленным большинство вопросов. Его бесполезность делает, порой, поиски ответов невероятно долгими. И именно поэтому софт должен работать приемлимо "из коробки" - чтобы во время бесконечных поисков ответов, можно было продолжать делать что-то еще, используя этот софт. Другими словами, чтобы очередная поломка не стала "блокирующей" для всего остального. Правда, умные люди придумали решение лучше: чтобы с одной стороны не повторять 1001 раз ответы на одни и те же вопросы, а с другой - не посылать на 4 буквы, написанные выше, - StackOverflow . Ай-яй-яй, это вы зря. Полноценных ДЕ, в которых в каком-то виде есть все: панель управления, интеграция приложений, работа "из коробки" - только два: КДЕ и Гном. Вот только Гном3 в его нынешнем состоянии - это просто игрушка. Гном2 - не поддерживается. Форки вряд ли могут быть каким-то надежным решением, тк энтузиасты никогда не заменят апстрим. Тем более для такого большого проекта. "Легкие" ДЕ слишком сильно уступают по возможностям "из коробки", как КДЕ, так и Гному. Часть этих недостающих возможностей, конечно, можно допилить напильником, от части - просто отказаться, вот только все это требует немало времени. Одним словом, из полноценных ДЕ, поддерживаемых апстримом, КДЕ - единственный. Что такое YOBA я не знаю. И, говорю заранее, в гугле искать не буду, и можете меня туда не посылать - если вам интересно, чтобы я понял ваш ответ, найдите ссылку сами или напишите объяснение. Но, в любом случае, Гном3 требует 3Д-ускорение (для не fallback режима). Так что об играх речь вообще не идет. Не ешьте много. Вам уже и сейчас утята мерещаться, а так и сами утеночком станете. Рискну предположить, что whois хотел подробности по поводу "памяти и мозгов". Что такое "мозги" остается только догадываться, но если под проблемами с памятью вы имеете в виду то, что в ХР не видно 4гб памяти, - то это не такая уж и проблема. Учитывая, что сам ХР расходует намного меньше 7-ки, и 3.2 (или сколько там доступно?) хватит для офиса и фф с сотней вкладок (хотя зависит от содержимого, конечно). Фрагментация не редкая вещь на винде. Скорость чтения 10мб/с получить вполне реально. Рецепт аналогичный тому, что был выше.

Ха, забавный сайт. Я про него давно забыл. Помнится, там когда-то была одна статейка весьма неплохо написанная. Но, вообще, полистав главную страницу, сейчас там ничего интересного не нашел.

Шутите? Ну-ну. Фс на этом вашем линуксе не фрагментируется, вирусы не живут - идилия. Хаха. Зато когда, о ужас, оказывается, что фс все-таки фрагментируется, то рекомендуемый способ дефрагментации.. удалить все и записать заново! А что? Все гениальное просто. Вы там, случайно, каменными топорами не балуетесь? (под фс я имел в виду ext2/3/4) "Что, вас LXDE уже выпустили из сумасшедшего дома?" ээ.. те я имел в виду, он что уже стал пригодным для работы? Последний раз, когда я его видел (может год-полтора назад), тамошний файловый менеджер (pcmanfm, кажется) падал с сегфолтом от "~" и ".." в строке пути. Это было настолько ужасающе печально, что дальше смотреть на это было просто невозможно. Я слышал, правда, что тоже какое-то время назад этот баг был закрыт. Кроме того, как там обстоят дела с "панелью управления" ? Чувствую, что ее там нету, или она такая, что все равно придется редактировать конфиги вручную. И, в этом случае, я не вижу отличия по сравнению с просто набором программ (вм, панельки, ну и тд). И теперь можно перейти к О да, я-таки имею что-то против Убунты (против линукса вообще, если точнее). Немного на первый взгляд, но очень много на второй - доработка напильником. Видите ли, доработать, конечно, можно все что угодно, но в процессе доработки может прийти такая вот неприятная мысль: "А зачем мне вообще эта система, если вместо того, чтобы заниматься на ней своими делами, я дорабатываю ее напильником?" И чем дольше вы будете работать напильником, тем чаще эта мысль будет вас посещать. Конечно, может быть и другой вариант: вам просто нравится процесс доработки напильником (который, чего уж там, сам по себе достаточно интересный, вот только не всегда совпадает с тем, что действительно нужно делать в данный момент). Если хотите, могу сказать это по-другому: у этого вашего линукса, действительно, весьма впечатляющие возможности в теории, и по всем этим возможностям и не только уже написали невроятное количество документации, проблема только в том, что чтобы счастье, наконец, наступило, всю эту докумтацию придется прочесть. И да, это проблема. Это огромная проблема. И это становится еще большей проблемой, когда обнаруживается, что из коробки там ни черта не работает.Те когда оказывается, что надо не просто прочесть охренную гору документации, надо прочесть ее здесь и сейчас. И тогда мечты заканчиваются, и начинается "Добро пожаловать в Линукс". Для сравнения, у винды, исходя из моего небольшого опыта, теоретические возможности меньше, кроме того некоторые действительно замечательные программы (например, xmonad) там просто не работают (winsplitrevolution - это жалкая тень xmonad-а, который его никогда не заменит, если что), тем не менее того, что "просто работает хоть как-то" там значительно больше. Под этим я имею в виду работоспособность, для достижения которой не требуется никаких знаний (типа "дерни за ручку, оно и откроется"). Есть еще одно достойное отдельного упоминания "свойство" этого вашего линукса - это его разработчики, дорогое наше коммьюнити. Как известно, дорогому нашему коммьюнити всегда насрать на всех, кроме самих себя. И об этом они никогда не забывают, и кричат всегда и везде. Можно подумать: "Ну и ладно". Но, оказывается, не ладно. Я бы отметил несколько интересных моментов в истории (мне неохота проверять их достоверность, так что если что не так, уверен, вы исправите): с выходом КДЕ4 была дропнута поддержка КДЕ3; в какой-то момент gdm был переписан, что привело (для пользователей) в потере многих возможностей кастомизации, соответственно, поддержка старого была дропнута; с выходом Гнома3 поддержка второго была дропнута в пользу убого fallback-режима. Насчет gdm-а не скажу, но я точно знаю, что первые версии как КДЕ4, так и Гнома3, даже и тестингом-то назвать было сложно, скорее - анстейбл или экспериментал. Те они были просто непригодны для работы, но ведь "проблемы негров пользователей шерифа разработчиков не волнуют!". Очень смешно с этой точки зрения выглядит недавнее заявление разработчиков Гнома: GNOME Shell to support a "classic" mode . После того, как они столько отказывались от fallback-режима, его поддержки и возврата классического вида, теперь они вдруг передумали. Хаха! (наверняка, без РедХата тут не обошлось). Ладно, одним словом: Микрософт никогда не дропал свой предыдущий релиз сразу после выхода нового. И одного этого уже может быть достаточно, чтобы не пользоваться этими "игрушками", которые дорогое коммьюнити так любит выпускать и тестировать на пользователях, прикрываясь тем, что: "Нам же за работу никто не платит! Все на энтузиазме! Берите и радуйтесь чему дают!". Эх, опенсорс, такой опенсорс.. Каких конкретно возможностей ХР не использует на новом железе? Кроме того, я вам напомню, что этот ваш линукс тоже не использует возможностей нового железа: поддержка 3Д там до сих пор печальна, как и качество открытых драйверов для видеокарт (я про nouveau, для ATI - не знаю). А если вы собираетесь пользоваться фирменным нвидивским, то.. хм, как-то использование проприетарных драйверов не слишком соответствует идеологии вашей любимой системы.

Или для тех, кто слишком хорошо знает, что такое убунту.

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

Выкладывайте уже исходники, чего тянуть.

Серьёзно? О_о А гайды по установке есть?) Википедия подсказывает мне, что в этой вашей Виндоус это делается какими-то сторонними утилитами List_of_RAM_drive_software и называется, видимо, "виртуальный диск" (virtual drive) (так же, как и тот, который из файла (который loopback)). И даже, кажется, как-то раз, как обычно проходя мимо, я видел тут обсуждение этих рамдисков под виндой, но сейчас найти не могу. В любом случае, если что, то я это все не пробовал. Я просто разместил объяву:huh:

Честно скажу, статью не читал (неохота), просто пролистал поиском по 945: Видите ли, если там и 64-битная система будет использовать <4гб, то это немного не тот случай. Но это я так, впрочем. Ага. Конечно, вы оговорились. Я даже и не сомневался. У одних знакомых комп сгорел, и они теперь живут в лесу с медведями, и интернет туда еще не провели, свои планки вы уже раздарили (БУ планка оперативки - отличный подарок на днюху! А БУ мышки и клавиатуры, залитые соком, дарить не пробовали? Но это не мое дело, конечно-конечно.). Все эти ваши сокращения - IRL, "кодинг" и "эдит" - неизвестны мне, но что со всеми свидетелями что-то случилось - это я понял.. Аа, точно! Это заговор! Опять организация NHK. Да, это может все объяснить.

ПРИШЛО ВРЕМЯ ПЕРЕУСТАНАВЛИВАТЬ ШINDOWS переходить на ram-диск? Говорят, эта ваша ШWindows уже научилась с ним работать:huh:

Раз знакомые сидят, то достать скрин св-в системы, который вас попросили сделать выше, проблем не составит. Ну, так покажите наконец? :huh: Интересно, а о какой опции, собственно, речь? О поддержке >4гб что ли? Те вы имеете в виду PAE? А на каком железе оно не работает?

А без антивируса, фаервола и прочих подобных программ вы пробовали? Другими словами, на чистой винде этот баг вопроизводится?

Нет, я всего лишь немного знаком с линуксом (который вам, возможно, понадобится, если вы хотите свой хостинг), а в чатах я разбираюсь не больше вашего. В любом случае, если вы не передумали, то начинайте пробовать. Хотя бы запустить линукс (например, Debian) в виртуалке (например, VMware). Что касается самого чата, то, видимо, вариантами могут быть сети типа ICQ/Jabber/IRC/Skype и тд. Возможно с собственным сервером и, возможно, с веб-клиентом (что-то такого типа CGI:IRC). Или, возможно, что-то такое AJAX Chat или такое Java Chat Servers

Странно, никто не хочет отвечать, а ведь тут должно быть много Ъ-линуксоидов и админов :unsure: В двух словах, это должно выглядеть как-то так: вы оплачиваете хостинг (сервер с постоянным IP) и доменное имя. Затем вы настраиваете этот сервер ("Добро пожаловать в Linux" :wacko:), запускаете там какую-то программу, которая и будет чатом (здесь, видимо, зависит от того, что за чат).. хм, а потом думаете почему все это не работает ^_^ Естественно, еще есть линукс коммьюнити, которое всегда готово помочь:ph34r: В результате, вы поймете, как вам все это надоело, и бросите эту пустую затею :huh: Конечно, не обязательно все должно случиться именно так, но я бы вам все же посоветовал оставить эту идею. А так.. Конечно, понятно, что вы эту идею не бросите, поэтому начните с эксперимента на виртуальной машине: сервер, клиент. Установить, настроить, убедиться, что работает. Те, берете какой-нибудь Debian, определяетесь с программой для чата, ну и тд -)

Посоветуйте, пожалуйста, романтику и чтобы действие происходило зимой.

Может здесь вы найдете подсказку к решению wiki.bakabt.com/Screenshots. Я так понимаю (см. ссылку), что обычно скрины получаются без сабов, даже если сабы включены. А чтобы снять скрин с сабами, нужно, чтобы сабы показывал какой-нибудь DirectVobSub. Те, чтобы сделать наоборот, надо чтобы сабы показывал сам mpc. Последнее, видимо, означает, что в п2 надо поставить галочку на 'Auto-load subtitles' (View-> Options-> Playback) вместо того, чтобы убирать. (я сам не пробовал, это просто рассуждения -)

Большое спасибо )

Помогите, пожалуйста, опознать: http://i057.radikal....649778c713f.jpg , http://i020.radikal....b0a4d902da7.jpg

А не проще смонтировать и пользоваться, ничего не извлекая (в винде что-нибудь типа daemon-tools)?

sgfault сокращение от "Segmentation Fault" - весьма распространенная ошибка работы с памятью (в линуксе). И так уж сложилось (традиция ;) ), что если первый запуск программы, которую писал я, не заканчивается SegFault-ом, значит там что-то очень сильно не так. Впрочем, сейчас этот ник скорее, как дань прошлому, чем имеет отношение к настоящему. Хотя у него есть еще одно преимущество: он редко оказывается занят -)

Попробую и я -) Для меня эта фраза в расширенном смысле является определением искусства. Когда-то кто-то чувствует это, его работа становится искусством. Если он просто работает "на публику", чтобы заработать (например), он никогда не почувствует эту "силу, радость и красоту". Это можно почувствовать только, если вложить в работу чувства, душу, слиться с ней, стать единым целым и она станет отражением тебя самого. И, когда другой _так делает работу, это сразу видно со стороны. Это может быть любая работа, начиная от картин и театра, и заканчивая заточкой ножей и ездой на велосипеде. Работа настоящего мастера этим и будет отличаться от работы ремесленника: нельзя стать мастером, если не любить работу, и не вкладывать в нее душу. Но, если ты вкладываешь в работу душу, она "оживает" и становится искусством. Поэтому, например, рисунок ребенка для меня всегда будет искусством, каким бы "неправильным" он не казался на первый взгляд. А что касается "для всех" и "для каждого" - я считаю, что "для каждого".

Хм.. думаю, что я знаю ответ. В любом случае, спасибо за помощь, сам бы я не догадался ^) В двух словах: точка не совпадала с символами больше 0x7f потому, что в кодировке utf8 нету таких кодов. Наверное, я должен написать подробнее, следуя традиции, что тот, на чей вопрос ответили, должен написать решение полностью. Первый тест. Поставим локаль для скрипта из предыдущего поста в однобайтовую, например, С и все сразу заработает (точка будет совпадать с символами больше 0x7f): #!/bin/bash LANG=C for ((i = 0x00; i <= 0xff; i++)); do printf "Try '0x%x' - " "$i" echo | sed -e"s/^/\d${i}BB/" >|1.tmp #cat 1.tmp sed -i -e's/.*BB/_&_/' ./1.tmp grep -v -q -e'_BB_' 1.tmp && echo -n "match" || echo -n "not match" echo done Теперь немного теории про utf8. Это общеизвестно, и можно прочитать в том же utf8(7), тем не менее, чтобы все было в одном месте или если кому-то читать неохота, я вкратце напишу здесь. Первый байт в кодировке utf8 - это длина последовательности байтов, которая содержит UCS код данного символа. Причем значение первого байта всегда в диапазоне 0xc0 - 0xfd. Фактически, если посмотреть на двоичную запись, то длина будет количеством единиц вначале этого байта и эта последовательность единиц всегда будет отделена нулем от остальной части байта, которая уже используется для хранения UCS кода символа, т.е 110x xxxx - для 2-байтового utf8 кода 1110 xxxx - для 3-байтового utf8 кода 1111 0xxx - для 4-байтового utf8 кода 1111 10xx - для 5-байтового utf8 кода 1111 110x - для 6-байтового utf8 кода (это максимальная длина кода символа в utf8). 1100 0000 (0xc0) - минимальное значение, 1111 1101 (0xfd) - максимальное значение. Вместо 'x' будет часть битов (старших) UCS кода символа. Остальные байты содержат оставшиеся биты UCS кода символа и их значение всегда в диапазоне 0x80 - 0xbf. Т.е они всегда будут иметь префикс (два старших бита) '10', что сделано, видимо, чтобы они всегда отличались от первого байта и можно было легко обнаружить, что часть многобайтового символа потеряна. Т.е: 10xx xxxx - не-первый байт кода символа в utf8. 1000 0000 (0x80) - минимальное значение, 1011 1111 (0xbf) - максимальное значение. Второй тест. Теперь, установив локаль в utf8, попробуем просто перебирать все возможные двухбайтовые последовательности и смотреть совпадет ли точка c получившимся многобайтовым символом и какие при этом будут значения байтов. Вот скрипт (выполняться он будет очень долго - я до конца так и не дождался, но это и не обязательно - уже вначале станет все видно): LANG=en_US.UTF8 for ((byte1 = 0x00; byte1 <= 0xff; byte1++)); do for ((byte2 = 0x00; byte2 <= 0xff; byte2++)); do printf "Try utf8: byte1 '0x%x', byte2 '0x%x'\n" "$byte1" "$byte2" echo | sed -e"s/^/ \d${byte1}\d${byte2}BB/" >|1.tmp sed -i -e's/.*BB/_&_/' ./1.tmp grep -q -e'^_' 1.tmp && echo -e "\tmatch" || echo -e "\tnot match " printf "\tutf8: byte1 '0x%x', byte2 '0x%x'\n" "$byte1" "$byte2" cat 1.tmp done done (первым символом в каждом файле теперь записывается пробел, поэтому выражение проверки у grep я изменил на '^_') Просмотрев вывод этого скрипта, будет видно, что точка не совпадает только с неправильными utf8 кодами. И, наконец, третий тест. Проверим, что точка совпадет со всеми правильными двухбайтовыми utf8 кодами. В двухбайтном utf8 коде могут быть записаны UCS коды от 0x7f (потому что ascii в utf8 всегда записывается одним байтом) до (2^11 - 1) (те 0x7ff), тк двухбайтовый utf8 код будет иметь вид 110x xxxx 10xx xxxx Здесь одиннадцать букв 'x', т.е UCS код, который мы можем записать с помощью двух байт utf8, должен содержать не больше 11 бит. Скрипт будет работать так (возможно, это не самый оптимальный вариант, но есть ли разница?): переменная ucs_cp перебирает UCS коды от 0x80 до 0x7ff. UCS код я разделяю на две части: byte1 - это часть, которая будет записана в первый байт utf8 кода (тот, что содержит длину последовательности). Сюда записываем 5 старших бит UCS кода (или, другими словами, все, кроме 6 младших бит, - сдвиг на 6 бит вправо). byte2 - это часть, которая будет записана во второй байт utf8 кода. Сюда записываем 6 младших бит UCS кода (или, другими словами, стираем все, кроме 6 младших бит, - побитовое 'И' с 0x3f). Дальше добавляем в начало byte1 '110' (длина многобайтового urf8 кода) - побитовое 'ИЛИ' c 0xc0, - и в начало byte2 добавляем '10' (как к не-первому байту многобайтового utf8 кода) - побитовое 'ИЛИ' c 0x80. Затем byte1 записывается в файл первым (как младший байт), за ним byte2 (как старший байт). После чего идет стандартная проверка совпала ли точка. #!/bin/bash declare -i ucs_cp=0 # UCS code point declare -i byte1=0 # Least significant byte in utf-8 code, containing five # most significant bits of UCS code. declare -i byte2=0 # Most significant byte in utf-8 code, containing six # least significant bits of UCS code. LANG=en_US.UTF8 for ((ucs_cp = 0x80; ucs_cp <= 0x7ff; ucs_cp++)); do printf "Try UCS code '0x%x':\n" "$ucs_cp" byte1=$((ucs_cp >> 6)) byte2=$((ucs_cp & 0x3f)) printf "\tsplit: 1st byte '0x%x', 2nd byte '0x%x'\n" "$byte1" "$byte2" byte1=$((byte1 | 0xc0)) byte2=$((byte2 | 0x80)) printf "\tutf8: byte1 '0x%x', byte2 '0x%x'\n" "$byte1" "$byte2" echo | sed -e"s/^/ \d${byte1}\d${byte2}BB/" >|1.tmp cat 1.tmp sed -i -e's/.*BB/_&_/' ./1.tmp grep -q -e'^_' 1.tmp && echo -n "match" || echo -n "not match" echo cat 1.tmp done В результате, точка совпадет со всеми получившимися символами (скрипт тоже работает небыстро, но дождаться стоит). PS. Не уверен, что ничего не напутал со старшими и младшими битами и байтами, но вроде ж работает :D PS2. И почему-то меня не покидает ощущение, что все это такой большой оффтопик для этого форума.. :D

И правда. Надо же, а я даже не знал, что sed читает многобайтовые символы. Но это все равно ничего не объясняет. Возьмем конкретный пример для 0xb2. Если локаль стоит правильно (допустим, это utf8), то почему 0xb2 не совпадает с точкой? # echo | sed -e's/^/\xb2BB/' >|1.tmp # sed -i -e's/.*BB/_&_/' ./1.tmp # cat 1.tmp ?_BB_ Честно говоря, вообще не понял к чему это. А почему вы думаете, что там echo $LANG у меня будет стоять utf8, а не C, например? Более того, по моим представлениям, что там стоит вообще не должно влиять на работу точки: если там стоит однобайтовая кодировка, значит sed должна (я так думаю) читать файл, записанный в utf8, по байтам. Прочитается он неправильно, ну и что? ascii символы BB будут правильными всегда, а точка должна совпадасть со всем, что осталось.

Ээ.. нет, мне это непонятно. Вопрос ведь в том, почему . (точка) совпадает только с 7-битными символами (вот это непонятно), а откуда их взять - это другой вопрос. И почему обязательно utf8? А может это был файл с обычной 8-битной кодировкой или вообще бинарник -) PS. В качестве небольшого (но, может быть, для кого-то интересного) дополнения. Если совпадение проверять таким скриптом #!/bin/bash for ((i = 0x00; i <= 0xff; i++)); do printf "Try '0x%x' - " "$i" echo | sed -e"s/^/\d${i}BB/" >|1.tmp #cat 1.tmp sed -i -e's/.*BB/_&_/' ./1.tmp grep -v -q -e'_BB_' 1.tmp && echo -n "match" || echo -n "not match" echo done , то получится, что еще 3 символа с кодами меньше 0x7f не совпадут (с '.*' по мнению скрипта): 0x26 (&), 0x5c (\) и 0x5f (_). 0x5f на самом деле совпадает, просто grep по '_BB_' сработает неправильно, если в файле 1.tmp исходная строка '_BB'. 0x5c и 0x26 не совпадут, потому, что (оказывается :huh: ) специальные символы в правой части s/// интерпретируются после преобразования эскейп-последовательностей в символы. Т.е, например: echo abc | sed -e's/\(a\)\(bc\)/_\1_\2/' то же самое, что echo abc | sed -e's/\(a\)\(bc\)/_\x5c1_\x5c2/' и echo abc | sed -e's/.*/_&_/' то же самое, что echo abc | sed -e's/.*/_\x26_/'

Значит, я все-таки не ошибся форумом -) Вы правы, ни для одного из символов больше 0x7f не работает. Осталось понять почему, но это, видимо, уже совсем другая история. Спасибо -)