Представлен (http://lists.gnu.org/archive/html/info-gnu/2013-05/msg00003....) новый значительный релиз реализации языка программирования AWK от проекта GNU - Gawk 4.1.0 (http://www.gnu.org/software/gawk). AWK был разработан в 70-х годах прошлого века и не претерпел значительных изменений с середины 80-х годов, в которых был определен основной костяк языка, что позволило на протяжении последних десятилетий сохранить первозданную стабильность и простоту языка. Несмотря на преклонный возраст, AWK до сих пор активно используется администраторами для выполнения рутинных работ, связанных с парсингом различного рода текстовых файлов и генерации несложной результирующей статистики.
Из добавленных в новом выпуске улучшений можно отметить поддержку арифметики высокой точности при сборке с библиотекой MPFR (http://www.mpfr.org/); полностью переработанный интерфейс для создания динамически подключаемых расширений на языке Си, которые можно использовать как функции на AWK; объединение интерпретатора gawk, системы профилирования pgawk и отладчика dgawk в рамках единого исполняемого файла gawk; новые опции "-i" и "-l" для загрузки библиотек и динамических расширений; новое расширение "inplace" для симуляции "sed -i"; новые массивы: SYMTAB, FUNCTAB и PROCINFO["id"].URL: http://lists.gnu.org/archive/html/info-gnu/2013-05/msg00003....
Новость: http://www.opennet.me/opennews/art.shtml?num=36909
inplace достаточно удобно.
Сложившийся в юниксах (да и не только) алгоритм "одна программа генерирует человекочитаемые данные - другая программа их парсит" напоминает наших дорожников, которые старательно кладут асфальт во время снегопада (на обледеневшую землю и слой снега), а потом перекладывают его летом (разумеется, под проливным дождем, на размокший песок).Фактически, при преобразовании данных в "человекочитаемую" форму теряется информация об их структуре (в частности, о разделении между полями). grep, sed, awk - не более чем костыли, которые предназначены для попыток восстановления структуры данных (выделить конкретное поле из записи, отвечающей заданному условию). При том, что в "машиночитаемой" форме такой проблемы нет как класса - почти любая модификация SQL позволяет играючи решить то, для чего "опытные админы" громоздят на bash, sed и awk многоэтажные карточные домики (рушащиеся от малейшего изменения синтаксиса исходных данных, или просто криво написанного шаблона, не учитывающего некоторые неочевидные случаи).
Гораздо более правильным и логичным было бы хранить подобные данные в машиночитаемом виде (например, SQLite или его NoSQL аналоги), а в человекочитаемую форму преобразовывать только по запросу администратора и при генерации отчетов. Помимо устранения проблем с парсингом, это дает и многие другие фичи - возможности индексирования, сжатия, избыточного кодирования, криптографического контроля целостности и т.д.
Разумеется, вышесказанное не относится к тем ситуациям, когда нужно распарсить не вывод программы, а текст из внепрограммного источника - в таком случае, конечно, sed и awk будут на своем месте. Ну а применимость их для не-парсинговых задач - это уже вопрос личного вкуса.
Много-премного букв и всё равно мимо. sed/awk прекрасно справляются с теми задачами, для к-х они разрабатывались, несмотря на ваше недовольство этим.
> Много-премного букв и всё равно мимо. sed/awk прекрасно справляются с теми задачами,
> для к-х они разрабатывались, несмотря на ваше недовольство этим.С точки зрения админа локалхоста, да еще под виндой - безусловно.
А вот админы продакшенов могут рассказать много веселых историй про неожиданно ломающиеся парсеры.
Видать криворукие админы. У меня куча серверов в продакшене на CentOS, включая инсталляции Оракла с RAC, ничего никогда не ломается.
> Видать криворукие админы. У меня куча серверов в продакшене на CentOS, включая
> инсталляции Оракла с RAC, ничего никогда не ломается.Не ошибается тот, кто ничего не делает :)
Или тот, кто уже все сделал.
> Не ошибается тот, кто ничего не делает :)админ тогда много делает, когда у него что-то не работает.
потому тот админ, что не ошибается, не нуждается в делании.
а ошибающийся да скорректирует скрипты свои.
> Видать криворукие админы. У меня куча серверов в продакшене на CentOS, включая
> инсталляции Оракла с RAC, ничего никогда не ломается.Ты еще молодой, у тебя все еще впереди...
Всмысле, стану таким же криворуким, как ты?
Так это неожиданно меняющийся поток входных данных.
Было doc стало docx :)
> Много-премного букв и всё равно мимо. sed/awk прекрасно справляются с теми задачами,
> для к-х они разрабатывались, несмотря на ваше недовольство этим.Я недоволен как раз тем, что они НЕ справляются со своими задачами.
Но самое идиoтское в этой ситуации - что если бы разработчики сначала думали, а потом кодили, такого класса задач вообще не было бы. Абсолютно избыточная сущность.
>если бы разработчики сначала думали, а потом кодили..это не энтерпрайзно
> Я недоволен как раз тем, что они НЕ справляются со своими задачами.а что вы пытаетесь с их помощью делать, если не секрет? и как?
проекты открытые - надо все баги, минусы и пожелания описать и выложить на обсуждение.
иначе ж ведь какой ресурс впустую расходуется, ежель все те разрабы столько времени зря тратят.
Это не Вы придумали такую гениальную вещь, как "Реестр Майкрософт Уиндоуз"?В таком случае, лучи добра и счастья Вам от миллионов благодарных администраторов!
Справедливости ради стоит отметить, что такие админы сами виноваты в своих бедах, выбрав администирование такой ОС в качестве средств зарабатывания денег :)
> Это не Вы придумали такую гениальную вещь, как "Реестр Майкрософт Уиндоуз"?"Реестр Майкрософт Уиндоуз" - не менее гениальная идея, чем awk. Но я не придумывал ни то, ни другое :)
Реестр, действительно неплохая вещь, но ему не хватает устойчивости к повреждениям носителя, ошибка в одном байте - и до свиданья, куст не грузится. Мне однажды пришлось лечить реестр hex-редактором погостика, хз что там случилось, но полдня ушло коту под хвост. Какой-нибудь Рид-Соломон был бы там весьма кстати.
> Реестр, действительно неплохая вещь, но ему не хватает устойчивости к повреждениям носителя,
> ошибка в одном байте - и до свиданья, куст не грузится.Имхо, он был бы неплохой вещью, если бы его применяли с умом, а не превращали в склад костылей.
Да и избыточное кодирование можно было бы предусмотреть.
Подскажите, чем эта идея неполха?Зачем продить ещё одну сущность, если уже есть файловая система? Та же древовидная структура, что и ФС. Разве нет?
Человекочитаемые логи сделаны для человека. Их можно вывести на экран и принтер. Они всегда под рукой когда недоступны "высоктехнологичные" инструменты. И уж совсем хорошо, когда при "лазании" по логам, под рукой awk. Изобилие разных инструментов под рукой лучше чем их дифицит. Умейте применять их по назначению.
> Человекочитаемые логи сделаны для человека. Их можно вывести на экран и принтер.
> Они всегда под рукой когда недоступны "высоктехнологичные" инструменты.Я уже сто лет как не грузился с дискеты. А вы, видимо, делаете это регулярно?
> И уж совсем хорошо, когда при "лазании" по логам, под рукой awk. Изобилие разных
> инструментов под рукой лучше чем их дифицит. Умейте применять их по
> назначению.Реестр винды - тоже инструмент. Принес он счастье своим пользователям?
> И уж совсем хорошо, когда при "лазании" по логам, под рукой awk. Изобилие разных инструментов под рукой лучше чем их дифицит.Наличие _некоторых_ инструментов, а также их активное использование - может быть вполне отрицательным признаком.
Точно так же, как наличие и использование костылей и инвалидной коляски свидетельствует о проблемах со здоровьем. Это не те вещи, которые я хотел бы иметь у себя дома. И тем более - нуждаться в них.
> Наличие _некоторых_ инструментов, а также их активное использование - может быть вполне
> отрицательным признаком.Вот если бы мир ИТ вот так вот сию минутно взял и родился сразу с "правильными" инструментами никто бы не спорил. Но так получилось что каждому из нас далось по-разному столкнуться с его многоообразием. Если вашу жизнь не коснулась необходимость анализа текстовых файлов/логов то это может сказать лишь о том, чего небыло у вас. Но это никак не означает что этого нет вовсе и тем более, что оно не нужно. Повторюсь, мир ИТ не родился внезапно во всей своей красоте и правильности.
Вот кстати характерный же пример как винузятники в силу каких-то благоприобритенных проблем с головой не в силах понять элементарных фактов, если они носят умозрительную, а не эмпирическую (т.е. не из брошюрок Свидетелей Микрософта) природу.Например, что от сериализации-десериализации или экранирования-деэкранирования никакой "информации" никуда потеряться не может.
> Например, что от сериализации-десериализации или экранирования-деэкранирования никакой
> "информации" никуда потеряться не может.Качественная десериализация "человекочитабельного" вывода отнюдь не тривиальная задача.
Даже с точки зрения дизайна, оверхед получается ощутимый.Впрочем, учитывая, как "качественно" на практике делают десереализацию - главная проблема уже не простота и логичность архитектуры, а надежность.
Десериализация это фактически парсер. Это элементарное приложение теории формальных грамматик.
Не умеешь писать парсеры, сто бамбуков по пяткам тому, кто диплом тебе дал.
Не можешь написать свою ОС. Сто бамбуков по пяткам.
Не можешь написать модуль ядра для Линукс. Сто бамбуков по пяткам.
Не можешь написать написать много поточную сортировку в B-tree. Сто бамбуков по пяткам.
Не можешь пропатчить KDE4 под freebsd. Сто бамбуков по пяткам.
> много поточную32767 ударов по пяткам во имя Розенталя.
впрочем, подозреваю, что тебя не излечит. а анонимус, который написал про парзеры, прав.
>[оверквотинг удален]
> Гораздо более правильным и логичным было бы хранить подобные данные в машиночитаемом
> виде (например, SQLite или его NoSQL аналоги), а в человекочитаемую форму
> преобразовывать только по запросу администратора и при генерации отчетов. Помимо устранения
> проблем с парсингом, это дает и многие другие фичи - возможности
> индексирования, сжатия, избыточного кодирования, криптографического контроля целостности
> и т.д.
> Разумеется, вышесказанное не относится к тем ситуациям, когда нужно распарсить не вывод
> программы, а текст из внепрограммного источника - в таком случае, конечно,
> sed и awk будут на своем месте. Ну а применимость их
> для не-парсинговых задач - это уже вопрос личного вкуса.И как тебе это помогает парсить "журнал событий в уиндоусе"? :)
> И как тебе это помогает парсить "журнал событий в уиндоусе"? :)А никак. Я не админю винду :)
Как балабол-гуманитарий вобще может что-то админить?
> И как тебе это помогает парсить "журнал событий в уиндоусе"? :)А в чем проблема парсить журнал событий винды?
Если лень с его структурой разбираться, то вполне можно выгнать его в текст и парсить через perl (awk, sed ...). А если не лень, то можно обращаться к журналу почти на SQL. (Регулярная структура этому вполне способствует).Структура текстовых логов частенько ломается при обновлении программ. На моей памяти скрипты не раз ломались только из-за того, что автор программы решил орфографию исправить.
Наличие отличных инструментов для работы с текстом совсем не означает отказ от других инструментов. Лог это база данных, а базы данных удобней хранить и обрабатывать соответствующими инструментами. Например, при отсутствии жесткой структуры, возможно, текстовое представление самое удобное, а как только появляется структура в данных - текст не самый удобный вид. Но, соглашусь, самый универсальный.
Статей "как к винде прикрутить сислог" вагон и тележка, несколько платных версий сислога и бесплатные версии. И что-то не видно желающих прикрутить евентвьювер (и прочее что радует пользователей винды) к линуху. Наверное все глупые такие.
1. Статей как заменить syslog на что-то другое и в том числе на коммерческие версии, если в тележках измерять, то обоз будет в разы длиннее.
2. В смешанных средах многим хочется однотипного управления. Если внимательно поищете, то найдете и как Linux машины в AD интегрируют. Кому-что удобнее/привычние. Но мы же не будем отклонения принимать за абсолютное решение?
3. Большинство решений а ля syslog на винде это просто парсинг стандартного журнала событий ибо это _очень_ просто.
4. А зачем Event _viewer_ прикручивать куда-либо еще? Это же просто viewer и к формату лога в виндах относится как viewer. Не нравится встроенный - делай как в нормальных операционках: читай/управляй скриптом
5. То, что радует пользователей виндов, а равно и пользователей Linux, к формату логов вообще отношения не имеет т.к. гуевые вьюеры логов под Linux еще более убоги т.к. админам они нафиг не сдались (и под виндами и под Linux)
> Статей как заменить syslog на что-то другое и в том числе на коммерческие версии, если в тележках измерять, то обоз будет в разы длиннее.Расскажите что там за логирование такое не сислогового формата. И как это успешно применяется.
> В смешанных средах многим хочется однотипного управления.
Это когда суп, кисель и мороженное вилкой есть? Ваше право.
> Если внимательно поищете, то найдете и как Linux машины в AD интегрируют. Кому-что удобнее/привычние. Но мы же не будем отклонения принимать за абсолютное решение?
От этого там появятся политики и прочие штучки? Нет? Какая досада.
> Большинство решений а ля syslog на винде это просто парсинг стандартного журнала событий ибо это _очень_ просто.
И большинству нужно именно это - текст на которые можно травить давно проверенные утилиты и возможность лить логи по сети на один сервер.
> А зачем Event _viewer_ прикручивать куда-либо еще?
Ну это же не меня радует единобезобразие управления логами. Наверное желающих такие фичи получить под линухом пруд пруди?
> Статей "как к винде прикрутить сислог" вагон и тележка, несколько платных версий
> сислога и бесплатные версии. И что-то не видно желающих прикрутить евентвьювер
> (и прочее что радует пользователей винды) к линуху. Наверное все глупые
> такие.КААК НЕТ? А Поттеринг хто такой, не слыхали? Он-то вот такой вот умный и есть...
в юниксах (да и не только) алгоритм "одна программа генерирует человекочитаемые
> данные - другая программа их парсит" напоминает наших дорожников,Полная ерунда. "Write programs that do one thing and do it well." -- выверено опытом и "кровью". Альтернативы -- ad-hoc специализированны, переумудренные вещи, пользоваться которыми никто не будет и не захочет.
> Фактически, при преобразовании данных в "человекочитаемую" форму теряется информация об их структуре (в частности, о разделении между полями).Где именно она теряется? Человекочитаемую, потому как для человека предназначена, а не для "Шиндошс админа"
Awk, sed, sort (и даже Perl) имеют также и вспомогательную роль, служат также, как и bash для связи между утилитами. Отсутствие вменяемых утилит мы видим на примере Виндовс, где к тому также пришли через 20 лет (Power Shell)
Основные преимущества их суть две вещи: 1) простота, 2) скорость Regex выражения родом именно из awk, s(ed) Те самые выражения будут использованы и в SQL (напр., PostgreSQL) Инфа, кстати, там тоже в тексте хранится. SQL не имеет преимущества в скорости без индексирования. Много работы, места и т. д. К тому же нет универсальности.К тому же, все эти утилиты легко "вставляемы" в другие утилиты и программы, например, Emacs. Очень мило там работают. Вы что предлагаете, каждый раз заново изобретать менее эффективный велосипед?
> в юниксах (да и не только) алгоритм "одна программа генерирует человекочитаемые
>> данные - другая программа их парсит" напоминает наших дорожников,
> Полная ерунда. "Write programs that do one thing and do it well."
> -- выверено опытом и "кровью". Альтернативы -- ad-hoc специализированны, переумудренные
> вещи, пользоваться которыми никто не будет и не захочет.Альтернатива - не придумывать лишние things, чтобы не пришлось их делать. Неужели это так сложно?
> Где именно она теряется? Человекочитаемую, потому как для человека предназначена
Предназначенную для человека информацию должен читать только человек. За попытки скормить ее программам надо бить по рукам.
> Основные преимущества их суть две вещи: 1) простота, 2) скорость
Вы очень точно отметили их основные недостатки (сложность и тормознутость). Правда, непонятно, почему вы считаете их достоинствами.
> Regex выражения родом именно из awk, s(ed) Те самые выражения будут использованы и в SQL (напр., PostgreSQL) Инфа, кстати, там тоже в тексте хранится.
Если архитектор ПО феерически криворук - да. Например, запись из rsyslog в SQL. Кой мне толк от того, что оно в базу запихано, если там все равно текстовая каша?
> SQL не имеет преимущества в скорости без индексирования.
При правильной архитектуре (когда никаких regexpов нафиг не надо) - имеет, и еще какое. Просто потому, что не надо парсить текст (очень медленная и сложная работа).
> Много работы, места и т. д. К тому же нет универсальности.
Да, это безусловные недостатки plain textа.
> К тому же, все эти утилиты легко "вставляемы" в другие утилиты и
> программы, например, Emacs. Очень мило там работают. Вы что предлагаете, каждый
> раз заново изобретать менее эффективный велосипед?Наоборот, это вы такое предлагаете :)
>> -- выверено опытом и "кровью". Альтернативы -- ad-hoc специализированны, переумудренные
>> вещи, пользоваться которыми никто не будет и не захочет.
> Альтернатива - не придумывать лишние things, чтобы не пришлось их делать. Неужели
> это так сложно?Уже такое было :-) Называлось OS/360 :-)
>> Основные преимущества их суть две вещи: 1) простота, 2) скорость
> Вы очень точно отметили их основные недостатки (сложность и тормознутость). Правда, непонятно,
> почему вы считаете их достоинствами.Простота и скорость разработки. :-)
Машинное время уже давно ничего не стоит :-)
> При правильной архитектуре (когда никаких regexpов нафиг не надо) - имеет, и
> еще какое. Просто потому, что не надо парсить текст (очень медленная
> и сложная работа).У вас опять получится OS/360.
> Вы очень точно отметили их основные недостатки (сложность и тормознутость). Правда, непонятно, почему вы считаете их достоинствами.Потому, что Вам нечего предъявить более простого и быстрого, (код на сях просьба не показывать :)) Есть вообще что-нибудь быстрее чем grep, sed и awk
> Если архитектор ПО феерических криворук - да. Например, запись из rsyslog в
> SQL. Кой мне толк от того, что оно в базу запихано, если там все равно текстовая каша?Криворук и недальновиден архитектор по имени Редмонд. Например, на Винде как не было достойной альтернативы syslog , так и нет. event viewer -- насмешка. Результат -- на лицо, очень мало Виндоадминов вообще знает о существовании логов, как класса. Зачем майкрософту "на старости-то лет" понадобилось приходить к выводам сформулированным задолго до них, над которыми они смеялись, как и Вы сейчас? Зачем нужно городить PS, headless server? Вы подумали бы перед тем как все и вся отвергать.
> При правильной архитектуре (когда никаких regexpов нафиг не надо) - имеет, и
> еще какое. Просто потому, что не надо парсить текст (очень медленная
> и сложная работа).Т.е. с текстом мы не работаем вообще? xml, html, LaTeX, logs, crontab выдуманы "врагами" Шиндошс? Как мы собираемся фильтровать текст, пардон, информацию? Вам наверное не приходилось работать с гигабайтными текстами где без Emacs с его возможностями, sed, awk и иногда перла не обойтись.
>> Много работы, места и т. д. К тому же нет универсальности.
> Да, это безусловные недостатки plain textа.Вы попробовали сами, перед тем как делать выводы.
>> К тому же, все эти утилиты легко "вставляемы" в другие утилиты и
>> программы, например, Emacs. Очень мило там работают. Вы что предлагаете, каждый
>> раз заново изобретать менее эффективный велосипед?
> Наоборот, это вы такое предлагаете :)Не понял, я вроде не придумываю свой сед, авк и греп. Что же мне вставлять куски текста или весь текст в БД а затем индексировать все это, при этом пить кофе и долго ждать пока все это закончится?
> Потому, что Вам нечего предъявить более простого и быстрого, (код на сях
> просьба не показывать :)) Есть вообще что-нибудь быстрее чем grep, sed
> и awkТрудно говорить с человеком, который никого не слышит, кроме себя.
Для работы с тестовыми файлами удобны инструменты для работы с текстовыми данными.
Причем, главным будет _удобство_, а не скорость. Вы зря сюда C приплели. Для C есть очень хорошие библиотеки для работы с текстовой информацией. Просто в простейших случаях это как на ракете за хлебом слетать.>> Если архитектор ПО феерических криворук - да. Например, запись из rsyslog в
>> SQL. Кой мне толк от того, что оно в базу запихано, если там все равно текстовая каша?Так если разработчик программы криворук, то и в тестовой каше не разберешься. Только зачем было делать тестовую кашу?
> Криворук и недальновиден архитектор по имени Редмонд. Например, на Винде как не
> было достойной альтернативы syslog , так и нет. event viewer --
> насмешка.1. Вы даже не представляете как устроен лог в винде.
2. event viewer - это просто штатный просмоторщик быстро глянуть в лог с минимальными возможностями (cat - тоже убог ;) ). Для регулярной работы с логом есть куча инструментов, в том числе , из всего зоопарка скриптовых языков.
3. У syslog даже на Linux есть куча очень достойных альтернатив. Просто syslog как Cobol: на него уже столько завязано, что проще мучаться с ним, чем искать себе приключений.> Результат -- на лицо, очень мало Виндоадминов вообще знает
> о существовании логов, как класса.Линадминов тоже хватает, которые не знают даже, где логи лежат. Только зачем говорить о недоучках? Может будем ориентироваться просто на админов.
> Т.е. с текстом мы не работаем вообще? xml, html, LaTeX, logs, crontab
> выдуманы "врагами" Шиндошс? Как мы собираемся фильтровать текст, пардон, информацию? Вам
> наверное не приходилось работать с гигабайтными текстами где без Emacs с
> его возможностями, sed, awk и иногда перла не обойтись.Для xml, html, LaTeX как и других языков разметки (и, например, парсинга исходных текстов языков программирования) надо пользоваться соответствующими парсерами. Появление этих языков разметки ( а ля SGML) было как раз следствием того, что текстовая каша надоела и нужно было генерировать удобные представления данных для разных потребителей (разные программы, разные люди).
Парсить гигабайты xml на sed или ручками в Emacs будет только сильно ограниченный в знаниях человек. XML через регэкспы в общем случае вообще не парсится.
>>> К тому же, все эти утилиты легко "вставляемы" в другие утилиты и
>>> программы, например, Emacs.Откройте для себя кроме Emacs огромный мир unix утилит и языков. Перестаньте делать руками то, что должен делать компьютер. Не надо уподобляться начинающим пользователям виндов, которые все тащат в MS Word т.к. там им привычно работать на макросах VB.
> Не понял, я вроде не придумываю свой сед, авк и греп. Что
> же мне вставлять куски текста или весь текст в БД а
> затем индексировать все это, при этом пить кофе и долго ждать
> пока все это закончится?Нет. Просто Вам говорят, что хватит петь аллилую текстовым логам с кашей в виде данных. Базу с данными надо хранить в соответствующей базе, а не прикрывать отличными инструментами недостатки в изначальном проектировании.
> Трудно говорить с человеком, который никого не слышит, кроме себя.Как же как, я весь во внимании.
> Для работы с тестовыми файлами удобны инструменты для работы с текстовыми данными.Истину говорите!
> Причем, главным будет _удобство_, а не скорость.Я абсолютно о том же, хотя и скорость не помешала бы. Открою для Вас секрет, что sed, awk, grep (perl, как крупнокалиберная артиллерия) очень даже быстродейственны.
>Вы зря сюда C приплели. > Для C есть очень хорошие библиотеки для работы с текстовой информацией.Ну и как "сбацать" однострочник на Си с такой библиотекой против авка, седа и грепа? Вы же правильно раньше подметили об удобстве. Кстати, выигрыш такого опуса на Сях, Джаве и пр. может быть даже и не замечен на каждодневных примерах. Проверено неоднократно.
> Просто в простейших случаях это как на ракете за хлебом слетать.Вот-вот, я тоже про ракету :).
> 1. Вы даже не представляете как устроен лог в винде.
> 2. event viewer - это просто штатный просмоторщик быстро глянуть в лог
> с минимальными возможностями (cat - тоже убог ;) ). Для регулярной
> работы с логом есть куча инструментов, в том числе ,
> из всего зоопарка скриптовых языков.Так назовите их имена и заодно скриптовые языки, и чем они лучше, эффективнее sed, awk и awk?
> 3. У syslog даже на Linux есть куча очень достойных альтернатив.Да, rsyslog, но идея та же, кстати все продумано, в том числе ротация логов, а вот в Виндовс я слышал есть проблемы с этим.
> Линадминов тоже хватает, которые не знают даже, где логи лежат. Только зачем
> говорить о недоучках? Может будем ориентироваться просто на админов.Зачем лукавить, или Вы вчера родились. Позвоните в МС-хелп, походите на виндо-форумы, в том числе официальные от МС. И найдите хотя бы один намек на логи. Где и когда у Вас спросят про логи?
К тому же если логи вообще ничего не значат, как этот "Windows has encountered a system error f3-f100-001". И что хотя бы одно МС-овксая или Тошибовская морда понятия не имеет, что эта шестнадцатеричная шифровка f3-f100-001 означает? Виндологика частенько остается энигмой. Почитайте, на интернетах довольно много по этому поводу материала накопилось.> Для xml, html, LaTeX как и других языков разметки (и, например, парсинга
> исходных текстов языков программирования) надо пользоваться соответствующими парсерами.Назовите имена пожалуйста и явки. Во-первых, я опять имел в виду для себя. Вот Вам надо дампнуть страничку с какого-нибудь url, парснуть содержимое, что-то посчитать или найти, составить репорт и всё это не интерактивно и в большом объеме. Ваши предложения по специализированному парсеру? Чем однострочный парсинг на универсальных авке, грепе, седе или перле хуже специальных парсингеров? Кстати, Вас можно крыть Вашей же картой, каждый раз возражая, что данный парсер не достаточно универсальный.
> Парсить гигабайты xml на sed или ручками в Emacs будет только сильно ограниченный в знаниях человек.
Да куда же нам до интеллектуалов от Венды :) Емаксом и каждая домохозяйка разберется, а вот Visual Basic - это самое то, рокет саенс!
>XML через регэкспы в общем случае вообще не парсится.То есть у Вас не получалось, вот и Ваш вывод. На мой взгляд, Ваши знания регексов в общем случае ограничены.
> Откройте для себя кроме Emacs огромный мир unix утилит и языков.
Минуточку, открыть я для себя многое открыл, может еще и до Вашего рождения. Я к тому, что В Емаксе через Shell-command-on-region (M-|) с ненулевыми аргументами ЛЮБАЯ шелловская утилита очень хорошо интегрируется в Емаксе. Слыхали про IDE? Что же теперь Вижуал Студио тоже запретить?
> Перестаньте делать руками то, что должен делать компьютер.А лучше купите у Майкрософта с еще какой-нибудь утилитой на .НЕТ на 10 ГБ, которые всё это профессионально будет делать? Слышу как Майкрософт стучит в Вашем сердце ;)
> Не надо уподобляться начинающим пользователям виндов, которые все тащат в MS Word т.к. там
> им привычно работать на макросах VB.Да Емакс -- это такой МС Ворд. Вы меня так рассмешили. А CAS (computer algebra systems) - это такой ексель. Хотя, если в Ворде (екселе) есть calc или dc, maxima, pari-gp может и я буду всё в Ворд тащить ("Унижусь до смиренной прозы", как сказал классик) :)
> Нет. Просто Вам говорят, что хватит петь аллилую текстовым логам с кашей
> в виде данных. Базу с данными надо хранить в соответствующей базе,
> а не прикрывать отличными инструментами недостатки в изначальном проектировании.О недостатках проектирования, это Вы конечно в точку. Только вот, не по адресу. Вот например, Юникс "спроектирован" изначально не устраивать хаоса в директориях. Так, конфиги, бинарники, юзеровские документы и системные файлы никогда не пихаются в одну директорию, в отличие от.
> Альтернатива — не придумывать лишние things, чтобы не пришлось их делать. Неужели
> это так сложно?действительно, это просто. поэтому всякие sqlite и прочие «лишние things» приживаются очень хреново.
Какой замечательный наброс.
Вы только что прослушали бред студента-гуманитария
Можно было проще написать: "Я хочу всё в SQL!"
"Удобство", "простота использования" и "доступность" - не всегда можно объединить. Проще парсить сохранённые логи на "упавшей" системе, а не трахаться с SQL запросами... Хотя кому как...
На упавшей системе все равно с чем трахаться. Битый текстовый лог не сильно удобен для работы как и база данных (не обязательно SQL, кстати, т.к. для лога главное скорость записи и надежность хранения уже записанных данных). А глазами парсить гигабайты вообще все равно что.
И таки при чем здесь awk и админы? Не они всю эту кашу заварили.
В целом Аноним дело говорит. Когда нужно написать нечто сложное, треующего обработки большого объема данных (например выяснить, можно ли поставить патч в Solaris, для этого нужно выяснить стоят ли его пакеты, нет ли Incompatible-патчей, не установлен ли он уже или закрыт другим патчом, если установлен, но в какой ревизии), приходится тратить силы на то, чтобы свернуть текстовое представление обратно в объекты.
С другой стороны, текстовый интерфейс проще для обработки, т.к. он имеет самый простой интерфейс - поток символов, чего не скажешь о не-текстовых интерфейсах. Вот вы например знаете нормальное штатное средство для работы с WMI? :)
Indeed, на примере dpkg. Хочу получить репорт, что и сколько у меня на Дебиане установлено из postgres, emacs и mutt и с "им подобным":
Например, имеем небольшой и простой однострочник:pkg-query -f '${Installed-size}\t${Package}\n' -W '*postfix*' '*postgre*' '*mutt-pa*' '*emacs*' | awk '/^[0-9]+/\
{s+=$1;print $0}
END{
printf "----------------------\nИтого Установлено: %.2f MB\n", s/1024}'#разбито на несколько строчек для удобочитаемости.
output:3373 emacs-goodies-el
13035 emacs23
541 emacs23-bin-common
58179 emacs23-common
4418 emacs24-common-non-dfsg
134 emacsen-common
532 maxima-emacs
896 mutt-patched
3448 postfix
64 postgresql
16431 postgresql-9.1
64 postgresql-client
4497 postgresql-client-9.1
154 postgresql-client-common
438 postgresql-common
64 postgresql-contrib
2028 postgresql-contrib-9.1
----------------------
Итого Установлено: 105.76 MBВопросы на засыпку:
1) как мы решаем подобные задачи на Виндовс (в адрес dpkg)
2) как мы будем решать подобные вопросы без авк?
тэг <pre> тут бы явно не помешал
> тэг <pre> тут бы явно не помешалоткрой тег [ code ], он крутой.
> 1) как мы решаем подобные задачи на Виндовс (в адрес dpkg)sccm, коллекции и прочие оргии. Основной смысл в том что админчики бегают по помойкам интернетов и ищут рецепты как это сделать. Обычно что-то подобное уже делали раньше. И они пробуют тыкать галки, как в красивых скринщотиках. Потом выясняется что часть данных можно достать только пауршелом. Начинаются прыжки и попытка на мегабаше накатать скрипт. А потом, при изменении версий, ВНЕЗАПНО может выяснится что структура хранения в бд поменялась и надо искать как править где-то в дебрях скуль запрос.
Всё для людей.
справедливости ради: sql-запрос таки проще поправить, чем более-менее сложную регулярку: регулярку проще переписать.
Кто спорит, если всё под своим контролем. Вот если загулить system-center-2012-sp1-orchestrator-scom-integration-pack-ip-activity-start-maintenance-mode-failed-to-get-monitor там очень интересные вещи. По моему дебажить подобное гогно ничуть не проще чем найти ошибку в своих скриптах.
> справедливости ради: sql-запрос таки проще поправить, чем более-менее сложную регулярку:
> регулярку проще переписать.приведите пример сложной регулярки.
> приведите пример сложной регулярки.здесь, конечно, стоило бы привести регулярку разбора… url, кажется. но это терминальный вариант, конечно. однако регулярка разбора более-менее сложных логов с выделением нужных частей тоже та ещё радость.
на всякий случай: термин «регулярное выражение» я применяю в «общепринятом» смысле, подразумевая под «регуляркой» и нерегулярные выражения с бэктрэкингом, например.
> Вопросы на засыпку:
> 1) как мы решаем подобные задачи на Виндовс (в адрес dpkg)Так же как и Вы: Используют api или соответствующую утилиту. Кстати, Ваш скрипт у меня (на всех Linuх) вообще не будет работать т.к.
1. pkg-query у меня вообще нет.
2. А догадайтесь почему еще..
3. А догадайтесь почему этому способу вообще нельзя верить на 100%
(Подсказка: у меня есть пакет с символами emacs, но он никакого отношения к Emacs не имеет)> 2) как мы будем решать подобные вопросы без авк?
Также как и Вы: передернем пример и воспользуемся, например, grep. (В виндах можно jscript, cmd, findstr)
> Так же как и Вы: Используют api или соответствующую утилиту.Ну так покажите, представите свой скрипт-однострочник, который находит все это на Виндовс.
>Кстати, Ваш скрипт у меня (на всех Linuх) вообще не будет работать т.к.На rpm-based такая возможность также имеется, что-то типа rpm -q -a --qf "blah-blah-blah".
> 3. А догадайтесь почему этому способу вообще нельзя верить на 100%
> (Подсказка: у меня есть пакет с символами emacs, но он никакого отношения
> к Emacs не имеет)А я не утверждал, что "dpkg has the cow's power" Вот мы дождемся Ваш скрипт, который будет всё это знать, уметь и не взамен требовать никакого кофе :)
>> 2) как мы будем решать подобные вопросы без авк?
> Также как и Вы: передернем пример и воспользуемся, например, grep. (В виндах
> можно jscript, cmd, findstr)так, в студию, пожалуйста а с "jscript, cmd, findstr" это Вы круто. Т.е., то же самое, только намного более убогое чем сед и авк? Покажите, и посмеемся над "неспециальностью" сед и авк вместе :)
>В целом Аноним дело говорит. Когда нужно написать нечто сложное, треующего обработки большого объема данных (например выяснить, можно ли поставить патч в Solaris, для этого нужно выяснить стоят ли его пакеты, нет ли Incompatible-патчей, не установлен ли он уже или закрыт другим патчом, если установлен, но в какой ревизии).То, что Solaris до 11 версии не мог обзавестись пакетным менеджером с разрешением зависимостей - это проблема разработчиков этой оси. Поэтому Вы и решаете "несуществующие" проблемы и, судя по написанному, не очень этим довольны.
>>В целом Аноним дело говорит. Когда нужно написать нечто сложное, треующего обработки большого объема данных (например выяснить, можно ли поставить патч в Solaris, для этого нужно выяснить стоят ли его пакеты, нет ли Incompatible-патчей, не установлен ли он уже или закрыт другим патчом, если установлен, но в какой ревизии).
> То, что Solaris до 11 версии не мог обзавестись пакетным менеджером с
> разрешением зависимостей - это проблема разработчиков этой оси. Поэтому Вы и
> решаете "несуществующие" проблемы и, судя по написанному, не очень этим довольны.Э-э-э, мужик. Ты Солярис-то не в телевизоре видал, не?
> В целом Аноним дело говорит. Когда нужно написать нечто сложное, треующего обработки
> большого объема данных (например выяснить, можно ли поставить патч в Solaris,
> для этого нужно выяснить стоят ли его пакеты, нет ли Incompatible-патчей,
> не установлен ли он уже или закрыт другим патчом,Открой для себя PCA.
http://www.par.univie.ac.at/solaris/pca/
Это сто лет как сделано. И лет 20 используется.
> Сложившийся в юниксах (да и не только) алгоритм "одна программа генерирует человекочитаемые данныеЕсли человек желает управлять этими данными - других вариантов нет.
> Гораздо более правильным и логичным было бы хранить подобные данные в машиночитаемом видеТак вот почему в линуксах так много иксэмэлей...
Для многих (большинства?) задач обработка текстового потока -- проще, легче и даже производительнее. Другое дело, если возможностей обычного текста не хватает -- стоит воспользоваться бинарным представлением, а не городить небоскрёбы тормозящий костылей.
Но таких случаев, на самом деле, мало.
> Так вот почему в линуксах так много иксэмэлей…к сожалению, всего лишь потому, что потонофилы набижали. хотите, мы их всех отдадим вам в винду? нам не жалко, честно!
предлагаете одмину читать вывод в протобаф?
Зря минусуете, Аноним дело говорит.
Вон, в systemd логи сделали бинарными по схожим причинам.
Анониму подошла бы база данных с хранением в текстовых файлах :-D
Такие анонимы и в прошлые заходы про системд посасывали. Но мы ведь сейчас не об этом?
Старая несмешная копипаста
Впервые встречаю тут вменяемую критику подобных костылей :)
+1
извините, а как давно вы пользуетесь AWK-ом или другими UNIX-фильтрами? мне кажется, что такое безапеляционное заявление требует, как минимум, многих лет работы с подобными инструментами.
Эк виндовозов корячит от любого упоминания о новом релизе любой стандартной программы, как чертей от святой воды прямо.
> Эк виндовозов корячит от любого упоминания о новом релизе любой стандартной программы,
> как чертей от святой воды прямо.Я бы на их месте безудержно веселился. Когда у твоих врагов что-то работает через задницы, да еще и большинство их этим гордится - чем не повод для веселья?
Впечатление, что у вас мозги через задницу работают. И вы этим гордитесь.
Другие же этим [утилитами] пользуются и пользуются весьма успешно.
То, что другие пользуются, еще не говорит об их интеллекте. Мыла с шампунем тоже когда-то не было, и большинство считало, что пользоваться таким ненормально. Так что это не довод.
> Когда у твоих врагов что-то
> работает через задницы, да еще и большинство их этим гордится —
> чем не повод для веселья?да мы уже ржать над бедными виндофилами устали. ну сколько можно же? то у них vista продаётся хреново и тормозит, то от кирпичей народ не в восторге, то wp оказывается никому не нужен. попробовали было плеер сделать — и тут облажались. планшет сделали — снова фигня какая-то получается вместо ожидаемой радости. только и остаётся бедным зарабатывать тупым рекетом на чужой зелёной платформе.
Грешно смеятся над убогими (вантузятниками)
Мы им сочуствуем и ироничнор вышучиваем, а у них от этого боль ниже спины
Как же уже скучно читать комментарии от таких вот школьников(студентов). Если точка зрения отличается от официальной, то сразу клеймят виндузятником, фашистом и перерастом.
Чорт... Только 4.0.2 закончил собирать.
> гораздо более правильным и логичным
> ты еще молодой
> если бы разработчики сначала думали, а потом кодили
> неужели это так сложно?
> надо бить по рукам``Картину раз высматривал сапожник
И в обуви ошибку указал;
Взяв тотчас кисть, исправился художник.
Вот, подбочась, сапожник продолжал:
"Мне кажется, лицо немного криво...
А эта грудь не слишком ли нага?"....
Тут Апеллес прервал нетерпеливо;
"Суди, дружок, не свыше сапога!"``
> для выполнения рутинных работ, связанных с парсингом различного рода текстовых файлов и генерации несложной результирующей статистики"не распарсил" (с) это из вывода AWK?
> "не распарсил" (с) это из вывода AWK?Петросянишь?
>> «не распарсил» © это из вывода AWK?
> Петросянишь?он не распарсил.
AWK - The best!