По всей видимости, наступило глобальное переутомление. Я с завидной регулярностью прибиваю / или делаю rm -rf /usr/lib, окружающие теряют способность сверить две строчки текста, несем всякую чепуху и т.д...

Что происходит? Магнитные бури? Вспышки на солнце?

Находим в конфиге два слова: "begin rewrite"
Добавляем туда строки:
<старый адрес> <новый адрес> [<флаги>]

Где <флаги> - указания, что перезаписывать. Если не указать, перезаписано будет все.
F - адрес в envelope-from
f - From:
r - Reply-To:
s - Sender:

Остальные флаги.

Решил написать о своей недавней "лаже", не принесшей никаких неприятностей, кроме бессонной ночи.

Итак, все началось с идеи оптимизировать свой /, избавившись от фрагментации файлов. В случае ext3, да и вообще linux - единственный эффективный способ - забекапить все файлы, создать ФС заново и восстановить файлы на старое место.
А для проверки фрагментации можно использовать команду e2fsck. Общеизвестно, что запускать эту команду на смонтированной фс не стоит. Но, зная это, я все равно запустил. ) Спохватившись после слов "recovering journal", я ткнул Ctrl-C (может быть, это добавило некоторое удовольствие мне в последствии, кто знает). Это было моей первой ошибкой. )
В общем, решив продолжить дело, я взял рядом лежащий диск с Ubuntu, загрузился и сделал fsck еще раз, исправляя ошибки. Фрагментация оказалась на уровне 2.2%, что не так много-то в общем...
После чего, воспользовавшись tar, я полностью сбекапил / в tar.gz, сделал mke2fs -J /dev/hda1 и полез распаковывать tar.gz со старой корневой системой. И вот как-то незаладилось. Архив был объемом порядка 2ГБ, а распаковывалось (и без сообщений об ошибках!) всего около 380 мегабайт. Долгая ругань с товарищами с #linux кончилась тем, что я запустил cpio с очень подробными опциями, и оказалось что все заканчивается на забитых нулями блоках. Я все-таки смог пропустить их, используя dd, и скармливая поток через пайп тому же cpio. Теперь, вроде-бы, распаковалось все и я даже смог загрузиться.
В чем же была моя вторая ошибка? Да элементарная - я не проверил созданную копию. )
Ну далее дело оказалось не очень хитрым - загрузился в новую систему, заметил, что часть библиотек и бинарников, в общем-то, отсутствует, и повреждена. Помог debsums - он показал, как и то чего нет, так и то что повредилось. aptitude reinstall восстановил все поврежденные файлы и система стала рабочей. Я же запомнил эти уроки, надеюсь, на всю жизнь.

как-то захотелось просмотреть абстрактный jpeg из домашнего каталога программой display.

Ну, как обычно, тыкаю

$ display <tab>

И понимаю, что что-то тут не так, и выбирать из 200-300 файлов любой жпег не очень-то удобно.

Роемся в man bash. )

$ display *.jpg<Esc-g> 

(или Alt-g, или Ctrl-x, g - для просто списка без дополнения)

Нажатием Ctrl-x * можо и вовсе вместо табкомплита поместить все имена файлов по маске в командную строку.

Первое, что стоит проверить в этой ситуации - это правильность параметра root= в загрузчике.
Второе - имеется ли /sbin/init в системе вообще.
Все остальное - потом.

(навеяно попытками поставить usplash|uswsusp в Debian Sid, в процессе пробы pm-utils)

Интересный ресурс

Можно просто пооценивать, можно поразглядывать. )

Обычно, если не указывать значение параметра -c, ping посылает icmp echo до тех пор, пока не будет завершен, например, с помощью Ctrl-C:

0):stasikos@zombie:~$ ping ya.ru
PING ya.ru (213.180.204.8) 56(84) bytes of data.
64 bytes from ya.ru (213.180.204.8): icmp_seq=1 ttl=57 time=760 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=2 ttl=57 time=703 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=4 ttl=57 time=2391 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=5 ttl=57 time=1465 ms

--- ya.ru ping statistics ---
6 packets transmitted, 4 received, 33% packet loss, time 5399ms
rtt min/avg/max/mdev = 703.354/1329.923/2391.067/682.176 ms, pipe 3

Но однажды мне захотелось странного. Поставить ping с интервалом поболее, да на долгое время, чтобы оценить этот самый packet loss в больших масштабах. Ну и смотреть статистику, не тыкая каждый раз ctrl-c и не перезапуская его снова.
"Shorter current statistics can be obtained without termination of process with signal SIGQUIT." - гласит man ping. Посему...

0):stasikos@zombie:~$ ping -q -i 2 ya.ru
PING ya.ru (213.180.204.8) 56(84) bytes of data.
(^Z)
[1]+  Stopped                 ping -q -i 2 ya.ru
1):stasikos@zombie:~$ bg %1
[1]+ ping -q -i 2 ya.ru &
1):stasikos@zombie:~$ kill -QUIT %1
6/2 packets, 66% loss, min/avg/ewma/max = 609.963/740.967/839.220/871.972 ms

Опцию q я указал, чтобы строки, которые выводит ping, не мешали работе в шелле, пока ping работает в фоне.

UID - это уникальный в пределах системы идентификатор пользователя. Представляет собой целое число.
Узнать его можно многими способами:

$ id 
uid=1000(stasikos) gid=1000(stasikos) группы=8(mail),20(dialout),24(cdrom),25(floppy),29(audio),44(video),
46(plugdev),1000(stasikos)
s

uid=1000 дает нам полное знание о собственном uid ).

$ id root
uid=0(root) gid=0(root) группы=0(root)

эта же команда дает нам возможность узнать и чей-то еще uid.

UID = `id -u`

В скрипте значение только текущего uid можно получать именно таким способом.
Кроме того, uid хранится в /etc/passwd:

$ getent passwd | grep stasikos
stasikos:x:1000:1000:Stanislav V. Kogut,,,:/home/stasikos:/bin/bash

Для изменения uid пользователя нужно воспользоваться командой usermod:

# usermod -u 1099 test

Но если все-таки uid пользователя в системе изменился вручную через редактирование /etc/passwd, это можно исправить, сделав пользователя владельцем его старых файлов и каталогов, которые ранее принадлежали этому пользователю, станут чужими, поэтому их нужно будет передать ему снова:

# find / -uid $OLD_UID -exec chown $username {} \;

Впрочем, эта команда может спасти и в случае, если пользователь владеет файлами за пределами своего домашнего каталога.
Задать uid при создании пользователя можно, указав ключ --uid для команды adduser.
P.S. А нафига это все? А это так, чтобы посмотреть, часто ли этот вопрос кого-то интересует.