Зачем нужны альтернативы?

Например:

Support for multibyte characters in UTF-8 and many East Asian encodings.

GNU coreutils этого не умеет. Даже банальный UTF-8.

>Cygwin

всё будет работать

петросян.jpg

> Зачем нужны альтернативы?

Видимо они нужны из-за своей лицензии CDDL:

http://ru.wikipedia.org/wiki/CDDL
--------------------
Файлы, лицензированные под CDDL, могут быть совмещены с файлами под другими открытыми или проприетарными лицензиями. CDDL не является полностью копилефт лицензией. Она позволяет совмещать открытый и закрытый код, защищённый авторскими правами. Как и MPL, CDDL несовместима с лицензией GPL. Это происходит из-за того, что GPL требует удаления всех лицензий и применения GPL вместо них, в то время как CDDL запрещает это. Примером несовместимости является невозможность включения файловой системы ZFS, выпущенной под CDDL, в ядро Linux, выпущенное под GPL.
--------------------

А в OpenBSD нет такого?

А есть же OpenBSD?

>А в OpenBSD нет такого?
Чего такого? *BSD (кроме FreeBSD местами) умеют юникод ещё хуже, чем coreutils. И не умеют тонну фич GNU coreutils (на которые завязаны некоторые скрипты).

many East Asian encodings.

Вообще уникальная фича среди *nix-софта. От EUC-кодировок сносит крышу почти всему гнутому. GNU is Not Unicode-safe, даже сейчас до некоторых GNU-разработчиков не доходит, что кому-то прийдёт в голову обрабатывать текст вне семибитного ASCII консольным софтом. Just for fun, что с них взять.
И, кроме всего прочего, heirloom полностью совместим с древними unix™ утилитами.

GNU coreutils этого не умеет. Даже банальный UTF-8.

я просто оставлю это здесь:

pinkbyte@oas2 ~ $ equery b /bin/ls
[ Searching for file(s) /bin/ls in *... ]
sys-apps/coreutils-8.7 (/bin/ls)
pinkbyte@oas2 ~ $ locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=
pinkbyte@oas2 ~ $ ls -la | head -1
итого 82280

Если это не UTF-8, то я уж прямо и не знаю...

Если это не UTF-8, то я уж прямо и не знаю...

Ты упорот? ls не обрабатывает текст.

@madoka~>echo 'Привет, the cruel 世界'|tr '[а-я]' '[А-Я]' 
°±°°°±, the cruel 䘖界
@madoka~>echo 'Привет, the cruel 世界'|~/bin/tr '[а-я]' '[А-Я]'  #heirloom toolchest тут.
ПРИВЕТ, the cruel 世界
@madoka~>equery b `which tr`
 * Searching for /usr/bin/tr ... 
sys-apps/coreutils-8.12 (/bin/tr)
sys-apps/coreutils-8.12 (/usr/bin/tr -> /bin/tr)
@madoka~>locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=C
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES=en_US.UTF-8
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

NAME tr - translate or delete characters

В манах стоит сделать s/characters/bytes/g. Всё равно это говно по-другому работать не умеет.

>ls не обрабатывает текст.

а зачем ему обрабатывать текст? libc нынче отменили?

echo 'Привет, the cruel 世界' | tr тервпинаомг ТЕРВПИНАОМГ
ПРИВЕТ, the cruel 䘖界

то, что есть бага с [ и ] еще не значит отсутвие поддержки

>䘖界
Если у тебя нет шрифтов: 世界 ≠ 䘖界. GNU coreutils убивает юникодный текст, что ты только что доказал.

>libc нынче отменили?
Чтобы libc работало, нужно юзать wchar и вообще быть в курсе того, что байт ≠ символ.

> А зачем нужны альтернативы гнутым утилитам?

Да, ГНУ, мягко говоря, не работет.

Люблю людей, которые, даже зная ответ на свой вопрос, задают его.

при чем здесь неправильно отображение символа и отстутствие юникода? я еще раз говорю - если не использовать [ и ] - все прекрасно работает

Чтобы libc работало, нужно юзать wchar и вообще быть в курсе того, что байт ≠ символ.

прикинь, я в курсе, т.к. программы на C писал. Но вот хоть убей не могу понять что значит «убивает юникод»?

>Если у тебя нет шрифтов: 世界 ≠ 䘖界

с таким же успехом при отстутствии шрифтов я могу предъявить претензии к Qt, Gtk и прочим. Я тебе выдал рабочий пример. Что тебя в нем не устраивает, объясни мне, может я где-то туплю?

>с таким же успехом при отстутствии шрифтов я могу предъявить претензии к Qt, Gtk и прочим.
Мда. Для слепых: оно сломало иероглиф. Вместо U+4E16 сделало U+4616 Шрифты тут ни при чём. Тулкиты никогда такого не сделают.
Естественно, ломает оно далеко не одни иероглифы.

Естественно, ломает оно далеко не одни иероглифы.

@madoka~>echo 'Приветафывафоывимжврапфукрфпжровсчляютмсюловпрфук' | tr тервпинаомг ТЕРВПИНАОМГ      
ПРИВЕТАЄЋВАЄОЋВИМжВРАПЄЃкРЄПжРОВЁЇлЏЎТМЁЎлОВПРЄЃк
@madoka~>echo 'Приветафывафоывимжврапфукрфпжровсчляютмсюловпрфук' | ~/bin/tr тервпинаомг ТЕРВПИНАОМГ 
ПРИВЕТАфыВАфОыВИМжВРАПфукРфПжРОВсчляюТМсюлОВПРфук

нда, это действительно фигня

Для слепых: оно сломало иероглиф

ты думал я иероглифы по кодам наизусть знаю? теперь уже понял где косяк. Да, нездраво это тогда.

Вот высказывание авторитетного линуксоида: «Да, например, программа tr из набора coreutils до сих пор юникода не понимает. Вообще. grep и sed понимают, но на такой скорости, что почти не понимают. Скорость работы падает на порядки. На десятичные порядки, а не двоичные».

Дополню исследованиями другого пользователя (месячной давности):

GNU grep 2.7
./configure --prefix=/usr --bindir=/bin --with-included-regex

$ echo ПРИВЕТ | LANG=C grep '[а-я]'
grep: Invalid collation character
$ echo ПРИВЕТ | LANG=ru_RU.UTF-8 grep '[а-я]'
ПРИВЕТ

GNU grep 2.5.3, Debian GNU/Linux Lenny

$ echo ПРИВЕТ | LANG=C grep '[а-я]'
ПРИВЕТ
$ echo ПРИВЕТ | LANG=en_US.UTF-8 grep '[а-я]'
$

GNU grep 2.6.3, Debian GNU/Linux Squeeze

$ echo ПРИВЕТ | LANG=en_US.UTF-8 grep '[а-я]'
ПРИВЕТ
$ echo ПРИВЕТ | LANG=ru_RU.UTF-8 grep '[а-я]'
ПРИВЕТ
$ echo ПРИВЕТ | LANG=C grep '[а-я]'
$
# echo ПРИВЕТ | LANG=en_US.UTF-8 sed -n '/[а-г]/p'
# echo ПРИВЕТ | LANG=C sed -n '/[а-г]/p'
ПРИВЕТ

В конце концов он прходит к следующему выводу: «Въ grep ошибки нѣтъ, а ошибка въ glibc (появилась вновь?)»

А что до гнутых расширений в скриптах, так лучше уж скрипты переписать в строгом соответствии с POSIX.

Въ grep ошибки нѣтъ, а ошибка въ glibc (появилась вновь?)

grep 2.7 у меня (кроме нескольких искуственных примеров) нормально работает. То есть:

@madoka~>echo ПРИВЕТ | grep '[а-я]'
[1] @madoka~>echo привет | grep '[а-я]'
привет

А что до гнутых расширений в скриптах, так лучше уж скрипты переписать в строгом соответствии с POSIX.

Зачем? Они часто пишутся под конкретный дистрибутив. В нём утилиты заведомо умеют нужные расширения. Ну и с расширениями банально удобнее.

Дополню исследованиями другого пользователя (месячной давности):

Во всех примерах grep работает некорректно. Если он без алиасов, конечно.