bash

Занялся я как-то созданием собственной "библиотеки" цветовых переменных для облегчения подсветки вывода в терминале. Однако быстро убедился, что дело это отнюдь не интересное, а напротив, скучное и утомительное. Каждый раз переправлять и пересохранять скриптик с новыми значениями команды tput или писать длинный однообразный скрипт и потом копаться в его выводе-простыне — удовольствие маленькое. И от скуки и общего разочарования я сочинил этакий почти-интерактивный скриптик, который несколько облегчил это дело, да и сам развлек меня. Может, кому-нибудь пригодится.

Префейс

Описание и код скрипта, сохраняющего прежнее время модифификации файла после его редактирования. Скрипт пригоден для текстовых и офисных форматов файлов, лишь бы они открывались в каком-либо редакторе.

Очень простой скрипт позволяет в 3 – 4 нажатия на клавиши распаковывать (почти) любые архивы и при этом не лезть в маны и хэлпы за параметрами разных архиваторов.

Читать далее...

Бывает нужно узнать версию Glib, которая стоит в системе. Видимо, самый простой и в то же время универсальный способ (должен подходить для разных дистрибутивов) такой:

Читать далее...

Три года назад хабраюзер imitsuran (Андрей Сурнин) опубликовал забавный пост Исправление раскладки клавиатуры а-ля Punto Switcher на bash и в нем полезный скрипт для тех, кто не хочет связываться с программами-аналогами Punto Switcher (Xneur и т.п.).

Скрипт успешно работал в Росинке-9 (читай: в Gnome 2 и с bash-4.1), а потом, в системах с Mate/Cinnamon (c bash-4.2 и 4.3), перестал.

Читать далее...

Перевод статьи "8 Tips for creating better bash scripts", написанной Benjamin Cane и опубликованной на сайте http://bencane.com 6 июня 2014

Benjamin Cane, 2014⁄06⁄06

Когда я только начал администрировать Linux и Unix серверы, я работал в среде, где были тонны скриптов, написанных другими администраторами. Время от времени мне приходилось тестировать их, выясняя, почему тот или иной скрипт перестал работать. Иногда они были написаны правильно и понятно, иногда неуклюже и запутанно.
Хотя поиск и устранение ошибок в плохо написанных скриптах были всегда напрягом, они преподали мне важный урок. Это показало мне, что, даже если вы не думаете, что скрипт будет использоваться в будущем, лучше писать его так, как будто кто-нибудь будет диагностировать его через два года. Причем этот "кто-нибудь" может оказаться кем угодно, даже вами же самим.

Это мой самодельный инструмент для бэкапа. На некоторых системах запускается по крону, на других — ручками по мере необходимости.

Собственно, все необходимые пояснения — в самóм скрипте.

(Стянул в незапамятные времена на каком-то форуме идею и алгоритм, теперь уже не упомню где, сорри. Впрочем, от того исходного скрипта осталась только одна строка, да и та изменена).

Читать далее...