Perl везде?

обычно в корпоративной политике четко указывается какой *nix должен использоваться, от этого и танцевать

AFAIK, perl входит в LSB.

Вот это интерестно. А есть ссылка?

у меня нет. когда-то на лоре кто-то говорил об этом, запомнилось.

>Естественно Bash c awk, sed и всякими регекспами практически нечитаем. С другой стороны я знаком с Perl и у него есть много удобный структур данных, работа с которыми если не усердствовать джедайством достаточно читаема другими разработчиками.

вообще-то, если не извращаться, и следовать стилю, то bash && sed && awk читаются не хуже перловки. А если сравнивать одностроки, то sed короче. И также непонятно.

bash-а может не быть на unix-ах, значит надо писать на sh
версии unix и linux sed и awk могут работать по разному
так что это не вариант, зато перл он везде перл

Ну у него есть вменяемые мепы, массивы, списки, все что надо. Конечно может в баше тоже что-то такое есть, еще не проверял, но то что я видел это просто магия запускания стремных утилиток с неясными параметрами.

>bash-а может не быть на unix-ах, значит надо писать на sh версии unix и linux sed и awk могут работать по разному так что это не вариант

это не так. sed & awk имеют GNU-расширения, но и умеют работать так, как требует того POSIX. Вы не обязаны использовать специфические гнутые фичи (в документации сказано, что есть гнутая фича, а что - стандарт).

В перле тоже есть нестандартные фишки, никто не переживает.

>Ну у него есть вменяемые мепы, массивы, списки, все что надо. Конечно может в баше тоже что-то такое есть, еще не проверял, но то что я видел это просто магия запускания стремных утилиток с неясными параметрами.

в bash'е всё есть. причём всё там более нагляднее и понятнее, чем в перле. Однако:

1) баш не стандартный

2) баш тормозной

http://refspecs.freestandards.org/LSB_4.0.0/LSB-Languages/LSB-Languages.pdf

Python там тоже есть.

версии unix и linux sed и awk могут работать по разному

К тому же, на всяких Unix'ах c большой долей вероятности стоят именно свои реализации sed'ов, awk'ов и прочего. Поэтому, если ТС юзает gawk, то это нужно как минимум тоже понимать.

Только что посмотрел, то на целевой машине есть Perl, что радует. Думаю попробовать с ним

К тому же Perl скрипты написаные для unix отлично работают без правки даже на винде с ActivePerl (если не использовать специфичные модули и не вызывать библиотечные функции/сисколлы и поправить пути к файлам).

>К тому же Perl скрипты

sed-скрипты тоже.

Но на самом деле, ТС хочет найти «универсальный молоток», что-бы любые болты забивал... perl - хороший выбор. хотя я предпочитаю закручивать болты ключом, а шурупы - отвёрткой.

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

А кто - нет? Хорошо бы только знать, с чем придётся иметь дело, с болтами или с гвоздями...

>Естественно Bash c awk, sed и всякими регекспами практически нечитаем

Перл же тоже.

>А кто - нет? Хорошо бы только знать, с чем придётся иметь дело, с болтами или с гвоздями...

для каждой задачи нужен свой инструмент. Конечно, области применения пересекаются, и для многих задач можно использовать разные инструменты. Все перечисленные вами ЯП являются Тьюринг-полными, а значит, ЛЮБУЮ задачу можно решить ЛЮБЫМ из перечисленных ЯП. Это теория. На практике, для решения разных задач нужны разные инструменты. Например sed не умеет считать. А perl без костылей не понимает UTF-8. Т.е. сделать фильтр мата на перле конечно можно, но он будет более громоздким и менее переносимым, чем фильтр на sed. А вот для работы с полями, и для чисел пойдёт awk. Ну а если ваша задача решается несколькими командами из coreutils, то перл тут тоже не нужен - просто юзайте shell.

А perl без костылей не понимает UTF-8

O_o?

о... ещё один.

ок. Смените в тексте все слова написанные БОЛЬШИМИ буквами так, что-бы Первая Буква была большой. остальные маленькие.

угу, я тоже фшоке. несколько лет пишу скрипты на перле для обработки текста в ютф8, и тут вдруг drBatty открывает глаза на истину. как дальше жить, как жить...

> Смените в тексте все слова написанные БОЛЬШИМИ буквами так, что-бы Первая Буква была большой. остальные маленькие.

может тебе есть смысл перл подучить?

$ perl -Mutf8 -Mencoding=utf8 -pe 's/\b([А-ЯЁ])([А-ЯЁ]*)\b/\u$1\L$2/g' <<<'ПРИВЕТ МИР! HELLO WORLD! привет мир! ПрИвЕт мИр!'
Привет Мир! HELLO WORLD! привет мир! ПрИвЕт мИр!

>может тебе есть смысл перл подучить?

ну вот про явное указание кодировки я и говорил...

-Mutf8 -Mencoding=utf8

по твоему два этих модуля не являются «дополнительными костылями»? Или ты наивно думаешь, что я не знаю что такое -M?

> по твоему два этих модуля не являются «дополнительными костылями»?

точняк. кодировок много, а либастрал пока к перлу не прикрутили, да.

либастрал пока к перлу не прикрутили, да.

а к sed прикрутили. Попробуй сам:

ksu@ksu:~$ echo "непонятная нёх: Rusya Anayasasına göre, Rusya yarı başkanlık sistemi ile yönetilmektedir. Başkan, devletin başkanı statüsündeyken; Başbakan, hükümetin başıdır. Çok partili temsili demokrasi ile yönetilen federasyonda, federal hükümet 3 temel erkden mevcuttur" | sed 's/.*/\U&/''
НЕПОНЯТНАЯ НЁХ: RUSYA ANAYASASINA GÖRE, RUSYA YARI BAŞKANLIK SISTEMI ILE YÖNETILMEKTEDIR. BAŞKAN, DEVLETIN BAŞKANI STATÜSÜNDEYKEN; BAŞBAKAN, HÜKÜMETIN BAŞIDIR. ÇOK PARTILI TEMSILI DEMOKRASI ILE YÖNETILEN FEDERASYONDA, FEDERAL HÜKÜMET 3 TEMEL ERKDEN MEVCUTTUR

>непонятная нёх

э...

[code]sed --version[/code]

?

это у вас похоже стоит негнутая sed, поставьте гнутую из портов. По POSIX Ё не буква. Не?

> а к sed прикрутили. Попробуй сам

$ iconv -t utf8 >test.utf8 <<<'Привет, мир!'
$ iconv -f utf8 test.utf8
Привет, мир!
$ sed -i 's/.*/\U&/' test.utf8
$ iconv -f utf8 test.utf8 
iconv: недопустимая входная последовательность в позиции 0
$ _

$ iconv -t utf8 >test.utf8 <<<'Привет, мир!'
$ iconv -f utf8 test.utf8
Привет, мир!
$ perl -Mopen=utf8 -i -pe 's/.*/\U$&/' test.utf8
$ iconv -f utf8 test.utf8 
ПРИВЕТ, МИР!
$ _

ну чо, продолжай развивать мыслю о костылях ;)

Меня терзают смутные сомнения насчёт того, что hizel сейчас всё бросит и побежит менять на своей фре sed на гнутый.

Да он есть практически на всех *nix машинах,ибо как говорили стандарт.
По твоей задачи существует куча модулей натом же cpan.org и также часть ан github тоже

ну чо, продолжай развивать мыслю о костылях ;)

ksu@ksu:~$ iconv -t utf8 >test.utf8 <<<'Привет, мир!'
ksu@ksu:~$ iconv -f utf8 test.utf8
Привет, мир!
ksu@ksu:~$ sed -i 's/.*/\U&/' test.utf8
ksu@ksu:~$ iconv -f utf8 test.utf8 
ПРИВЕТ, МИР!

Если система в UTF-8, то и sed в UTF-8. А твоя система очевидно в другой кодировке. Соответственно и sed работает В ДРУГОЙ кодировке, которую ТЫ считаешь самой хорошей. Можешь указать своей sed, что ты хочешь работать именно в UTF-8. LC_COLLATE ЕМНИП.

Вообще я вас не понимаю - вы на бегинеров произвести впечатление хотите? Дык я ваш perl тоже могу поломать. Там и ломать ничего не надо:

ksu@ksu:~$ echo 'Привет, мир!' | perl -pe 's/.*/\U$&/'
Привет, мир!
ksu@ksu:~$ echo 'Привет, мир!' | sed 's/.*/\U&/'
ПРИВЕТ, МИР!

без всяких настроек и костылей перловка не работает, а sed работает.

И ещё: я и НЕ говорил, что perl - отстой. Это ты видимо сам домыслил. Просто не для всех задач этот ваш любимый перл - лучший ЯП. Если-бы это было так, то все остальные ЯП выкинули-бы на свалку.

>Меня терзают смутные сомнения насчёт того, что hizel сейчас всё бросит и побежит менять на своей фре sed на гнутый.

это его проблема.

>Да он есть практически на всех *nix машинах,ибо как говорили стандарт.

sed тоже стандарт, и есть на всех машинах. ну кроме венды.

> Можешь указать своей sed, что ты хочешь работать именно в UTF-8.

«указывать кодировку явно? нет пути! костыль же!» © drBatty ;)

> без всяких настроек и костылей перловка не работает, а sed работает.

конечно ;)

> sed тоже стандарт

sed — стандарт. позиксовый sed, не гнутый. результат работы позиксового ты уже видел.

«указывать кодировку явно? нет пути! костыль же!» © drBatty ;)

дык ты в iconv ЯВНО указал, а в sed - неявно. Либо трусы, либо крестик.

Фокус в том, что sed берёт кодировку из окружения, впрочем как и iconv (а ты что-то против iconv имеешь? А что так?). А вот perl так не умеет (ну я не знаю как. Покажи, если умеет). Т.е. sed скрипт будет отлично работать в любом Linux'е, какая-бы там кодировка не была. Конечно сам скрипт должен быть в той-же самой кодировке, как и всё остальное. Перловому скрипту надо ещё и кодировку прописать. Что напрягает - сам знаешь - скриптов много, и они мелкие. Это не один большой С++ проект.

В твоём примере ты перевёл кодировку в неродную для системы, а sed у тебя так в родной и работает. Вот кривизна и случилась. Оно и без sed так будет:

$ echo "тест" | iconv -t cp1251 | iconv
iconv: недопустимая входная последовательность в позиции 0

и так с любой командой, которая понимает и знает utf-8. Например iconv.

Perl везде? (комментарий)

ну и что? sed работает в ТВОЕЙ кодировке, как и все программы. Что тут удивительного? Я не виноват, что у тебя до сих пор не UTF. Windows?

>sed — стандарт. позиксовый sed, не гнутый. результат работы позиксового ты уже видел.

стандартный POSIX'овый перл работает в точности так же.

>POSIX'овый перл

какой какой? :-D

> дык ты в iconv ЯВНО указал, а в sed - неявно. Либо трусы, либо крестик.

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

> Фокус в том, что sed берёт кодировку из окружения, впрочем как и iconv … А вот perl так не умеет (ну я не знаю как. Покажи, если умеет).

я тебе ещё в самом начале сказал: учи перл, ****, учи его! perl -Mencoding=:locale ...

> Т.е. sed скрипт будет отлично работать в любом Linux'е, какая-бы там кодировка не была.

звучит как «sed скрипт будет отлично работать в любом моём Linux'е, какая-бы там utf8-кодировка не была».

> Конечно сам скрипт должен быть в той-же самой кодировке, как и всё остальное. Перловому скрипту надо ещё и кодировку прописать. Что напрягает - сам знаешь - скриптов много, и они мелкие. Это не один большой С++ проект.

нет, я столько не выпью...

> В твоём примере ты перевёл кодировку в неродную для системы, а sed у тебя так в родной и работает. Вот кривизна и случилась. Оно и без sed так будет…

ты совершенно ничего не понял…

> ну и что? sed работает в ТВОЕЙ кодировке

а как же либастрал? ты же обещал…

> Я не виноват, что у тебя до сих пор не UTF. Windows?

ты, наверное, очень удивишься, но под многими юниксами(<--) системные скрипты запускаются под LC_ALL=C. внезапно, да?

> стандартный POSIX'овый перл работает в точности так же.

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

можно и на php писать, почему бы и нет :-)

а в сэд я вообще ничего не указывал, ни явно, ни неявно, ибо ман по сэду вообще ничего не говорит по этому поводу

4.2

`[a-z]' is case insensitive You are encountering problems with locales. POSIX mandates that `[a-z]' uses the current locale's collation order - in C parlance, that means using `strcoll(3)' instead of `strcmp(3)'. Some locales have a case-insensitive collation order, others don't.

Another problem is that `[a-z]' tries to use collation symbols. This only happens if you are on the GNU system, using GNU libc's regular expression matcher instead of compiling the one supplied with GNU sed. In a Danish locale, for example, the regular expression `^[a-z]$' matches the string `aa', because this is a single collating symbol that comes after `a' and before `b'; `ll' behaves similarly in Spanish locales, or `ij' in Dutch locales.

To work around these problems, which may cause bugs in shell scripts, set the `LC_COLLATE' and `LC_CTYPE' environment variables to `C'.

`s/.*//' does not clear pattern space This happens if your input stream includes invalid multibyte sequences. POSIX mandates that such sequences are _not_ matched by `.', so that `s/.*//' will not clear pattern space as you would expect. In fact, there is no way to clear sed's buffers in the middle of the script in most multibyte locales (including UTF-8 locales). For this reason, GNU `sed' provides a `z' command (for `zap') as an extension.

To work around these problems, which may cause bugs in shell scripts, set the `LC_COLLATE' and `LC_CTYPE' environment variables to `C'.

а как же либастрал? ты же обещал…

извини. чудес не бывает :-)

ы, наверное, очень удивишься, но под многими юниксами(<--) системные скрипты запускаются под LC_ALL=C. внезапно, да?

осиль отквоченную цитату... Я думал, человек со звёздами хотя-бы документацию читать умеет.. :-(

>можно и на php писать, почему бы и нет

я тут проверил - php по умолчанию плевал на локаль, и считает букву Ф двумя символами :)

>и считает букву Ф двумя символами

имеется ввиду в PCRE.