Если 31 августа спросить у GNU date, какой будет следующий месяц, результат будет немного странным:

$ date
Tue Aug 31 11:32:35 UTC 2010
$ date +"%Y-%m" --date "next month"
2010-10
$ date +"%Y-%m" --date "next month"
2010-10

Документация GNU date (см info date Relative items in date strings) специально обращает внимание на эту проблему и рекомендует вычислять следующий месяц не для сегодняшнего числа, а для 15 числа текущего месяца:

$ date +"%Y-%m" --date "$(date +%Y-%m-15) next month"
2010-09

Однажды глубокой ночью мне позарез понадобилось вытащить из остановленной виртуальной машины Virtualbox, находящейся на моем рабочем компьютере, один файлик. Удаленно запустить виртуальную машину и тем более подключиться к ней не получилось, поэтому я решил попробовать вытащить нужный раздел из vdi и смонтировать его. Ситуация немного осложнялась тем, что виртуальный жесткий диск хоть и содержал всего один корневой раздел, но был динамически расширяющимся, а это значит, что блоки файловой системы располагались в хронологическом порядке, а не в том, который ожидает драйвер файловой системы.

К счастью, можно легко преобразовать vdi из динамического формата в статический с помощью многоцелевой утилиты vboxmanage, входящей в состав пакета virtualbox:

vboxmanage clonehd --variant static debian.vdi temp.vdi

Теперь у нас есть файл temp.vdi, внутри которого где-то присутствует образ искомой файловой системы; для ее корректного извлечения нужно вычислить смещение образа относительно начала файла. В половине найденных по запросу «mount vdi linux» статей рекомендуется использовать для этих целей утилиту vditool, предназначенную на самом деле для внутреннего тестирования функциональности виртуальных дисков в VirtualBox. Раньше бинарник vditool можно было отдельно скачать с сайта virtualbox.org, но теперь его там по понятным причинам нет (желающие могут скомпилировать его самостоятельно: vditool.cpp)

Мы, как всегда, пойдем другим путем и воспользуемся подручными средствами. Первые 512 байт нашего vdi-файла — его заголовок, в котором можно разобраться, воспользовавшись, например, этим мануалом или непосредственно описанием структуры заголовка vdi в исходниках VirtualBox. Из этих источников следует, что образ размечен следующим образом:
512 байт: заголовок
4 * N + X: карта мегабайтных блоков, здесь N ­— количество мегабайт в виртуальном жестком диске, а X — выравнивание получившегося числа до ближайшей верхней 512-байтной границы
512 + 4*N + выравнивание: смещение данных

Зная точный размер виртуального диска, можно легко вычислить смещение вручную:

$ vboxmanage showhdinfo f8e0de05-1419-405d-92d9-8358dc1e6bec
VirtualBox Command Line Management Interface Version 3.0.8_OSE
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

UUID:                 f8e0de05-1419-405d-92d9-8358dc1e6bec
Accessible:           yes
Description:
Logical size:         4095 MBytes
Current size on disk: 2637 MBytes
Type:                 normal (base)
Storage format:       VDI
In use by VMs:        debian (UUID: f1f8221a-6542-4dfe-9062-5397f429da4b)
Location:             /home/bvk/.VirtualBox/HardDisks/debian.vdi

(UUID нужного диска можно узнать из вывода команды vboxmanage list hhds). Здесь выравненное до 512 значение размера карты блоков равно 16384, а смещение данных — 16896.
А можно и вытащить смещение непосредственно из заголовка vdi. Например, вот начало моего четырёхгигового виртуального диска:

$ head -c 512 temp.vdi |hexdump  -C
00000000  3c 3c 3c 20 53 75 6e 20  56 69 72 74 75 61 6c 42  |< << Sun VirtualB|
00000010  6f 78 20 44 69 73 6b 20  49 6d 61 67 65 20 3e 3e  |ox Disk Image >>|
00000020  3e 0a 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |>...............|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  7f 10 da be 01 00 01 00  80 01 00 00 02 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000150  00 00 00 00 00 02 00 00  00 42 00 00 00 00 00 00  |.........B......|
00000160  00 00 00 00 00 00 00 00  00 02 00 00 00 00 00 00  |................|
00000170  00 00 f0 ff 00 00 00 00  00 00 10 00 00 00 00 00  |................|
00000180  ff 0f 00 00 ff 0f 00 00  db fa c4 c9 fd 13 ea 49  |...............I|
00000190  9e ae 4e 47 43 3f a0 3c  46 37 6c be e6 fd 02 40  |..NGC?.<f7l ....@|
000001a0  a7 63 44 3f 6e 3f 26 d8  00 00 00 00 00 00 00 00  |.cD?n?&.........|
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001c0  00 00 00 00 00 00 00 00  0a 02 00 00 ff 00 00 00  |................|
000001d0  3f 00 00 00 00 02 00 00  00 00 00 00 00 00 00 00  |?...............|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

Жирным шрифтом выделены необходимые четыре байта offsetData по смещению 0×0158. Можно искать их визуально, помня о little-endian-порядке байт (в этом случае искомое значение равно 0×00004200), а можно воспользоваться простенькой командой:

$ head -c 348 temp.vdi |tail -c 4|perl -ne 'print unpack("L",$_),"\n"'
16896

В любом случае, лишний раз перепроверить себя никогда не помешает.

Посмотрим, что находится по этому смещению. Сразу можно предположить, что там располагается начало образа жесткого диска, из этого следует, что первые 512 байт содержат mbr. Проверим:

$ dd if=temp.vdi bs=512 count=1 skip=$((16896/512))|file -
1+0 records in
1+0 records out
512 bytes (512 B) copied, 3.9397e-05 s, 13.0 MB/s
/dev/stdin: x86 boot sector; partition 1: ID=0x83, active, starthead 1,
startsector 63, 7903917 sectors; partition 2: ID=0x5, starthead 0, startsector
7903980, 481950 sectors, code offset 0x4c

Жесткий диск содержит 2 раздела: основной размером 3859 мегабайт, начинающийся с 63 сектора (1 сектор — 512 байт), и расширенный 235 мегабайт, отведенный установщиком Debian под swap (вот это сюрприз на виртуалке). Для очистки совести проверяем заголовок первого раздела:

$ dd if=temp.vdi bs=512 count=3 skip=$((16896/512+63))|file -
3+0 records in
3+0 records out
1536 bytes (1.5 kB) copied, 4.7716e-05 s, 32.2 MB/s
/dev/stdin: Linux rev 1.0 ext3 filesystem data,
UUID=5ac94027-bf6e-43bc-9c3e-8a7830fe4ff8 (needs journal recovery) (large files)

То, что надо! Осталось смонтировать. Несколько лет назад пришлось бы дополнительно извлекать все 7903917 секторов в отдельный файл и монтировать его, но сейчас можно просто указать смещение от начала файла как опцию mount (оставшиеся расширенный раздел и swap внутри него будут проигнорированы):

$ sudo mount -o loop,offset=$((16896+63*512)) temp.vdi mnt
$ ls mnt/
bin   cdrom  etc   initrd.img      lib         media  opt   root  selinux  sys  usr  vmlinuz
boot  dev    home  initrd.img.old  lost+found  mnt    proc  sbin  srv      tmp  var  vmlinuz.old

Задача решена, все свободны.

В предыдущем посте — небольшая история о том, как в Linux была улучшена поддержка устройств экстра-маленького размера благодаря покупки Линусом Торвальдсом вышивальной машинки :) В письме Линуса в рассылку util-linux-ng@kernel.org было упомянуто, что для управления этой машинкой он использует Eee PC с Fedora 12 на борту. Как пользователь Eee PC 701g с почти двухлетним стажем, я заинтересовался и написал Линусу письмо с несколькими вопросами о его опыте использования этих компьютеров. Получилось мини-интервью, которое и предлагается вашему вниманию.

Q: Какие модели Eee PC Вы используете?
A: У меня их две штуки: 701 и 901.

Q: Это основной компьютер или один из дополнительных?
A: Нет, конечно же, это не основной компьютер. Atom тормозной как грех. Я считаю, что процессоры с прямым выполнением команд (in-order execution) — преступление против человечности, и я уверен в том, что если Intel не предпримет значительных шагов (т.е. сделает Atom out-of-order), ARM Cortex A9 захватит рынок low-end машин.

У меня есть пара нетбуков, потому что я люблю маленькие компьютеры и использую их в поездках. Но они никогда не могли бы служить основными машинами для разработки или чем-то вроде этого.

701 слишком мелкий для того, чтобы быть полезным. Экран крошечный и у него непозволительно маленькое разрешение. Клавиатуру едва можно использовать. 901 намного лучше и мог бы быть неплохим помощником в поездках, но разрешение тоже слишком маленькое (9 дюймов нормально, но 1024×600 юзабельно только для смартфонов, а для лэптопов подошло бы как минимум 1366×768, как мне кажется)

Поэтому я не использую ни один из них ни для чего, кроме тестирования. 901 используется моей женой для её вышивальной машинки, и для такого, обычного использования он подходит очень хорошо.

ВНИМАНИЕ! Наверно, следует заметить, что мои требования могут быть завышенными по сравнению с требованиями многих других людей. Моя основная машина — Nehalem 3.2 GHz c 6 GB RAM и двумя быстрыми SSD-дисками от Intel. Поэтому мои представления о том, какая производительность может считаться «приемлемой», могут не совпадать с представлениями других.

Q: какие задачи Eee PC помогает Вам выполнять?
A: Сейчас 701 работает тестовым стендом для совершенно различных вещей — я держу его поблизости в основном как 32-битный x86-стенд (все мои основные машины — x86-64, поэтому, если мне нужно проверить, что 32 бита еще работают, я использую 701).

901 я иногда использовал в поездках как лэптоп, и в основном он меня удовлетворял, но, откровенно говоря, существуют нормальные ноутбуки, которые намного-намного-намного лучше.

Например, я немного поигрался с машинами, основанными на CULV Core 2 Duo (вместо Atom) с экраном 1366×768 и внезапно обнаружил, что может быть намного более мощная (чем eeepc — прим.пер.) сборка. Она больше по размерам (10 дюймов), потребляет больше энергии, но оно того стоит.

Q: приобрели ли Вы эти нетбуки самостоятельно или они были подарены?
A: Оба Eee PC были подарены. 10″ CULV Core2 было самым достойным приобретением, на которое я потратил свои деньги.

Q: сколько времени Вы проводите перед этим нетбуком? Достаточен ли его размер для Вас?
A: См. выше. 701 и близко не стоял. 901 вполне пригоден к использованию, и если бы у него не было такое маленькое разрешение, он мог бы быть неплохим помощником в путешествиях.

Q: производились ли какие-нибудь аппаратные модификации?
A: в оба добавил памяти, вроде сейчас в обоих по 2 Гб (возможно, 701 был с 512 мегабайтами, и я проапгрейдил до гигабайта, слишком лениво проверять). И еще в оба добавил ПЗУ: в 701 — быструю SD-карточку (понятие «быстрая» тут весьма относительно, но для SD-карточки неплохой результат), в 901 — Mini-PCI SSD.

Мне нравятся high-end SSD (например, интеловские замены жестким дискам), но те, что используются в low-end нетбуках, страдают от ужасающе отвратительной скорости записи. Поэтому SSD в этих нетбуках, как правило, медленнее, чем реальные диски.

Q: и еще один, более общий вопрос. Как Ваше рабочее время распределено между кодированием и административной/политической/социальной деятельностью?
A: Сейчас кодирую очень мало. Практически всё время занято обсуждениями с другими разработчиками и внесением их изменений в ядро.

Часть первая.
На Рождество Санта Клаус подарил Туве Торвальдс машинку для вышивания. Среди прочих достоинств эта машинка имеет USB-интерфейс, по которому можно закачивать заранее приобретённые шаблоны вышивки в специальном закрытом формате. При подключении к компьютеру это чудо техники через минуту определяется как USB mass storage с файловой системой FAT12, при этом закачивание небольших файлов происходит очень долго и зачастую не приводит ни к каким результатам: о возникающих ошибках пользователю ничего не сообщается. Таково всё проприетарное ПО, — сетует Линус, — закрытые форматы, кривые прошивки, невнятные ошибки… Проблема предпросмотра шаблонов вышивок в формате PES на компьютере оказалась самой простой и теперь на git.kernel.org имеется специальная программа pesconvert для обслуживания вышивальных машинок.

Часть вторая.
Линус пишет письмо в рассылку util-linux-ng@vger.kernel.org с детальным описанием длительного процесса определения типов разделов и ФС на маленьком, медленном и подглючивающем блочном устройстве. После активного обсуждения (которое, несмотря на явную гиковость, можно читать как захватывающий детектив) было найдено несколько узких мест в утилите blkid, пытающейся определить более чем 50 типов файловых систем по их сигнатурам, что приводит к неоднократному чтению 69 килобайт с устройства, и в сумме объём прочитанных данных, с учётом упреждающего чтения, составляет около половины объёма всего устройства. Учитывая тот факт, что скорость обмена данными у этой штуки составляет 16 килобайт в секунду, простое определение единственного fat-раздела занимает около 30 секунд (всё это нужно для того, чтобы udev смог корректно примонтировать это устройство).

Совместными усилиями задержка была сведена к рекордному минимуму в полсекунды. Для этого Karel Zak (главный мейнтейнер util-linux-ng) добавил в blkid несколько опций, ограничивающих количество возможных ФС и объём читаемых данных для очень маленьких устройств (зачем пытаться определить raid на диске размером с полдискеты?), Линус немного оптимизировал кое-какие системные вызовы и теперь в ближайшем выпуске util-linux-ng будет заявлена поддержка очень маленьких дисков, а в ядре Linux, чем черт не шутит — частичная поддержка неких вышивальных машинок.

Часть третья последует, не пропустите.

Несколько месяцев назад заинтересовался причинами появления управляющих кодов ASCII в их нынешнем виде. Раскопки привели меня к первым терминалам в Multics, терминалы — к телетайпам, телетайпы — к телеграфным аппаратам. Тема чрезвычайно интересная, но полноценного поста у меня так и не вышло по разным причинам. Просто накидаю сюда ссылок для интересующихся (в основном на английском).

Unix и его предшественники
Multicians.org — один из основных сайтов по предыстории Unix. В основном описывает различные аспекты ОС Multics (включая рекламную брошюру (4 Мб)), но содержит также массу сведений и о ранних вариантах Unix, и о CTSS.

Unix history — основной сайт по истории Unix.

Концепция иерархической файловой системы впервые была описана в 1965 году и сильно отличалась от ныне используемой. В частности, в качестве разделителя каталогово предлагалось использовать двоеточие, а на уровень выше можно было ссылаться как на *; у каждого файла присутствовал специальный атрибут TRAP, в котором можно было указать свою процедуру проверки прав доступа к этому файлу. Но уже в Multics реализация файловой системы значительно отличалась от данного проекта иной, а в Unix и вовсе приняла привычный нам вид.

The Evolution of the Unix Time-sharing System (Dennis M. Ritchie, 1979) — краткая история Unix, рассказанная одним из её создателей.

The Restoration of Early UNIX Artifacts — опыт восстановления файлов с древней ленты, содержащей один из самых первых релизов Unix. В конце документа несколько интересных ссылок.

Исходный код Unix — отсканированная распечатка тщательно прокомментированных ассемблерных кодов Unix. Датируется 1972 годом. 11 мегабайт.

Excavating ancient abbreviations in Linux ­— история происхождения некоторых аббревиатур, используемых в UNIX/Linux (для чтения оригинала требуется
регистрация, поэтому ссылка на кэш гугла).

Буду благодарен за PDF/DJVU версию книги «A quarter century of Unix» by Peter Salus :)

Терминалы
Коллекция информации о текстовых терминалах, отправная точка исследований.

Рассказ одного из создателей Multics о первых терминалах и опыте удалённой домашней работы (70-е годы, суперкрутые модемы на 1200 бод) (en)

Краткая история терминалов DEC (в т.ч. VT100)

Что такое «smart terminal» и чем он отличается от «dumb terminal». В
основном тем, что умеет проверять пользовательский ввод уже на стороне терминала, а не передаёт его серверу.

Телеграф
К вопросу о возникновении телеграфа множество интересных сведений из истории телеграфной связи

История телеграфа в России

Телеграфное дело. Пособие для сержантов и старших специалистов войск связи — раритет :) Книжка 1946 года выпуска, доступно и понятно описывает теорию электротехники и электроники по состоянию на момент окончания Великой Отечественной войны, а также знакомит читателя с основными понятиями телеграфной связи.

Для тестирования различных версий нашего продукта (внутри — БД под управлением mysql и интерфейс к ней на PHP под Apache2) требуется быстро создавать многочисленные chroot-окружения на выделенном сервере и управляться с ними.

В базовой системе (lenny) оставляем только функционал, необходимый для управления всем хозяйством, лично мне необходимы mc, openssh, vim, bash_completion и иногда svn. Также неплохо поиметь где-нибудь (да хоть на этой же машине) кэширующий прокси для репозиториев debian, типа apt-proxy или apt-cacher, чтобы не создавать излишнюю нагрузку на региональные зеркала. У нас используется apt-cacher, работающий по адресу http://apt:3142.

Debootstrap ­— основная рабочая лошадка:

apt-get install debootstrap

debootstrap --include=mc,ssh,vim lenny /systems/lenny http://apt:3142/ftp.debian.org/debian/

Первый аргумент — название релиза, второй — путь, куда устанавливается система, третий — адрес репозитория. В опции –include через запятую указываются пакеты, которые необходимы, но не входят в минимальную базовую систему. Debootstrap выкачивает из репозитория и устанавливает минимальный набор пакетов, теоретически сразу после этого можно делать chroot /systems/lenny и переходить к работе, но осталась еще несколько немаловажных доделок:

Добавляем идентификатор системы, который будет отображаться в скобках в приглашении шелла (читай — bash), выполняемом в chroot-окружении:

echo lenny > /systems/lenny/etc/debian_chroot

Но работа в основном ведется от имени root, а в squeeze и sid у root’а в .bashrc переменная окружения PS1 переопределяется и этот идентификатор пропадает. Поэтому если делаем виртуалку squeeze, то строчку с PS1 в /root/.bashrc лучше закомментировать:

sed -i 's/^\(export PS1.*\)$/#\1/g' /systems/squeeze/root/.bashrc

Монтируем /dev/pts — виртуальную файловую систему, которая динамически создаёт файлы терминалов /dev/pts/X для каждого нового подключения; это необходимо для нормального функционирования многих программ, работающих с терминалом, в т.ч. скриптов postinst и config пакета mysql-server:

mount -t devpts devpts /systems/lenny/dev/pts

Монтируем /proc (реально proc в новом месте будет содержать ту же информацию, что и общесистемный /proc):

mount -t proc proc /systems/lenny/proc

Чтобы apt-get не ругался на неподписанные пакеты при установке, необходимо обновить файл Release.gpg, т.к. по умолчанию debootstrap его не устанавливает. Это проще всего сделать обновлением индексных файлов репозитория:

chroot /systems/lenny apt-get update

После этого уже можно делать chroot /systems/lenny, устанавливать и настраивать пакеты, запускать/останавливать сервисы и т.д. Главная проблема при этом ­— следить за тем, чтобы сервисы в разных chroot’ах не конфликтовали, пытаясь занять порт на одном IP-адресе. Обычно добавляются виртуальные сетевые интерфейсы и им назначаются виртуальные же IP-адреса, которые и указываются в настройках сервисов.

Disclaimer: данная заметка описывает мой персональный опыт и не претендует на полноту. Комментарии и дополнения приветствуются.

Выдержка из man 1 watch (входит в комплект утилит procps в Debian Lenny):

You can watch for your administrator to install the latest kernel with

        watch uname -r

(Note that -p isn’t guaranteed to work across reboots, especially
in the face of ntpdate or other bootup time-changing mechanisms)

В комментариях к прошлогоднему переводу Bash Pitfalls внимательный flavi задался вопросом, почему при попытке выполнить скрипт, в начале которого написано

#!/bin/bash --posix --verbose

выдаётся ошибка

/bin/bash: --posix --verbose: invalid option

в то время как в интерактивном режиме bash нормально запускается с такой комбинацией опций; более того, если в shebang’е оставить только одну из этих опций, то скрипт также запускается без ошибок.

Поначалу я предположил, что --posix запрещает опции, не определённые стандартом POSIX на sh. Но тогда попытка выполнить bash --posix --norc также приводила бы к ошибке, и конструкция #!/bin/bash --verbose --norc работала бы нормально, а это не так.

Пришлось разбираться более плотно. В bash (1) я вычитал следующее (выделение — моё):

If the program is a file beginning with #!, the remainder of the first line specifies an interpreter for the program. The shell executes the specified interpreter on operating systems that do not handle this executable format themselves. The arguments to the interpreter consist of a single optional argument following the interpreter name on the first line of the program, followed by the name of the program, followed by the command arguments, if any.

Т.е. в shebang можно задавать только один аргумент; кроме того, bash самостоятельно анализирует shebang и вызывает указанный интерпретатор только в случае, если система сама не может выполнить этот скрипт.

Сам файл передаётся на выполнение с помощью системного вызова execve (2) (это я вычитал в файле execute_cmd.c в исходном коде bash), в man-странице которого и разъясняется политика партии по поводу разбиения аргументов интерпретатора:

On Linux, the entire string following the interpreter name is passed as a single argument to the interpreter, and this string can include white space.

Таким образом, в самом первом примере у bash в argv оказывается не два аргумента --verbose и --norc, а один --verbose --norc, что и приводит к ошибке, и вина bash лишь в том, что он не разбивает свои аргументы на части, как это делает, например, Perl.

Причина такого странного поведения операционной системы (казалось бы, что сложного в том, чтобы просто разбить строку на части по пробелам или символам табуляции) описана, например, в этой дискуссии LKML или, более подробно, в письме Garance A Drosihn в рассылку freebsd-arch. Вкратце, если бы механизм механизм обработки shebang (в Linux — linux/fs/binfmt_script.c) передавал все аргументы интерпретатору, то для некоторых из них было бы затруднительно отделить аругменты интерпретатора от собственно аргументов вызываемого скрипта. По крайней мере, так было еще на заре развития Unix и с тех пор большая часть Unix-систем передаёт все аргументы как единую строку.

Пытающимся отвыкнуть от идеологии CVS и SVN — рассказ о концепциях распределённых систем контроля версий.

Более подробное введение

ага, для ссылок есть твиттер и del.icio.us, но ЭТУ ссылку я уже однажды потерял. Так что пусть тут побудет, в назидание.

Если после перезагрузки не сохраняются параметры клавиатуры в Gnome-окружении Debian или Ubuntu, поможет добавление setxkbmap в приложения, запускаемые автоматически при входе в систему («Система — Параметры — Запускаемые приложения» или «System — Parameters — Sessions»)

Если при монтировании расшаренного через Samba каталога через mount.cifs симлинки отображаются как локальные ссылки, нужно на обеих машинах в smb.conf отключить unix extensions, которые и отвечают за такое поведение символических ссылок:

unix extensions = no

Если в Ubuntu одновременно перестали работать su, sudo, входы в систему с консоли и через ssh (основной симптом: зависает после ввода пароля), то для постановки окончательного дифференциального диагноза можно попробовать выполнить команду «logger test». Если и это зависает, то налицо проблема с демоном syslogd. В моем случае решение вылилось в отключении опции «-r» в/etc/default/syslogd (принимать сообщения по сети), которая однажды была добавлена мной для удаленной отладки одного voip-телефона. На самом деле это явная бага, которая, судя по Ubuntu Bug 26986, тянется аж с 2005 года.

В блоге «Полезные советы по Linux» наткнулся на способ ссылаться на определенное место в документации:

sh -c 'PAGER="less" LESS="-p search_string" man man_page'

Явно вызываем sh, задаем просмотрщик less и указываем ему строку, которую нужно найти. Команда man запустит less и прокрутит экран до первого совпадения.

Конечно же, необходимо убедиться, что заданный шаблон присутствует в документе хотя бы один раз, и первый раз встречается именно в том месте, на которое вы хотите сослаться. Если ни одного совпадения не найдено, будет выведена ошибка и man будет показан с его начала, да и то только после нажатия Enter. Также стоит учитывать, что у адресата вашего сообщения может быть другой shell, другая версия документации и вообще другая операционная система.

Несколько примеров (предполагаем, что в качестве шелла используется sh-compatible shell типа bash или zsh, а переменная PAGER установлена в less).

Абзац в bash (1) про фичу complete-into-braces из одной из предыдущих заметок:

LESS="-p complete-into-braces" man bash

Раздел про подстановку из истории в bash (1). Поскольку строка HISTORY EXPANSION в документе встречается неоднократно, то требуется привязка к началу строки:

LESS='-p ^s*HISTORY EXPANSION' man bash

Подсветка важной фразы целиком:

LESS='-p Please note.*log the command[^.]*.' man sudo

Этот фокус можно задействовать в других утилитах, использующих less, например, в perldoc:

LESS='-p ^s*Range Operators' perldoc perlop

О том, как эта конструкция работает:

LESS='-p MANPAGER, PAGER' man man
LESS='-p -ppattern.*' man less
LESS='-p Options which.*' man less

Из /usr/share/doc/mc/README.Debian:
- если в истории команд mc постоянно присутствуют строки вида cd "`printf "%b" '\0057home'`", убедитесь, что в переменной окружения HISTCONTROL присутствует ignorespace или ignoreboth, или же эта переменная вообще отсутствует. Подробности в debian bug 440102.
- действие, с незапамятных времен выполнявшееся по кнопкам M-O (в противоположной панели отобразить путь в текущей панели), с 4.6.2-pre1 пор переехало на M-I, а на M-O теперь отображение в другой панели родительского каталога, или каталога, находящегося под курсором. Эргономично, да, но очень непривычно. Кстати, русскоязычная справка, вызываемая по F1, описывает старое поведение.

За 10 минут сделал патч, добавляющий вариант «сортировать файлы по версии» в меню выбора режима сортировки. К сожалению, простой правкой конфига тут обойтись не получилось, поэтому пришлось пересобрать пакет mc целиком — еще 40 минут, но оно того стоило :-)

vimdiff Alt-A Alt-Enter Tab Alt-A Alt-Enter Enter

и

diff -rubB Alt-A  Tab Alt-A Enter

Этот код добавляет в меню две команды: сравнения двух каталогов и мержа файла в одном каталоге с одноименным файлом в другом каталоге:

d   Compare directories
    if [ "%d" = "%D" ]; then
      whiptail --msgbox "The two directores must be different" 7 60
      exit 1
    fi
    diff -rubB "%d" "%D" | vim -

# обычный непомеченный файл
+ t r & ! t t
f   Diff & merge file under cursor with the same file in other panel
    if [ "%d" = "%D" ]; then
        # если в противоположной панели открыта та же папка
        whiptail --msgbox "The two directores must be different" 7 60
      exit 1
    fi
    if [ ! -f "%D/%f" ] ; then
       # если в противоположной панели нет файла с таким же именем
        whiptail --msgbox "No copy of %f in %D" 7 60
        exit 1
    fi
    if diff -q "%D/%f" "%d/%f" ; then
       # если файлы не различаются
        whiptail --msgbox "%D/%f and %d/%f are identical" 10 80
        exit 1
    fi
    vimdiff "%d/%s" "%D"

Иногда возникает путаница между опциями -r и -R, каждая из которых в разных программах может означать рекурсивную обработку файлов в найденных каталогах. А может означать нечто совершенно противоположное или работать не так, как этого ожидал пользователь. Попробуем разобраться, в каких случаях что используется.

Эпиграф

— Это новый «Гарри Поттер». Я заказал версии для детей и взрослых, чтобы проверить, что в тексте нет различий.
Морис Мосс, The IT Crowd.

chmod

Неправильно:

chmod -r 755 dir

Ключ -r у chmod интерпретируется как «запретить всем чтение файла», а 755 в данном случае рассматривается как название файла, у которого изменяются права. Поскольку в подавляющем большинстве случаев файла с таким названием в текущей директории отсутствует, то команда возвращает ошибку.

Правильно:

chmod -R 755 dir

chown, chattr, chgrp

Неправильно:

chown -r user:group dir
chattr -r dir +I
chgrp -r group dir

У вышеперечисленных команд опция -r просто отсутствует. Для рекурсивной обработки директорий необходимо использовать опцию -R. Очевидно, так сделано из солидарности с «братской» командой chmod

Правильно:

chown -R user:group dir. .
chgrp -R group dir
chattr -R dir # только Linux, только для ext2/ext3

cp

Неправильно:

cp -r dir destdir

Правильно:

cp -R dir destdir

Несмотря на то, что в странице документации cp из GNU coreutils сказано, что опции -r и -R равнозначны и означают рекурсивную обработку встречающихся директорий, опция -r, в отличие от -R, не соответствует стандарту POSIX и ее указание может повлечь за собой неожиданные последствия в случае, если очередной копируемый объект является чем-то отличным от обычного файла или директории (например, символической ссылкой, fifo или сокетом). В таких случаях некоторые реализации cp просто копируют содержимое ссылки/fifo, тогда как при -R такие объекты пересоздаются заново. Раньше такое поведение было присуще GNU cp, о чем до сих пор имеется свидетельство в русском man cp. Что касается более правильных (чем Linux) систем, то, например, в BSD-версии cp опция -r работает в «режиме совместимости», т.е. не создает символическую ссылку заново, а копирует содержимое в файл с тем же именем.

ls

Неправильно:

ls -r

Ключ -r команды ls означает «обратный порядок сортировки»
Правильно:

ls -R

rm, grep

Зато в следующих случаях употребление -r/-R равнозначно:

rm -r dir
rm -R dir

а также

grep -r pattern dir
grep -R pattern dir

Что касается grep, то, во-первых, обе опции не соответствуют POSIX (но, похоже, присутствуют во всех реализациях) Во-вторых, иногда возникает путаница между опциями -i (игнорировать регистр) и -I (пропускать двоичные файлы). Но это уже тема для другого разговора :)

Прочие команды

Поскольку команд, в том или ином виде поддерживающих рекурсивную обработку каталогов, набралось довольно много, то я попробовал свести их в одну таблицу.

Заключение

Как видно, в большинстве случаев для указания рекурсии используется опция -r в нижнем регистре, в противовес стандартным утилитам, для которых характерно все же -R. Поэтому совет один: в случае сомнения смотрите в man, там все написано :)

Постскриптум

По абзацу про cp видно, что русская документация в некоторых дистрибутивах (не будем показывать пальцем на Debian и Ubuntu) не соответствует реальному положению дел. В частности, несмотря на то, что в jaunty используется GNU coreutis 6.10, русский man описывает cp версии 4.1. Желающие могут самостоятельно сравнить свою версию man 1 cp с локализованной. Другими словами, русская страница документации cp в силу своей древности вводит пользователя в заблуждение, т.е. врёт. По этой причине я рекомендую сделать apt-get remove manpages-ru.

Еще немного про perl. Перелистывая Perl Cookbook, вдруг осознал, что никогда не задумывался о возможностях оператора диапазона «..«. То есть, конечно, понятно, что в списковом контексте он вернет список значений от левого операнда до правого и конструкция foreach(1 .. 5) превратится в начало натурального ряда. А вот про то, что в скалярном контексте этот оператор ведет себя наподобие диапазона в sed, я не знал. Например, часто возникающая задача «сделать что-то с данными между открывающей и закрывающей строкой» решается просто и элегантно:

perl -ne 'print if /<Directory /i .. /<\/Directory>/i' httpd.conf

Благодаря кажущейся простоте этого оператора (зачем читать доку про такие элементарные вещи, если в первом попавшемся букваре по перлу написано, что именно делает этот оператор) редкая птица удосужится ознакомиться с описанием .. в perlop, что и приводит к подобным открытиям.

Не последнюю роль тут играет и местами довольно сложный язык документации. Но мир меняется к лучшему и недавно на translated.by в рамках проекта pod2-ru под руководством Анатолия Шарифулина народ принялся за перевод perldoc. К настоящему моменту уже переведены: perlbook, perldoc, perlpragma, perlstyle; на подходе perlintro и в процессе одна из центральных страниц документации — perlfunc. Также переведена примерно половина perlboot. Так что если есть желание и возможность помочь в переводе документации perl, присоединяйтесь к любому из этих переводов или начинайте свой. Даже с минимальными знаниями английского языка вы можете помочь в качестве редактора или корректора. В общем, внесите уже свой вклад в open source :)

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

Сначала был примерно такой код:

Логично было бы объединить два условия в одно:

Но после этого условие стало выполняться для каждой строки STDIN, вне зависимости от того, совпадает она с шаблоном или нет. Попробуем разобраться.

Для простоты рассмотрим однострочник на Perl, локализующий эту проблему:

Здесь в одном условии встречаются три оператора: присваивания =, привязки =~, а также логическое И &&. Согласно perldoc perlop, оператор присваивания имеет более низкий приоритет, чем два остальных, поэтому выполняется последним, и код можно представить в виде:

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

Поэтому при объединении условий всегда нужно проверять приоритеты операторов и группировать условия вручную: