Оболочки *

Доброе время суток. Данный топик является изложением личного опыта владения телефонами на базе Android. Монолог будет о плюсах и минусах сторонних прошивок и o том, что интересует, не совсем обычного пользователя современных гаджетов. Данный топик, надеюсь, будет интересен пользователям Android устройств раздумывающиж над кастомизацией. Опытным пользователям и тем более разработчикам, эта заметка вряд ли расскажет что-то новое.

У меня нет опыта владения телефонами на Windows Phone или Apple iOS и данный холивар в этом топике не затрагивается.

Совсем недавно я открыл для себя оболочку Ridiculous fish, которая принципиально отличается от bash и zsh с которыми я работал ранее. На моем MacBook Pro под Mac OS X оболочка установилась без каких либо проблем и замечательно работала. Освоившись в новой оболочке, я решил что пришло время установить и настроить ее так же и на серверах, на которых установлен 64-разрядный Debian Squeeze. Тут то я и столкнулся с тем, что 32-разрядный deb пакет, который лежит у них на сайте, на 64-разрядный Debian не устанавливается. И я решил собрать любимую оболочку из исходников. Этот процес и будет описан в статье.

Предлагаю программу для администраторов — Rinstall (скачать можно здесь). Она решает следующие задачи:

1. Удалённое администрирование
2. Удалённое выполнение команд
3. Удалённая установка приложений

    Занялся я как-то оптимизацией скорости работы своего скрипта. Алгоритм был уже вовсю отполирован, распараллелен и выполнялся уже более чем за сносное время. Лишь изредка, облизывая части кода, шебурша места, использующие внешние команды и приводя в благоухающую гармонию встроенными командами оболочки, обращал внимание на застоявшуюся роль труженика — потокового редактора sed, всё так же старательно обрабатывавшего регулярные выражения в моём расцветающем скрипте.
Существует множество мест, где люди грызут друг другу глотки и отстаивают честь своего любимого редактора в грозной войне sed vs awk vs grep vs …
Тем не менее, большинство знает, что замена вызовов внешних команд на внутренние зачастую значительно ускоряет критические места скрипта, заставляет улыбаться автора, тратя меньше его времени на ожидание за чашкой кофе «пока закончится обработка». Это, в некотором смысле, некоторая неадекватность, если он знает язык Си и может значительно ускорить программу переписыванием кода на Сях; но не следует сразу записывать его в сумасшедшие — некоторые скрипты довольно объемны для переноса кода и используют различные команды, заставляя код пухнуть от нахальных вставок системных вызовов exec().
    Итак, как бы то ни было, разработчики bash третьей версии наделили нас возможностью пользоваться встроенными регулярными выражениями внутри команды [[ при помощи =~.
Большинство результатов на гугление про такую способность bash выносят один и тот же вердикт — «пользоваться регулярными выражениями внутри bash — моветон».
В данной статье я попытаюсь вынести вердикт, насколько всё плохо (а оно действительно как-то нехорошо).

Окончание перевода Bash Pitfalls. Предыдущие части доступны в блоге «Оболочки» (часть 1, часть 2) и в моём блоге.

22. echo "Hello World!"

Проблема в том, что в интерактивной оболочке Bash эта команда вызовет ошибку:

bash: !": event not found

Это происходит потому, что при установках по умолчанию Bash выполняет подстановку истории команд в стиле csh с использованием восклицательного знака. В скриптах такой проблемы нет, только в интерактивной оболочке.

Очевидное решение здесь не работает:

$ echo "hi\!"
hi\!

Продолжаю знакомить сообщество с переводом Bash Pitfalls.
Часть первая.
Первоначальная публикация перевода.

11. cat file | sed s/foo/bar/ > file

Нельзя читать из файла и писать в него в одном и том же конвейере. В зависимости от того, как построен конвейер, файл может обнулиться (или оказаться усечённым до размера, равному объёму буфера, выделяемого операционной системой для конвейера), или неограниченно увеличиваться до тех пор, пока он не займёт всё доступное пространство на диске, или не достигнет ограничения на размер файла, заданного операционной системой или квотой, и т.д.

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

Большинство имеющихся руководств посвящено тому, как надо писать. Я же расскажу о том, как писать НЕ надо :-)

Данный текст является вольным переводом вики-страницы «Bash pitfalls» по состоянию на 13 декабря 2008 года. В силу викиобразности исходника, этот перевод может отличаться от оригинала. Поскольку объем текста слишком велик для публикации целиком, он будет публиковаться частями.

На Хабре частенько появляются посты, которым явно неуютно в рамках блогов, куда их поместили авторы. Большинство постов на темы, связанные с bash, живёт в «Linux для всех», хотя bash вполне может работать и в FreeBSD, и в Mac OS X, и даже под Windows в окружении cygwin. В свою очередь, множество Linux-пользователей работает в традиционной для *BSD оболочке csh. То же самое можно сказать и про zsh, и fish, и про другие популярные и не очень шеллы.

Поэтому, чтобы избежать путаницы между операционными системами и оболочками и при этом никого не обидеть, создан тематический блог о командных оболочках: habr.ru/blogs/shells. Предлагаю помещать сюда статьи, касающиеся использования командных интерпретаторов как в роли языков программирования, так и в роли пользовательского окружения.

Приветствуются статьи об оболочках, использующихся в Unix-like системах, но, думаю, и про возможности cmd.exe многим было бы интересно узнать.