Довольно распространенная задача в скриптах – получить размер файла в различных попугаях, к примеру в строках. Для этих целей есть годная утилита wc. Вот только выхлоп у нее не очень удобный, кроме попугаев в выхлопе присутствует еще и имя файла. Чтобы эту гадость вырезать, необходимо прибегать к каким-то конвейерным конструкциям. НО! В случае, если файл подается на стандартный вход, имени никакого нет, и на выходе получается только необходимая величина. Поэтому идеал – lines=$(wc -l < /path/to/file)
WHY, STUPID MOTHERFUCKERS, WHY ?!?!?! i don't need your fucking restrictions to your drug-based naming conventions --- glib-2.54.3/gio/glib-compile-schemas.c.orig 2018-02-09 07:22:22.154862311 +0200 +++ glib-2.54.3/gio/glib-compile-schemas.c 2018-02-09 07:23:04.773862128 +0200 @@ -1219,19 +1219,6 @@ return; } - if (path && (g_str_has_prefix (path, "/apps/") || - g_str_has_prefix (path, "/desktop/") || - g_str_has_prefix (path, "/system/"))) - { - gchar *message = NULL; - message = g_strdup_printf (_("Warning: Schema “%s” has path “%s”. " - "Paths starting with " - "“/apps/”, “/desktop/” or “/system/” are deprecated."), - id, path); - g_printerr ("%s\n", message); - g_free (message); - } - state->schema_state = schema_state_new (path, gettext_domain, extends, extends_name, list_of);
Fullscreen в fvwm
Раскрытие окна на весь экран – приятная штука. Иногда. Особенно, когда экран невелик. Вот только есть эта фича не везде, где нужно. Но, “мы не можем ждать милостей от природы, взять их у нее — наша прямая задача”, так, кажись, дедушка мичурин говорил. Посему, вместо того, чтобы надеяться на разработчиков того или иного софта на предмет полноэкранного режима, такое вот решение для fvwm
Numpad и xmodmap
лично меня редкостно выбешивает отвратная работа numpad-а, как средства навигации. т.к. начинал с xt-клавиатур, то эти ваши at-стрелочки считаю новомодным хипстерством. после каких-то очередных обновлений эта гадость в связке urxvt+tmux отказалась работать вообще. только цифровой ввод, и пох на состояние numlock. игрища с разными типами терминалов и баловства с настройками не особо и помогли. причем без tmux/screen, в голом urxvt все работало as expected
в результате этих головняков я задался простым вопросом – а нахер мне в системе вообще два типа стрелок, хомендов и прочих пейджапов? ответ был однозначный – нахер мне это не упало, и одного достаточно. в результате родился такой вот конфиг для xmodmap, мапящий numpad-овские кнопки на соответствующую навигацию. заодно и caps на shift+caps перевесил, а то частенько ложные срабатывания были
Шалости с перенаправлениями
есть в составе coreutils очень забавная команда tty. все, что она делает – это выводит путь к текущему терминалу или псведотерминалу. что-то типа /dev/tty1 или /dev/pts/1. зачем это нужно, кроме как для понтов, спросите вы? а вот зачем.
к примеру, есть скриптик, кругом красивый и интерактивный, и использующий dialog, а не обычный read или подобное, для получения данных от пользователя. и есть необходимость получить какое-то значение, и сразу загнать его в переменную, без извращений с временными файлами или иными дополнительными сущностями. классический подход var=$(command) здесь не сработает. однако наворотив вот такую конструкцию
var=$(dialog --inputbox "Enter some data" 8 60 2>&1 > $(tty))
можно спокойно получить требуемый результат
gtk-doc для eudev
все в этом мире имеет как свои хорошие, так и плохие стороны. gentoo в этом плане – не исключение. сейчас речь об их форке udev-а – eudev.
хорошее, в принципе, дело. systemd в частности и поттеринг вообще очень многих (я не исключение) крайне заебали своими закидонами. поэтому иметь подобную альтернативу крайне нужно. но вот как они развиваются? ладно, выбросили gudev, glib-овую обвязку, это, в принципе, нормально. но вот нахуя при этом еще и выпиливать gtk-doc для всего – это пионерство для меня осталось загадкой. документация по api библиотек – для лохов? программа хорошо документированная на языке программирования си?
я бы еще воспринял это изменение, если бы ребятки предоставили более-менее адекватную замену, какой-нибудь man 3 libudev или что-то наподобие. так ведь хуй там.
благо, комментарии из кода не выкинуты (пока), и gtk-doc можно запилить обратно. патч для версии 3.2.1 можно взять здесь
Безопасность eval
и еще раз к вопросу о пользе чтения man-ов
eval считается крайне уязвимой конструкцией, особенно на произвольных данных. дескать, подставь ; и лепи себе дальше патчи бармина, сколько душе угодно.
оно то так, но есть в bash одна очень приятная штука для борьбы с этим злом – расширитель @. позволяет экранировать всякую каку без особых извратов с echo/sed/perl/whatever
Ошибка в GraphicsMagick
обнаружилась тут давеча омерзительная вещь, при создании скриншотов gm import начисто игнорирует опцию -frame, и вообще не желает включать обрамление окон в скриншот. причем гадость эта проявляется только при выборе окна мышью. если явно указывать id, к примеру предварительно узнав его через xwininfo -frame, все делается корректно.
пришлось лезть в исходники. сначала я грешил на некорректную работу XQueryTree, но потом все оказалось значительно тривиальнее. классический use after free при разборе данной опции.
Временные метки при логировании
захотелось странного – меток времени в .xsession-errors. обычно этот файлик создается простым редиректом всего выхлопа через exec > blah-blah 2>&1. а далее в ход идет bash-евская магия с сопроцессами. в результате команда приобрела следующий вид
exec > >(while read ln ; do echo "[$(date)] : $ln" >> "${TMPDIR:-/tmp}/xsession-errors.$USER" ; done) 2>&1
дальше можно уже изгаляться как угодно, фильтры там добавить, чтобы лишнее отсеять ну или кто во что горазд
по хорошему, вместо дерганья внешней date надо бы написать свою командочку для вывода, благо последние версии bash (4.4) это позволяют. но это уже как-нибудь в другой раз
FVWM и переводы gettext
в fvwm есть хорошая штука – встроенная поддержка gettext. все сроки описанные как $[gt.String] являются переводимыми. одна проблема, как это все извлечь и запихать в .po файл. руками – неспортивно, писать отдельную тузлинку – как-то чрезмерно. наиболее оптимальный вариант – внедрить поддержку этого дела в какой-нибудь из существующих инструментов.
я выбрал пакет intltool. везде его использую, реализован он на perl-е, что весьма лепо, и для подобных задач самое оно. патчик получился на удивление простеньким
Read в конфиге FVWM
в man fvwm по поводу команды Read написано следующее – This looks for file config in $FVWM_USERDIR and $FVWM_DATADIR directories, as described in Read.
но вот чтобы работала таки $FVWM_DATADIR, т.е. переменная окружения, а не FVWM_DATADIR, т.е. макрос m4, определяемый и используемый на момент compile-time, не неизменяемый в runtime, приходится таки напильничать.
надфиль следующий
--- fvwm-2.6.7/fvwm/read.c.orig 2016-12-07 14:12:09.000000000 +0200 +++ fvwm-2.6.7/fvwm/read.c 2016-12-07 14:19:43.728814143 +0200 @@ -239,8 +239,14 @@ if((f = fopen(full_filename, "r")) == NULL) { - full_filename = CatString3( - FVWM_DATADIR, "/", filename); + char *datadir = getenv ("FVWM_DATADIR"); + + if (datadir) + full_filename = CatString3( + datadir, "/", filename); + else + full_filename = CatString3( + FVWM_DATADIR, "/", filename); f = fopen(full_filename, "r"); } }
Emacs и tearoff меню
у всех меню в gtk-шной сборке emacs-а включен tearoff – мерзкая дурость, позволяющая меню закрепить в отдельном окне. удобство довольно сомнительное, по крайней мере для редактора, который обычно развернут на весь экран. и лично меня жутко раздражала эта мерзкая полоска из дефисов, которая еще и подсвечивается, в каждой менюхе. хорошо, хоть не очень часто меню пользуюсь
в конце-концов решил это недоразумение выпилить. поначалу кромсал код, но потом нашел более элегантное решение. просто перед сборкой сделать export CFLAGS="$CFLAGS -UHAVE_GTK_TEAROFF_MENU_ITEM_NEW"
все, задача решена
Провал перехода на gtk3
очередная попытка перейти в системе на gtk3 – очередной провал, и очередной откат на gtk2
первая причина проста – нет софта.
- firefox без наличия в системе gtk2 не собирается, какие рашпили не применяй. а последние версии, требующие обязательного присутствия в системе антикварного autoconf-2.13 – вообще лютейший пиздец.
- нормального почтового клиента – нет. любимый sylpheed – только gtk2. claws – хоть и собирается под gtk3, но его собственные виджеты для списков – полный пэ, кладущий стопицот болтов на текущие темы в частности и css-движок вообще. balsa – эта дура не умеет локальные ветки, только с сервера. поле references (rcf 4021) – то ли не осилили, то ли для лохов. громоптиц – та же беда, что и с огнелисом
- gimp – пока что только gtk2. что там у них в git-е творится, даже и смотреть не хочу.
- pidgin – аналогично. а учитывая то, что они весь интерфейс 3-й ветки переводят на webkit, но при этом почему-то используют webkit, а не webkit2 – вообще вызывает изрядное недоумение
вторая причина – собственно либа и вектор ее развития
тут подходит старая поговорка “садился – бодрился, стал срать – и упал”. нелогичность развития просто поражает. есть куча положительных моментов, типа выкидывания всяких [vh] классов, вроде GtkVSeparator/GtkHSeparator и т.д. унификация сложных виджетов (selector->chooser). выбрасывание deprecated барахла, и как следствие – чистка кодовой базы. но блядь!!! с барахлом они переборщили. от релиза к релизу куча полезных штук объявляется устаревшими, взамен ничего не предлагается.
- стоковые элементы – устарели. замены нет. объяснение – дергайте иконки из темы. ДОЛБОЕБЫ, БЛЯ, СТОКОВЫЕ ЭЛЕМЕНТЫ – ЭТО НЕ ТОЛЬКО ИКОНКИ! а еще и перевод меток и простота api для пользователей.
- иконки в меню – устарели. пояснение – хотите иконки, пихайте свой контейнер. схуяли? на кой хрен эту рутину переносить из библиотеки в приложения?
- csd – вообще боль и печаль. особенно их неотключаемость без хаков с LD_PRELOAD
- отсутствие color picker-а в диалоге выбора цвета – тоже изрядно напрягает
- popover – отдельная тема для ненависти. изначально идея неплохая, но ее реализация – бля, узнаю, какая тварь это выдумала – буду топтать пожизненное на американской киче
вот такие пироги. жаль, что поторопился свой yad покострячить. теперь придется задвигать trunk в отдельную ветку и мержить legacy обратно в trunk
upd: и да, отдельную ненависть вызывает стремление использовать GSettings для хранения настроек и прочих текущих состояний диалогов выбора файла и цвета, и как следствие – косвенное требование наличия dconf в системе
eject и setuid
экспериментирую тут с автомонтированием через udev с добавлением всяких собственных ништяков. pmount мне не особо нравится, к тому же надобность есть только в отмонтировании из-под пользователя, а это можно и другими средствами реализовать. наиболее приемлемым мне показался eject (из состава util-linux) со взведенным uid битом. но, как оказалось, не все так просто, как казалось. chmod ug+s /usr/bin/eject особого эффекта не дал. отмонтирование сбоило из-за недостатка прав. изучение исходников показало, что за каким-то чертом разработчики запуск umount делают весьма странным образом. после fork-а дергают sedgid(getgid()) и setuid(getuid()). сакральный смысл этих действий мне совершенно неясен, потому перед сборкой делается следующее:
sed -i 's/getgid/getegid/' sys-utils/eject.c
sed -i 's/getuid/geteuid/' sys-utils/eject.c
после этого все работает как надо
FVWM и буфер обмена
В связи с переходом на gtk3 встал вопрос о менеджере буфера обмена. Всякие parcellite и клоны, мягко говоря, дерьмецо. Заточены в основном под gtk2. Да и хренова туча всякой дополнительной лабуды в них мне и в хер не уперлась. Пришлось воротить что-то свое. В принципе, все, что мне нужно – это хранить некую не очень большую историю и иметь возможность выбрать нужный кусок.
В результате родилось следующее. Небольшой скриптик, использующий xclip для управления буферами и fvwm для его периодического дергания и организации меню выбора нужного куска.