Окончание перевода 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 многим было бы интересно узнать.

Знание истории происхождения вещей и их названий, будь то простой карандаш, автомобиль или команда операционной системы, делает их повседневное использование намного интереснее. В этой заметке я постарался разобраться в причинах странного, казалось бы, наименования некоторых программ, используемых в операционной системе Unix и её родственниках: *BSD, Solaris, HP-UX, Linux и т.д.

Перепечатка моей статьи, написанной, в свою очередь, по мотивам страницы What does {some strange unix command name} stand for?

В Debian в bash был добавлен патч, благодаря которому пользователь может написать свою функцию, выполняемую в случае, если введённая пользователем команда отсутствует. В Ubuntu эту фичу использует подсказка command-not-found, заметно тормозящая работу, в то время как можно найти более интересные и полезные возможности применения этого механизма, оставив поиск пакета специализированным программам. Поделюсь своим опытом.

С давних времен многих смущает разнообразие вариантов обеспечения безопасности при выполнении операций с максимальными привилегиями. Например, в официальной документации Ubuntu в качестве команды редактирования рекомендуется использовать что-то вроде sudo nano, а в многочисленных любительских мануалах (в стиле «5 фокусов в командной строке, которые удивят вашу бабушку») для получения root'ового шелла предлагается писать sudo su -. Попробую объяснить, почему такое положение вещей кажется мне неправильным.