Администраторам Linux писать скрипты на Bash приходится регулярно. Ниже я привожу советы, как можно ускорить эту работу, а также повысить надежность скриптов.

Совет 1

Не пишите скриптов, которые выполняют действия ничего не спрашивая. Такие скрипты нужны довольно редко. А вот всевозможного «добра» для копирования, синхронизации, запуска чего-либо, хоть отбавляй. И если в любимом Midnight Commander Вы вдруг нажали не на тот скрипт, то с системой может произойти все что угодно. Это как правила дорожного движения — «написано кровью».

Совет 2

Отталкиваясь от предыдущего, в начало каждого скрипта неплохо помещать что-то вроде:

read -n 1 -p "Ты уверен, что хочешь запустить это (y/[a]): " AMSURE 
[ "$AMSURE" = "y" ] || exit
echo "" 1>&2

Команда echo, кстати, здесь нужна потому, что после нажатия кнопки <y> у вас не будет перевода строки, следовательно, следующий любой вывод пойдет в эту же строку.

Совет 3

Это ключевой совет из всех. Для того, чтобы не писать каждый раз одно и то же — пользуйтесь библиотеками функций. Прочитав много статей по Bash, я вынужден констатировать, что этой теме уделяется мало внимания. Возможно в силу очевидности. Однако я считаю необходимым напомнить об этом. Итак.
Заведите свою библиотеку функций, например myfunc.sh и положите ее, например в /usr/bin. При написании скриптов она не только поможет сократить ваш труд, но и позволит одним махом доработать множество скриптов, если Вы улучшите какую-либо функцию.
Например, в свете совета 2 можно написать такую функцию:

У вас в vk.com есть любимые музыкальных группы или друзья, с которыми ваши музыкальные вкусы совпадают? У меня да. И хотелось иметь актуальную локальную копию музыки этих групп и друзей, чтобы слушать её, например в машине, телефоне, плейере или где-нибудь ещё. Так родилась идея создания консольного open source приложения vmd (vkontakte music downloader), которое я обещал выложить на github вот в этом посте. Программа мультиплатформенная работает под linux, windows и mac os x. Скачать бинарные сборки под эти ОС можно скачать на домашней странице проекта. Под хабракатом рассказано, как vmd использовать и некоторые технические подробности.

С незапамятных времен в Visual Studio существовала возможность написания визуализаторов для своих C++ типов, что позволяет изменить способ отображения типов в окнах отображающих содержимое переменных в отладчике (такие как auto, watch, locals и всплывающие подсказки для переменных). В Visual Studio 2012 появилась возможность в расширениях к Visual Studio распространять визуализаторы в новом формате natvis.

Были конвертированы старые визуализаторы для Boost'а и мои старые для TinyXML, а также добавил новые визуализаторы для Boost, wxWidgets и TinyXML2. Получилось в итоге расширение к Visual Studio 2012 — C++ Debugger Visualizers

Несколько лет назад, когда CardBus и FireWire (IEEE 1394) еще были относительно «в ходу», многие производители ноутбуков в своей продукции использовали контроллеры семейства PCIXX21 и PCIXX11 фирмы Texas Instruments: один небольшой чип обеспечивал поддержку не только упомянутых интерфейсов, но и многих популярных стандартов сменных карт памяти.

Такой чип (а именно, PCI7411) стоит и в моей NEC Versa S950. Этот малоизвестный ноутбук я в свое время предпочел даже ThinkPad-серии практически исключительно из-за более лучшей поддержки FreeBSD (оборудования в целом и спящего режима в частности) — специально тестировал в новосибирском Техносити перед покупкой. Долгое время я не пользовался встроенным кард-ридером, по привычке обходясь USB'шными «свистками». Но недавно я обнаружил, что FreeBSD до сих пор его не поддерживает. И если лет пять-шесть назад это можно было объяснить отсутствием нормального драйвера для этих контроллеров (нужно было что-то скачивать и собирать самому), то теперь я точно знал, что они «из коробки» поддерживаются во FreeBSD драйвером sdhci(4), о чем прямо сказано на странице руководства (и позже подтвердилось чтением исходников).

Я начал неспешно гуглить на эту тему, и картина стала вырисовываться невеселая. Оказалось, что таких «счастливчиков», как я, немало. Многие постили в рассылки и форумы «портянки» dmesg и pciconf -lv, заводили баги в трекерах (например, OpenBSD PR i386/5843), но решения никто не предлагал. Более того, фактически поставив точку в вопросе, Александр Мотин, автор драйвера sdhci(4), в 2010 г. написал на форуме, что-де TI документацию на чип не дают, а значит, если производитель сконфигурировал чип неверно, а его настройка через BIOS не предусмотрена, сделать что-либо затруднительно. В свою очередь, Theo de Raadt закрыл i386/5843 со словами: «We do what we can. This vendor, amongst other, have their sdhc controllers locked out and hidden behind little undocumented bits. We've strugged before to find this information, and failed. If you can find this information on some other operating system, or in some vendor documentation, we would be thrilled.»

Вопрос о столах поднимался несколько раз (раз, два).

Однако, на чем же мы сидим перед столом?

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

Все мы работаем с компьютером и порой не замечаем, на чем же мы сидим.

Оказывается наши санитарные правила и нормы (СанПиН 2.2.2/2.4.1340-03) достаточно хорошо описывают удобный эргономичный стул для работы взрослых за компьютером!

А какой стул правильный?