Учим bash-скрипты, пишем Sokoban

[sl4mmer]

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

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

[ninacarrot]

Именно, но часть моих знакомых отказывается иметь со скриптами дело по непонятным причинам.

*Вспомнил, как в 8 лет писал свою «Windows» на батнегах и ndos, когда из-за EGA-монитора не завелась Windows 3.11, и стер скупую мужскую слезу*

[VolCh]

Я вот не отказываюсь, но откладываю на «в следующий раз уж точно» уже несколько лет. То есть возникает какая-то задача для которой идеологически верно было бы, наверное, использовать язык шелла, но вот глядя на код вроде вашего, да ещё с пояснениями о важности пробелов и т. п. создаётся впечатление, что решать задачу в шелле придётся неоправданно долго из-за необходимости на практике столкнуться с кучей нюансов типа тех же пробелов. Да и вообще код как-то выглядит перегруженным «пунктуацией», назначение которой неочевидно по опыту разработки на других языках.

[tripiz]

Везет же автору с количеством свободного времени и сил :)

[ninacarrot]

Спасибо за комплимент! Вот только сил и времени на все не хватает: есть идеи еще минимум на четыре статьи, да вот только писать их некогда (пока что).

[4twilight]

Я джва года хочу такую игру…

P.S. а если серьезно, то хороший материал с точки зрения описания структуры и синтаксиса bash. Добавил в избранное.

[ramilexe]

надо в блог «ненормальное программирование»

[ninacarrot]

Разве? Если бы на brainfuck или на чистых bat…

[yktoo]

На Whitespace лучше.

[equand]

bash? давайте на sh :D

[sl4mmer]

wget winetricks.org/winetricks

sh так sh — изучайте )

[kost_bebix]

Спасибо огромное. Баш учить полностью лень, а вот статей «баш для тех, кто уже умеет программировать» не хватает. Впринципе, это и есть причина, почему толком баш не знаю.

[j1nn]

хороший способ выучить баш, не изучая его полностью — это написать на нем что-нибудь очень нужное:)

[kost_bebix]

На очень нужное знаний хватает, ага.

[printf]

Извиняюсь за очевидный вопрос, но в чем принципиальная разница?

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

Мне кажется, в данном случае неважно же.

[nagato]

[ ] работает только с числами
разница будет, если, например, B=""

[nagato]

Ой, про то, что только с числами, наврал.

[Livid]

Действительно наврали. А вот насчет пустой строки правда. Чтобы избежать сюрпризов при использовании [ приходится писать что-то в духе
if [ «x$B» -eq «xstringhere» ];…

[nagato]

Если сравнивать строки, то нужен =, -eq для чисел.

[Livid]

Да, тут я уже наврал :)

[mafet]

а я всю жизнь на пустоту сравнивал так:
if [ "$x" = "" ];
Это не правильно? не пойму, в чём тут подводный камень? вроде всего нормально работало.

[Livid]

В общем-то правильно. Но есть оговорки. Например, примечание 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» не учитывается).
/Цитирую

Если говорить о кросс-шелловом скриптинге, то становится еще интереснее.

[mafet]

хм. спасибо! у меня кстати был какой-то косяк с пустой строкой, но не помню на какой ОС это было и при каких обстоятельствах.

[printf]

Так в .bat-файлах, кстати, делали. Синтаксис не помню уже, но смысл такой же, с добавлением символа.

[ninacarrot]

[ — это команда, встроенная в bash, а [[ — это еще одно название test, при этом [[ — более универсальный вариант, не так ли? Соответственно, следует использовать [ там, где обязательна оптимизация по скорости и зависимостям. Я использовал [[ лишь для того, чтобы не путаться. А вообще, действительно не имеет значения.

[Livid]

Вообще-то нет. [[ это не обертка к test, это как раз башизм, причем гораздо менее портабельный. У него есть несколько преимуществ перед [ (который как раз test, в баше немного расширенный). Подробности, например, здесь: stackoverflow.com/questions/669452/is-preferable-over-in-bash-scripts

[ninacarrot]

Спасибо за информацию!

[ftp27]

Помнится мне, что товарищ Sicness пару месяцев назад писал что то подобное :)

[ninacarrot]

Однако, в списке его топиков ничего такого нет.

[ftp27]

Однако да ) Видно топик про это он решил не писать

[Anexroid]

Спасибо. Давно думаю о том, чтобы bash поучить, да все руки не доходили да примеров достойных не было.

[ninacarrot]

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

[Antigluk]

Не хватает какого-то «Game Over»-a) А так неплохо, да)

[ninacarrot]

Хотите — добавьте по вкусу в главный цикл после каждого хода.

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

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

[Wizard999]

А какие средства отладки есть?

[Antigluk]

echo?

[Wizard999]

Из wiki:

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

Вот такого хочется… А echo — это типа логи… Без отладчика очень сложно сделать что то большое и сложное. Особенно, тут же нет даже компилятора…

[Anexroid]

Ну не знаю. Нам наш препод по Си говорит, и я с ним согласен, с учетом большого опыта программирования и отладки PHP: Юзайте printf (echo), им можно отладить всё. Отладчики везде разные, больше времени потратите на знакомство с его функциями, а юзая printf можно отлаживать что угодно и где угодно.

[j1nn]

надо же, я так всегда думаю, а меня постоянно пытаются переубедить. и ладно бы на огромных проектах — нет, совсем нет.

[Antigluk]

Отладчик не нужен, согласен с Anexroid

[Klaus]

хочется дополнить, что это справедливо в основном для скриптовых языков

[Anexroid]

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

[Klaus]

когда проект большой каждый раз ждать компиляции меня лично раздражало.

[ninacarrot]

Метод раз:1, 2
Метод два

[darkshine]

если в скрипте прописать «set -x», то при его запуске в stderr будут выводиться команды именно в том виде, в котором они выполняются. Таким образом, можно отслеживать какая из веток в операторе «if / then / else / fi» выполняется и какие значения переменных используются в выражениях.

вместо команды «set -x» можно просто вначале скрипта первой строкой поставить "!/bin/bash -x".

[guglez]

либо можно просто выполнить bash -x ./script.sh

[yktoo]

> r=$(( $x + $y )) #и снова обратите внимание на скобки и пробелы

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

r=$((x+y))

[Livid]

О! Спасибо, от моего внимания эта возможность как-то ускользнула.

[romy4]

в bash/sh конструкции if, for и т.д. — это команды, а не конструкции языка, потому после них обязательно нужен пробел. мне кажется, об этом необходимо упомянуть, чтобы понимать зачем так. вообще sh/bash чуть более, чем полностью состоит из команд.

[romy4]

только часть команд встроенные, а часть внешние как test и [ которые могут использоваться как и встроенные, так и отдельные программы /usr/bin/[

[Livid]

На самом деле в баше не все так просто. Builtin-версии имеют кучку расширений (по сравнению с POSIX), которые могут быть и не доступны в системной версии. Поэтому /usr/bin/* почти никогда не используются в баше-специфичных скриптах. Для примера сравните man read и man bash (/^ *read \[)

[Beholder]

B — очень хорошее название для переменной для хранения символа с клавиатуры, да

[ninacarrot]

B is for keyBoard.

[KY05]

Спасибо!

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

п.с. «заодно»

[ninacarrot]

Если интересно, могу сделать специально для вас.

[KY05]

Специально для меня не надо, а для жителей Хабра, думаю, будет интересным.

[NoWeekOff]

Я имеет смысл для чего-то сложнее 5 строк использовать bash?

Более менее длинные скрипты пишу на ruby или python. Получается покрасивше и отлаживать проще. Проблем с наличием интерпретаторов в системе не испытывал.

[murr]

Согласен, Ruby + Thor помогают просто решить множество проблем по автоматизации.

[ninacarrot]

Вы просто не пробовали писать для embedded-линуксов. Там python и ruby часто некуда впихнуть, а sh какой-никакой (чаще никакойbusybox) имеется.

[NoWeekOff]

Это конечно да, но имхо сильно частный случай

[ninacarrot]

Разумеется, мощные скриптовые языки очень удобные. Разумеется, embedded — это частный случай. Но каждый опирается на свои возможности, так ведь?

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

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

[NoWeekOff]

> каждый опирается на свои возможности, так ведь?

Крайне верное замечание. Я как раз пришел к администрированию из программирования. Руки сами тянутся к любимому и знакомому.

[Flack]

case-esac это жесть конечно.

[ninacarrot]

Мне кажется, это более-менее логичное решение для bash. По сравнению с другими, гораздо менее логичными.