25 августа 1991 года в 20:57:08 GMT некий студент из Хельсинки с адресом torvalds@kruuna.helsinki.fi отправил в конференцию comp.os.minix сообщение под заголовком «What would you like to see most in minix?», в котором рассказал, что пишет бесплатную операционную систему, свободную от кода minix (чисто хобби, не будет такой большой и профессиональной, как gnu), в которой уже вроде работают bash 1.08 и gcc 1.40, но нет переносимости, и вряд ли когда-нибудь она будет работать с чем-то помимо ATшных винчестеров.

От себя: Читая этот блог, вы читаете его с Linux сервера Неплохая бесплатная операционнная система получилась! Что уж говорить про Linux-ы Google …

Долго искал — можно ли как-то приблизиться к сервису, близкому ShellGuard, и нашел максимально хорошее решение — PuTTY Connection Manager. Эта программа делает следующее — она запускает на каждую консоль новое окно PuTTY как процесс, но интегрирует их в одно Windows окно, делая вкладки (Tabs), переключаться между которыми теперь можно через Ctrl + Tab. Работает очень хорошо, но все таки остался неприятный осадок — было бы замечательно, если бы порядок переключения делался в Most Recent порядке (между наиболее недавно использованными табами). Но этого нет. Еще хочется добавить из минусов — очень медленно развивается разработчиками. И хотя можно запросить и проголосовать за какую либо новую фичу, что-то мне подсказывает, увидеть ее потом можно через N-ое количество лет.

Кстати, как ShellGuard, так и PuTTY — работают с SSH ключами. Если вы не используете SSH ключи для авторизации (то есть работаете по старинке — вводя каждый раз пароль), то очень рекомендую это сделать — удобно, быстро и более безопасно! Конечно, сами ключи для авторизации необходимо защитить паролем, но его надо ввести один раз (для ShellGuard — только при первой сессии и для PuTTY вводится при запуске Pageant из состава PuTTY)

Я сам программирую динамические веб сайты (CGI) только на Perl. Никогда не использовал PHP. Это не только потому, что я фанат Perl, но и дань эффективности — под Perl много модулей, много возможностей, и при грамотном подходе сайты на Perl будут работать быстрее PHP — ведь Perl код после компиляции хранится в памяти в виде байт кода (типа «Пи кода» кода в Pascal). А если знаешь Perl, то и разработка может идти гораздо быстрее.

До недавнего времени я использовал технологию Apache + mod_perl + Embperl, а сам внешний WWW сервер имел фронтенд -Apache + mod_accel либо еще лучший вариант — nginx  (оба — реализуют проксирование). Лет 8 назад это было отличным решением, когда я начал использовать эту технологию. Но сейчас она устарела и сложна в использовании.

Сейчас я всем программерам на Perl, пишущим приложения под Web, очень рекомендую обратить внимание на следующие технологии в Perl, которые, несомненно эффективнее и проще, чем вышеуказанная связка:

• PSGI технология, а также ее реализация через модули Plack
• Starman — perl сервер, с режимами pre-fork, контроля количества процессов и многое другое. Вообщем, почти как apache.
• Dancer — отличное решение для реализации своих PSGI приложений, но с более простым программированием.

Сейчас немного подробнее

PSGI — недавно придуманный стандарт для Perl, который реализует простой и понятный программисту подход — вместо написания CGI скриптов и всей этой ваши с передачей параметров серверам и т.п.., очень умный человек (Tatsuhiko Miyagawa) придумал (правда взяз за основу наработки из Python) простой подход — любое приложение (будь то скрипт или группа скриптов)  оформляется в виде обычной perl функции, которая чётко принимает и возвращает определенные параметры: принимает ссылку на хеш, в котором есть и заголовки HTTP, и служебные заголовки (вместо старых в CGI переменных окружения), а возвращает ссылку на массив из трех элементов: HTTP ответ, ссылку на массив заголовков ответа и ссылку на массив данных (HTTP BODY). Просто и со вкусом! Причем, можно возвращать и ссылку на код функции для реализации stream потоков. То есть в PSGI можно реализовать любой вид сервера — простой, отдающий потоковые данные (типа видео, например), либо удерживающее соединение (Comet технология). Но и это не все. Прелесть такой структуры функции PSGI в том, что одна функция может вызывать другую PSGI, но при этом делающее что-то своё. То есть другими словами — стек вызова. Называется это — middleware. А Plack служит клеем — имеет в своем составе сервис функции для формирования такого стека.

И, конечно же, если подумать, нужен сам сервер, который будет принимать TCP соединения, парсить заголовки и формировать хеш для PSGI, вызывать его и отдавать ответ. И таких серверов написано уже много. Один из них — Starman. Он, практически, выполняет те же функции, что выполняла бы связка Apache + mod_perl, только гораздо эффективнее, так как он проще, и нет тех «костылей», которые были приделаны в apache & mod_perl для их функционирования.

А что же делает Dancer? Он называется типом Frameworks в терминологии Plack. Он для сервера Starman работает как PSGI, но вы сами пишите на perl через предоставляемые Dancer-ом функции, которые облегчают вам жизнь. Dancer сам парсит входные данные от Starman, формирует их в удобный вид для обработки в perl и также формирует обратные заголовки и данные. К тому же, Dancer может работать без Starman — он имеет свой простой вебсервер. Также, раз Dancer может работать как PSGI функция, его можно вызывать из под любого сервера Plack типа, а также на нем можно написать свои middleware. Вообщем, тут вам как ваша фантазия и профессионализм подскажет.

Здесь на английском официальная инструкция, как это сделать. Основной смысл — провайдер ставит записи CNAME вместо PTR в обратной зоне (IN-ADDR.ARPA), а вы уже меняете на своем DNS настройки. В примере дан более развернутый пример, когда провайдер описывает записи для целой подзоны, например сетки /27 (32 машины) и указывает NS записи вашего DNS. Можно сделать проще для одного IP — провайдер ставит на вас CNAME вместо PTR (но не NS), CNAME указывает на ваш доменный адрес (на адрес под вашим доменом), для которого вы уже описываете PTR запись. Тем самым, если захотели другое имя для IP, меняете его у себя в DNS и телемаркет…

Если не знаете, зачем это, то знайте: обратное разрешение нужно для более правильной работы e-mail (если у вас есть почтовый сервер — для его IP это лучше сделать ). В противном случае, письма, оправленные через ваш SMTP, могут «отвегаться» большинством почтовых релеев (relay).

1. В компьютерных технологиях, стандартом часового пояса времени является НЕ ЛЕТНЕЕ ВРЕМЯ. Везде, в компьютерных системах, это подчеркивается — есть опция «Летнее время». То есть, если стоит пометка, то время летнее, и к стандартному сдвигу для данной временной зоны добавляется час. То, что приняли в России — это бред. Выходит, что РФ теперь будет жить всегда по «летнему времени». Придется ждать, когда везде в компьютерных системах (включая мобильники) для городов РФ сдвиг будет перенесен на час вперед для всех городов (см. след. пункт)
2. Теперь везде, где есть временные зоны (сотовые телефоны, компьютеры) россиянину надо будет выбирать не только свою зону, но и всегда ставить опцию летнего времени. А если ее нет — то придется всегда вместо своего города в базе зон выбирать другой город, который восточнее на 1 час. В общем, будет бардак. Не надо надеется, что везде эти базы зон будут оперативно обновлены — телефоны не перепрошьют, компы, если и обновятся, то не скоро.
3. Еще один очень неприятный момент: со следующей зимы все в России будут жить с большей разницей во времени с теми странами, где часы переводят. Пример — сейчас Москва зимой в зоне GMT +3 (что значит — для получения московского времени надо ко времени Гринвича — GMT — добавить 3 часа), европейские города — GMT +1. Это значит, что зимой разница между ними — 2 часа. Весной Европа и мы перейдем на летнее, Москва станет GMT +4 (в комп. системах это как «GMT +3″ + летнее время), Европа GMT +2. Разница попрежнему будет составлять два часа. А вот осенью случится то, что мне лично не нравится. Европа станет снова GMT +1, а Москва так и останется GMT +4. Разница времени зимой с Европой будет 3 часа. Я не беру в пример более восточные города РФ, а также города в США — везде разница с ними увеличится на час, чего никогда не было. Получается, что соотечественники за рубежом будут вынуждены звонить своим родственникам в Россию еше раньше, чтобы те не успели лечь спать. Также, это скажется на бизнесе между РФ и Европой. Европейское телевидение станет на всю зиму еще больше отставать по времени (например, те кто смотрит спутниковое — они это почувствуют). Тут еще надо подумать, не будет ли это так же плохо для населения, как то, когда стрелки переводили.

Остался еще неприятный момент, что ПО компьютеров придется дорабатывать и ждать обновлений — сейчас Windows & Unix автоматически переводят время, и без обновлений, осенью масса компьютеров просто некорректно переведет время. Но даже если оператор и вернет время обратно вручную, этого будет мало — придется ставить временной пояс не своего города, иначе система будет некорректно вычислять Гринвическое время, что также приведет к сбоям и проблемам. Вообщем, это будет что-то типо второй проблемы Y2K, только не для всего мира, а для РФ.

Непонятно, чем думали, когда решили весной последний раз перевести часы…

Для решения этой проблемы надо просто напросто добавить строку map archive = no в smb.conf файл. После перезапустить samba: service smb stop & service smb start

В MySQL есть такая особенность для таблиц типа MyISAM — операции изменения таблицы (INSERT/UPDATE/DELETE) имеют более высокий приоритет перед SELECT. Представим себе такую картину: к MySQL поступает сразу несколько запросов  в таком порядке: SELECT (1) -> UPDATE (2) -> SELECT (3) -> SELECT (4). Все эти запросы — от нескольких клиентов (сессий) и все — на работу с одной и той же таблицей (для простоты понимания). Первый SELECT, предположим, занимает 2 сек времени на выполнение. Если бы не было UPDATE, то остальные селекты могли бы исполняться в параллель — таблица ведь не меняется, данные тоже, почему бы не дать другим клиентам тоже выполнить запросы… Но, поскольку, есть UPDATE (то же было бы для случая DELETE/INSERT), MySQL заблокирует таблицу полностью при первом же случае (в нашем примере сразу же после отработки первого SELECT, который поступил раньше UPDATE), т.е. он ждет выполнения первого селекта (2 сек) для блокировки. За эти две секунды никто не может получить доступ к таблице, остальные SELECT будут ждать выполнения UPDATE (вень у него более высокий приоритет пол умолчанию), а UPDATE ждет первого SELECT. Все… Это пипец… Если у вас не загруженный сервак, то вас это беспокоить не будет — никто не будет наступать друг другу на пятки. А если сервак загружен, эту ситуацию можно сравнить с давкой в торговом центре, где ажиотаж, но при этом security решили пропустить без очереди VIP персону…

Какой выход? Оказывается, довольно простой. Один из вариантов — изменить по умолчанию приоритет операций для изменения таблиц (т.е. для UPDATE/INSERT/DELETE) — опция --low-priority-updates при запуске mysqld. Но это слишком глобальный способ, и вряд ли хороший. Я не вдумывался в его смысл, но думаю, раз придумали такой приоритет, то значит это кому то нужно.

Есть способ второй — найти такие узкие места в программе, где есть вместе долгоисполняемые SELECT (например большие JOIN), а также где рядом исполняется INSERT/DELETE/UPDATE на те же таблицы. И вот для тех INSERT/DELETE/UPDATE добавить слово LOW_PRIORITY в запросе. И все! На 99% вы устраните это узкое место и будете удивлены, насколько все пропрет Представим, что будет после. Если встретился долгий SELECT, а поступил также, например UPDATE, но уже с LOW_PRIORITY, а за ним в очереди другие SELECT, то другие SELECT будут исполняться сразу же в параллель вместе с первым длинным по времени, даже пока он не закончился. А уже после будет работать UPDATE и никому не мешать. Вообще, есть больше рекомендаций от самой MySQL.ORG.

Итак, если кратко, то надо сгенерировать закрытый и открытый ключи на стороне, где будем запускать скрипты (назовем такую машину «клиент»), положить открытый ключ туда, куда будем коннектится (назовем его условно «сервер») и настроим, чтобы сессия для такого-то аккаунта Unix запускалась не от Unix пароля, а от ключа (с паролем, но ниже будет показано, как настроить, чтобы вводить его однократно за весь день, например)

1. На стороне клиента генерируем ключ типа DSA:

   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   cd ~/.ssh
   ssh-keygen -t dsa
   Enter passphrase (empty for no passphrase): …
   Enter same passphrase again: …
   chmod go-rwx ~/.ssh/*

   Я рекодмендую обязательно указать пароль. Рекомендуется указывать пароль, который не используется для аккаунта Unix. Если вы не укажите пароль (сделаете пустым), то любой, кому попадет ваш закрытый ключ-файл, сможет зайти на удаленный сервер под вашим аккаунтом без всяких проблем. Конечно, чтобы файл попал к кому либо, надо, чтобы были нарушены права доступа в Unix. Но файл может «утечь» случайно с утилитами синхронизации, бекапа или т.п.. Далее, я расскажу, как настроить, чтобы вы сами в дальнейшем не вводили часто пароль для закрытого ключа.

2. Копируем ключ на сервер:

   scp -p id_dsa.pub remoteuser@remotehost:
   Password: ********

3. На уделенном сервере делаем:

   ssh -l remoteuser remotehost
   Password: ********
   mkdir -p ~/.ssh # Создать директорию, если ее нет
   chmod 700 ~/.ssh
   cat id_dsa.pub >> ~/.ssh/authorized_keys  # Добавление к файлу, если он уже есть
   chmod 600 ~/.ssh/authorized_keys
   mv id_dsa.pub ~/.ssh # Не обязательно, но можно сохранить открытый ключ на всякий случай
   logout

   Теперь, у вас есть закрытый и открытый ключ на вашей клиентской машине, защищенный (или нет) паролем, и открытый ключ на стороне сервера. Серверу достаточно вашего открытого ключа, чтобы вас идентифицировать (условно говоря, сервер каждый раз будет генерировать некий уникальный текст и давать его вашей клиентской машине при открытии сессии, а ваша машина должна будет его подписать с помощью закрытого ключа, передать обратно цифровую подпись серверу, а тот сверит ее для выданного вам же текста. Поскольку подписать может только тот, кто имеет закрытый ключ + пароль к нему, а проверить подпись может тот, что имеет ваш открытый ключ, то идентификация в этом случае гарантирует серверу, что вы — эти именно вы, и Unix пароль в таком случае вообще не нужен и нигде в сессии не передается).

4. Следующий шаг — настройка ssh-agent. Он может нам понадобится, если мы не хотим постоянно вводить пароль для закрытого ключа. Если же вы на шаге 1 указали пустой пароль, то можете пропустить 4 -6 пункты — вам не потребуется демон ssh-agent для кеширования пароля — его попросту нет — он не будет запрашиваться утилитами, использующими протокол ssh, и все эти утилиты могут работать из скриптов прямо на этом этапе.
   Демон ssh-agent висит в памяти и за операциями подписи и криптования к нему обращаются программы ssh & scp (и другие). Этот демон хранит в своей памяти ваш пароль для закрытого ключа определенное время, заданное вами. Это очень удобно, если вы повседневно используете openssh, например, даже для git pull & git push.

   crontab -e

   Вставляем в редакторе в crontab файл:

   @reboot ssh-agent -s | grep -v echo > $HOME/.ssh-agent

   Эти команды говорят крону, что во время ребута системы запустить ssh-agent, а его вывод — переменные среды окружения с настройками записать в файл $HOME/.ssh-agent. Этот файл необходим нам для того, чтобы программы ssh, scp знали, куда коннектится (в них сохраняются пути до Unix сокетов коммуникации с ssh-agent).
   Чтобы нам не ждать перезагрузки, запускаем демон сразу же:

   nohup ssh-agent -s > ~/.ssh-agent

5. Теперь, в ваши скрипты, которые используют ssh & scp, надо добавить такую строку:

   . ~/.ssh-agent

   Также, рекомендую добавить следующие строки в ~/.bashrc (для bash shell-а):

   . $HOME/.ssh-agent
   alias keyon="ssh-add -t 10h"
   alias keyoff='ssh-add -D'
   alias keylist='ssh-add -l'

   Тем самым, при заходе на клиентскую машину ssh сессией, у вас загрузятся настройки для работы с ssh-agent, а также определятся алиасы команд для повседневной работы. Например, выполнив в bash команду «keyon», от вас ssh-add команда потребует ввести пароль для ключа. После ввода он будет еще работать 10 часов. В это время вы можете запускать команды ssh, scp и любые другие, что используют ssh для коннекта на сервер (rsync, git), и все эти команды будут работать без запроса пароля.

6. Второй вариант настройки ssh-agent (если его выбираете, можете пропустить пункты 4 и 5):
   В файле ~/.bash_profile прописываем:

   SSHAGENT=/usr/bin/ssh-agent
   SSHAGENTARGS="-s"
   if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
   eval `$SSHAGENT $SSHAGENTARGS`
   trap "kill $SSH_AGENT_PID" 0
   ssh-add
   fi

   Этими командами вы говорим при логине, если если нет таких-то переменных, запустить ssh-agent, выполнить команды вывода ssh-agent в текущем шеле (eval), а по завершении shell-а пристрелить процесс ssh-agent-а (trap). Здесь также при логине у вас единожды запросится пароль для ключа. Затем он будет в памяти ssh-agent

Подробнее и всесторонне об ssh-agent можете прочитать в статье Mark A. Hershberger

Также рекомендуется к чтению:

1. 20 советов по безопасному использованию сервера OpenSSH
2. OpenSSH Public Key Authentication

Итак, что же это за такая rsync? Это действительно, утилита рекурсивного копирования (копирует все файлы и поддиректории) с одного хоста на другой, или даже внутри одной машины. На этом все ее отличие от, например, утилиты cp заканчивается. И вот тут самое интересное — она при копировании каждый файл или директории, которые копируем, проходит блоками, и отслеживает только изменения блоков в сравнении с уже скопированными блоками. Грубо говоря, она копирует только «дельты» файлов и директорий! Что это значит? Это значит, что второй, третий и так далее запуски этой программы на определенную цель (куда копировать) будут занимать гораздо меньше времени, операций копирования и передачи данных по сети при повторном копировании уже изменившихся файлов. Вот несколько примеров ее использования:

1) Быстрый перенос баз данных (на примере SQL).

Имеем два сервака — один рабочий A, второй Б — куда будем резервировать свои базы данных (там где нет работающего SQL). Тогда для резервирования можно периодически запускать rsync на сервере A, не прекращая работы SQL сервера (назовем это «рабочим резервом»). Но чтобы нам иметь полностью правильные базы в резервной директории сервера Б, нам надо временами останавливать SQL на серваке А, и пока там нет работаюшего SQL, делать повторное копирование (назовем это «фиксированным резервом»). Вот тут то rsync и пригождается! Во время «рабочего резерва» многие файлы успевают устареть, ведь SQL продолжает работать. Во время «фиксированного резерва» копируются только дельты с последнего запуска «рабочего резерва». Если время между этими запусками мало, то дельты копируются очень быстро — на больших базах это может быть не более минуты, например. Для снижения времени простоя, надо просто выполнить повторный «рабочий резерв» прямо перед остановкой MySQL сервера. Плюсы такого способа — минимальный даун по времени, минимум человеческих ошибок, простота. Я не знаю другого способа на данный момент, чтобы сделать быстрый резерв больших баз данных на другую машину, и при этом свести время простоя к минимуму.

Команды (смотрите не перепутайте! Тут все как в теории относительности )
На стороне сервера Б (можно и на стороне А, но тогда надо поменять пути местами), куда копируем, запускаем команды копирования во время «рабочего резерва»

cd
nohup /bin/nice -n 20 ionice -c3 rsync --rsync-path='/bin/nice -n 20 ionice -c3 rsync' -avz --delete IP.ADDRESS.SERVER.A:'/path/to/source/folder/' /path/to/target/folder/

Краткие пояснения (ВАЖНО):
Некоторые утилиты могут отсутствовать, примеры даны для Linux! Здесь nohup — «оторвать» ввод/вывод от терминала. Это нам потребуется, когда мы захотим оставить запущенный «резерв» в фоновом режиме. Сразу мы не можем этого сделать (то есть не ставлю ‘&’ в конце), так как rsync при копировании использует ssh, и раз мы копируем на другой сервак, он запросит у нас пароль (если авторизация через openssh ключи + ssh-agent, то можно и поставить ‘&’, но об этом в другой раз, в другой статье). После ввода пароля уже можно будет нажать Ctrl+Z в shell и затем "%1 &" для запуска в фоновом режиме первой запущенной задачи (см. man bash). Команда nice — выставить приоритет для процессора, а ionice — приоритет для операций при работе с диском — все приоритеты ставяться на понижение, чтобы продолжалась нормальная работа сервера. Опция --delete для rsync — удалять все файлы в целевой директории (от слово «цель», target), которых нет в исходной (source). То есть, после копирования получим полностью равную директорию по содержанию.
Слеш в конце исходной директории (/path/to/source/folder/)  — важная штука! Если в конце слеш — директория рассматривается rsync-ом как комплект директорий и файлов в ней для копирования, а если слеша нет — как один объект, целая директория со своим именем — в обоих случаях копирование рекурсивное, но если из примера убрать слеш в конце первого пути (сделать /path/to/source/folder), то в /path/to/target/folder/ будет создана папка folder и туда скопируется ее содержимое! Почитайте man-ы, если хотите понять, как присутствие или отсутствие слешей в конце директории влияет на ход событий

2) Перенос сайтов.

Способом, описанным выше, также можно переносить и сайты вместе с их базами. Для баз мы используем способ выше, а для переноса контента делаем все то же самое, но при работающем apache. Как и в первом способе, apache мы останавливаем только на несколько минут или секунд, быстро запускаем rsync для «фиксированного резерва», а после окончания запускаем apache снова. После остается сменить только DNS на новый IP адрес и все! Для повышения скорости переноса не забудьте за неделю до переноса выставить часовой TTL в вашем DNS для SOA записи зоны и для всех ее остальных записей. Тогда при смене IP весь трафик на сайт переместится за один час! Но это, как говориться, уже другая история.

Если вы работаете раз от разу в bash, tcsh и других shell-ах, вы можете не знать про следующие, но очень удобные команды, которые облегчать вам жизнь под Unix:

• Ctrl + A — переход в начало текущей строки;
• Ctrl + E — переход в конец текущей строки;
• Стрелка вверх / Стрелка вниз - хождение по history командам соответственно к более старым командам / к более новым (это вы навярняка знаете)
• Ctrl + U — стирает все слева от текущей позиции курсора, то есть чтобы быстро очистить строку, можно сделать Ctrl + E и затем Ctrl + U
• Esc -> d — стирает слово справа (сначала нажимаем Esc, отпускаем, затем ‘d’)
• Tab - формирует законченный вид не до конца набранной команды, файла или директории. Для MySQL -  еще таблицы, имени колонки. Если нет однозначности, то после повторного нажатия Tab выдаются варианты. Очень ускоряет процесс работы в командной строке, если вы не знали про это
• Ctrl + PageDown - переход к самой последней (свежей) команде в history
• Ctrl + PageUp - переход к самой старой (первой) команде history
• Ctrl + R - самая ценная команда для меня — поиск в history. Делается так: нажимаем Ctrl + R, появляется приглашение ввести подстроку поиска ( (reverse-i-search)`’: ), далее мы вводим, например, «mysql» — видим самую последнюю команду shell-а, где встречалось подстрока «mysql». Если она нас не устраивает, то для повтора поиска тут же надо снова нажать Ctrl + R. Каждое нажатие Ctrl + R перемещает нас к более старым командам с подстрокой «mysql», которые мы когда либо исполняли. Если же нас найденная команда устраивает, нажимаем «Стрелка вправо» или «Стрелка влево» и приступаем к редактированию и исполнению команды. Это очень удобная и нужная команда!

Все эти команды — подмножество команд библиотеки readline (man 3 readline). Ее используют и другие программы, например MySQL. Но в MySQL есть то ли баг, то ли так задумано разработчиками. Суть ее в том, что MySQL версий 3.x, например, прекрасно исполнял команду поиска (Ctrl + R), но потом, по каким то причинам, новые релизы — MySQL 4.x & 5.x перестали работать с поиском. Скорее всего, это связано с тем, что раньше MySQL использовал readline библиотеку, но потом разработчики перешли на editline. И последняя перестала работать с поиском. Я долго мучался, пока не нашел решение. Оно следующее:

Создать файл ~/.editrc — конфиг для editline. Там мы пишем следующие строки:

bind "\e[3~" ed-delete-next-char
bind "^R" em-inc-search-prev

После этого в MySQL 4.x & 5.x у нас будет работать Ctrl + R.

Другим решением для MySQL вместо редактирования .editrc будет использовать rlwrap программу (установка в Linux Fedora Core, например, такая: yum install rlwrap) — она «обертывает» stdout запускаемой программы и создает history для вводимых строк (хранит в ~/.commandname_history). У нее есть некоторые недостатки — на ввод паролей она делает echo, то есть пароль будет виден на экране. Можно с помощью опций отключить это, но это не идеально. Зато можно в нее обернуть любую программу, которая даже не имеет history вообще (rlwrap perl -MCPAN -e shell , например). Итак, второе решение для MySQL может быть таким:

alias mysql=’rlwrap -a mysql’

Это ставиться в ~/.bashrc, например. Или вместо алиаса можно просто запустить:

rlwrap -a mysql -uroot -p mysql

Man на rlwrap вы можете найти на сайте разработчика.

Вот такие вот тонкости, которые на 100% облегчат вам работу в Unix.