Pull to refresh

Comments 67

Воот во что можно погамать на плеере из плэйбоя!!!

А если серьезно + автору. Игра для примера — интересно, но кроме шуток, за счет скриптов можно очень здорово повысить эффективность работы. Пользователи *боксов подтвердят.
Именно, но часть моих знакомых отказывается иметь со скриптами дело по непонятным причинам.

*Вспомнил, как в 8 лет писал свою «Windows» на батнегах и ndos, когда из-за EGA-монитора не завелась Windows 3.11, и стер скупую мужскую слезу*
Я вот не отказываюсь, но откладываю на «в следующий раз уж точно» уже несколько лет. То есть возникает какая-то задача для которой идеологически верно было бы, наверное, использовать язык шелла, но вот глядя на код вроде вашего, да ещё с пояснениями о важности пробелов и т. п. создаётся впечатление, что решать задачу в шелле придётся неоправданно долго из-за необходимости на практике столкнуться с кучей нюансов типа тех же пробелов. Да и вообще код как-то выглядит перегруженным «пунктуацией», назначение которой неочевидно по опыту разработки на других языках.
Везет же автору с количеством свободного времени и сил :)
Спасибо за комплимент! Вот только сил и времени на все не хватает: есть идеи еще минимум на четыре статьи, да вот только писать их некогда (пока что).
Я джва года хочу такую игру…

P.S. а если серьезно, то хороший материал с точки зрения описания структуры и синтаксиса bash. Добавил в избранное.
надо в блог «ненормальное программирование»
Разве? Если бы на brainfuck или на чистых bat…
UFO just landed and posted this here
Спасибо огромное. Баш учить полностью лень, а вот статей «баш для тех, кто уже умеет программировать» не хватает. Впринципе, это и есть причина, почему толком баш не знаю.
хороший способ выучить баш, не изучая его полностью — это написать на нем что-нибудь очень нужное:)
На очень нужное знаний хватает, ага.
Извиняюсь за очевидный вопрос, но в чем принципиальная разница?

if [ "$B" -eq 3 ]
if [[ "$B" -eq 3 ]]

Мне кажется, в данном случае неважно же.
[ ] работает только с числами
разница будет, если, например, B=""
Ой, про то, что только с числами, наврал.
Действительно наврали. А вот насчет пустой строки правда. Чтобы избежать сюрпризов при использовании [ приходится писать что-то в духе
if [ «x$B» -eq «xstringhere» ];…
Если сравнивать строки, то нужен =, -eq для чисел.
Да, тут я уже наврал :)
а я всю жизнь на пустоту сравнивал так:
if [ "$x" = "" ];
Это не правильно? не пойму, в чём тут подводный камень? вроде всего нормально работало.
В общем-то правильно. Но есть оговорки. Например, примечание 18 в ABS 7.3 по ссылке автора: rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#FTN.AEN2722

Цитирую
Как указывает S.C., даже заключение строки в кавычки, при построении сложных условий проверки, может оказаться недостаточным. [ -n "$string" -o "$a" = "$b" ] в некоторых версиях Bash такая проверка может вызвать сообщение об ошибке, если строка $string пустая. Безопаснее, в смысле отказоустойчивости, было бы добавить какой-либо символ к, возможно пустой, строке: [ «x$string» != x -o «x$a» = «x$b» ] (символ «x» не учитывается).
/Цитирую

Если говорить о кросс-шелловом скриптинге, то становится еще интереснее.
хм. спасибо! у меня кстати был какой-то косяк с пустой строкой, но не помню на какой ОС это было и при каких обстоятельствах.
Так в .bat-файлах, кстати, делали. Синтаксис не помню уже, но смысл такой же, с добавлением символа.
[ — это команда, встроенная в bash, а [[ — это еще одно название test, при этом [[ — более универсальный вариант, не так ли? Соответственно, следует использовать [ там, где обязательна оптимизация по скорости и зависимостям. Я использовал [[ лишь для того, чтобы не путаться. А вообще, действительно не имеет значения.
Вообще-то нет. [[ это не обертка к test, это как раз башизм, причем гораздо менее портабельный. У него есть несколько преимуществ перед [ (который как раз test, в баше немного расширенный). Подробности, например, здесь: stackoverflow.com/questions/669452/is-preferable-over-in-bash-scripts
UFO just landed and posted this here
Помнится мне, что товарищ Sicness пару месяцев назад писал что то подобное :)
Однако, в списке его топиков ничего такого нет.
Однако да ) Видно топик про это он решил не писать
Спасибо. Давно думаю о том, чтобы bash поучить, да все руки не доходили да примеров достойных не было.
UFO just landed and posted this here
Меня с детства по рукам били, когда я комментарии не писал. Шутка. Хотя…
Не хватает какого-то «Game Over»-a) А так неплохо, да)
Хотите — добавьте по вкусу в главный цикл после каждого хода.

places=0
allmap=$(( $LIMIT * $LIMIT ))
for (( r=1 ; r<allmap ; r++ )) do
if [[ "${map[${r}]}" = "o" ]] 
then
places=$(( $qt + 1))
fi
done
if [[ "$places" -eq 0 ]] 
then
echo "You win!"
B="q"
fi


Можете даже несколько уровней добавить.
Из wiki:

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

Вот такого хочется… А echo — это типа логи… Без отладчика очень сложно сделать что то большое и сложное. Особенно, тут же нет даже компилятора…
Ну не знаю. Нам наш препод по Си говорит, и я с ним согласен, с учетом большого опыта программирования и отладки PHP: Юзайте printf (echo), им можно отладить всё. Отладчики везде разные, больше времени потратите на знакомство с его функциями, а юзая printf можно отлаживать что угодно и где угодно.
надо же, я так всегда думаю, а меня постоянно пытаются переубедить. и ладно бы на огромных проектах — нет, совсем нет.
Отладчик не нужен, согласен с Anexroid
хочется дополнить, что это справедливо в основном для скриптовых языков
В основно, конечно, да. Просто потому, что для скриптов нет нормальных отладчиков. Но вообще, можно обойтись и без него и в компилируемых языках.
когда проект большой каждый раз ждать компиляции меня лично раздражало.
если в скрипте прописать «set -x», то при его запуске в stderr будут выводиться команды именно в том виде, в котором они выполняются. Таким образом, можно отслеживать какая из веток в операторе «if / then / else / fi» выполняется и какие значения переменных используются в выражениях.

вместо команды «set -x» можно просто вначале скрипта первой строкой поставить "!/bin/bash -x".
либо можно просто выполнить bash -x ./script.sh
> r=$(( $x + $y )) #и снова обратите внимание на скобки и пробелы

Внутри (( )) знак доллара вообще можно опустить и написать просто:

r=$((x+y))
О! Спасибо, от моего внимания эта возможность как-то ускользнула.
в bash/sh конструкции if, for и т.д. — это команды, а не конструкции языка, потому после них обязательно нужен пробел. мне кажется, об этом необходимо упомянуть, чтобы понимать зачем так. вообще sh/bash чуть более, чем полностью состоит из команд.
только часть команд встроенные, а часть внешние как test и [ которые могут использоваться как и встроенные, так и отдельные программы /usr/bin/[
На самом деле в баше не все так просто. Builtin-версии имеют кучку расширений (по сравнению с POSIX), которые могут быть и не доступны в системной версии. Поэтому /usr/bin/* почти никогда не используются в баше-специфичных скриптах. Для примера сравните man read и man bash (/^ *read \[)
B — очень хорошее название для переменной для хранения символа с клавиатуры, да
Спасибо!

А как будет выглядеть Pac-Man?

п.с. «заодно»
Если интересно, могу сделать специально для вас.
Специально для меня не надо, а для жителей Хабра, думаю, будет интересным.
Я имеет смысл для чего-то сложнее 5 строк использовать bash?

Более менее длинные скрипты пишу на ruby или python. Получается покрасивше и отлаживать проще. Проблем с наличием интерпретаторов в системе не испытывал.
Согласен, Ruby + Thor помогают просто решить множество проблем по автоматизации.
Вы просто не пробовали писать для embedded-линуксов. Там python и ruby часто некуда впихнуть, а sh какой-никакой (чаще никакойbusybox) имеется.
Это конечно да, но имхо сильно частный случай
Разумеется, мощные скриптовые языки очень удобные. Разумеется, embedded — это частный случай. Но каждый опирается на свои возможности, так ведь?

Например: у меня есть несколько зверьков с embedded — пару роутеров, Palm и WinMo-девайс (правда, на нем linux живет в экспериментальных целях), и ни на одном нет python или ruby.

Кроме того, я активно использую KolibriOS, и полноценного порта python для нее пока что нет (впрочем, sh тоже нет). Почему не портирую сам? Python я не знаю, для меня must-have это lua, которую я уже портировал.
> каждый опирается на свои возможности, так ведь?

Крайне верное замечание. Я как раз пришел к администрированию из программирования. Руки сами тянутся к любимому и знакомому.
Мне кажется, это более-менее логичное решение для bash. По сравнению с другими, гораздо менее логичными.
Sign up to leave a comment.

Articles

Change theme settings