Ykidia
Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата:| Из-за чего sed "противный"? |
Из-за богомерзких (если вспомнить, что в Windows есть службы и иконы  ) динамических библиотек, мозолящих глаз названием (либлибли...) и чуждых ОС Windows содержимым. Не волнуйтесь, я не против *nix-ов. Но из-за кассового ПО и ГИСов мне пришлось иметь дело с opensource довольно плотно как минимум год, и я уже понял, что это за бардак. Ощутимый порядок в этот бардак вносит CMake, но вот некоторые - в том числе и sed - напрочь игнорируют его, вынуждая для сборки использовать (устанавливая их в систему!) всяческие сборники динамических библиотек, которые я охарактеризовал выше. "Всему должно быть свое место, дети, и это место - школа" (c). Я это к тому, что когда sed потребовал от меня дополнительные dll-ки, я полез за исходниками, чтобы собрать его заново и таким образом отучить от вредных привычек, как я уже проделывал с некоторыми *nix-овыми утилитками. И что я там увидел? Кури makefile и configure, если хочешь собрать для своей среды ее же средствами и эта среда - не Linux, а когда тебе удастся все собрать, знай, что оно везде будет таскать за собой объемную "обвязку" (либо внутри себя, либо в виде подгружаемых файлов), нужную только ему одному!... В общем, мне претит подобный подход. Но это - мое личное мнение. Кому-то нравится - их дело.
Надеюсь, я ответил на Ваш вопрос, и Вы меня поняли, хотя бы отдаленно.
Спасибо за правильный curl - заработало сразу. Может, я со своим что-то перемудрил или недосмотрел... Потом как-нибудь разберусь. А сейчас, по традиции, измененный код: Подробнее... Переводится не все, но, по крайней мере, UTF-8 не искажается. Попробую добавить перевод Яндекса, правда, там надо указывать язык, а Google недопереводит не только какой-то один, а разные, например арабский, японский, даже русский в транслите. |
Всего записей: 242 | Зарегистр. 03-03-2005 | Отправлено: 16:18 07-06-2012 | Исправлено: Ykidia, 16:19 07-06-2012 |
|
Правда, заработало не все, точнее, ничего не заработало - может быть у меня кривой curl/sed ? В любом случае даже отсеивать по <name> и <state> не хотел - надо было сначала создавать файл, прежде чем делать в него ">>". Ну это мелочи - переделал свой код под findstr, скорость возросла в десятки раз ))). Вот уж не ожидал от echo, что оно такое нежное - а findstr все пофиг. Единственное НО с findstr - с большим файлом перед началом цикла поиска по файлу долго "напрягается", прямо как с "type" - видимо интерпретатор сначала кладет результат findstr (и type и прочих) в память, а уж потом оттуда начинает выдавать в цикл. 
