Люди должны сами делать выводы, какой вариант лучше, и на этом учиться.
дело в том, что тот скрипт некрасивый. Я вообще удивляюсь, каким образом он вообще работает! ИМХО не надо учится на плохом коде...
Люди должны сами делать выводы, какой вариант лучше, и на этом учиться.
дело в том, что тот скрипт некрасивый. Я вообще удивляюсь, каким образом он вообще работает! ИМХО не надо учится на плохом коде...
[quote=zhevak]Люди должны сами делать выводы, какой вариант лучше, и на этом учиться.
дело в том, что тот скрипт некрасивый. Я вообще удивляюсь, каким образом он вообще работает! ИМХО не надо учится на плохом коде...[/quote]
Э-эй! Алё? Дмитрий, вернись на грешную землю... Улови, что мы говорим об одном и том же.
На плохом коде тоже можно учиться: типа смотрите, как делать не следует. И сравните с тем, как это делать правильно.
На плохом коде тоже можно учиться: типа смотрите, как делать не следует.
этого никто кроме вас и меня не видит (ну и тех кто разбирается). Если уж оставлять такой код, то следует снабдить его кучей комментариев, ПОЧЕМУ так делать нельзя.
GET "http://www.google.com/dictionary?langpair=en|ru&q=$1&hl=ru&aq=f" | \ # нельзя использовать GET
# ибо эта команда есть далеко не у всех. Например в слаке её нет, хотя там куча всего. Кроме того, даже если эта команда и есть,
# на самом деле, она может быть реализована алиасом. А алиасы не работают в скриптах.
# кроме того, даже если это и не алиас, то возможно, что в PATH нет такого на момент запуска скрипта.
grep dct-tt | \ # нельзя использовать grep в сложных случаях. Причина проста:
# нам необходимо выполнить сложные действия, и grep нам мало. Потому нам придётся ещё что-то вводить.
# зачем плодить сущности? проще всё сделать одной sed, если уж... Кроме того, нельзя вводить параметры без кавычек,
# ибо шелл раскрывает параметры, и в команду попадёт что-то совсем другое. Мы [b]обязаны[/b] использовать кавычки
# ибо в противном случае получаем быдлокод, который [b]работает не всегда[/b] - если шелл не смогла раскрыть шаблон, она его так и передаёт, и в тестах всё работает правильно.
# на практике шелл сможет, и случится НЁХ. В большинстве случаев - ошибка, а часто - дыра в безопасности.
sed /'class=\"dct-e/d' | \ # нельзя дробить команды - две команды выполняются вдвое дольше одной, всегда ваш К.О.
# нельзя экранировать символы без необходимости - в этой версии sed \" значит "кавычка", в другой версии она может означать всё что угодно.
sed '/<a\ href/d' | \ # пробел тоже экранировать нельзя в данном случае
sed 's/<span class="dct-tt">//g' | \ # это мы уже нашли раньше - тогда это и нужно было удалить командой s///
# это избавило-бы нас от необходимости вторично компилировать это сложное выражение (да и писать меньше).
sed 's/<\/span>//' | \ # заборчики \/\\/\//\/ смотрятся красиво, но набирать их долго. И они нечитаемые в т.ч. и быдлокодером.
sed '/<span /d' | \ # тут мы удолили все строки в которых есть <span, завтра гугл чуть изменит формат, и быдлокод сломается - он удалит и нужную информацию.
head -n 5 # аффтор не в курсе, но любой осиливший документацию знает, что sed сама может прекратить вывод после 5й строки.как-то так... Короче - в каждой строке ошибка, а в некоторых их больше одной :(