Запуск программы с изменённым окружением

Если нужно выставить (или переопределить) для запускаемой программы какую-нибудь переменную окружения, проще всего сделать так:

$ MYVAR=1 MYOTHERVAR=2 ./myscript.sh args

Но, иногда, такая запись не работает. Например тогда, когда нужно выполнить программу от имени другого пользователя. На помощь приходит /usr/bin/env:

$ sudo su - other_user -c '/usr/bin/env "MYVAR=1" \
 "MYOTHERVAR=2" ./myscript.sh args'

(На самом деле должно записываться в одну строчку.)

Цитата

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

--Brian Kernighan

Git: рассылка уведомлений о коммитах по e-mail

Как настроить рассылку уведомлений о коммитах в центральном гитовом репозитории, в который все пользователи сливают свои изменения?

В гите есть готовый пример хука для этого, post-receive-email.

Документация — в начале файла.

Как устанавливать:

1. Подключаем файл

В документации рекомендуют вызывать этот файл из post-receive хука. Если вы можете найти у себя в системе нужный post-receive-email от гита, и удовлетворены его расположением, так и поступите (не забудьте, что файл должен иметь права на исполнения от имени пользователя, который делает push в репозиторий).

Иначе — тупо замените .git/hooks/post-receive в своём репозитории на post-receive-email. Не забываем про chmod +x и про то, что имя файла должно быть строго post-receive.

2. Настраиваем рассылку

Находясь внутри вашего репозитория выполните команды:

$ git config hooks.mailinglist "<адреса@куда.отправлять.почту, через@запятую>"

$ git config hooks.emailprefix "[Префикс к теме письма] "

$ git config hooks.envelopesender "от@кого.письмо"

Также рекомендую прописать описание проекта в .git/description (обратите внимание, что этот файл — не расшарен между репозиториями).

3. Проверяем

$ ./post-receive refs/heads/master OLD_SHA NEW_SHA

Вместо OLD_SHA и NEW_SHA вставляем два SHA1-хеша коммитов в репозитории ("голова" до имитируемого нами push и после него). Любуемся на текст письма.

Если всё работает, то тестируем отправку (на сервере должен быть настроен sendmail):

$ ./post-receive refs/heads/master OLD_SHA NEW_SHA | sendmail -t -f "$(git config hooks.envelopesender)"

Если письмо пришло, хук настроен.

Второе превью Lua 5.2

Анонс здесь:

http://article.gmane.org/gmane.comp.lang.lua.general/61783

Скачивать отсюда:

http://www.lua.org/work/

Хабрахабр: Что можно ожидать от Луа 5.2?

Запостил статейку.

http://habrahabr.ru/blogs/development/80429/

Как хранить гитовые хуки в гите

Гитовые хуки — довольно важная часть пайплайна разработки. С их помощью контролируется то, что и как коммитится в репозиторий.

Хуки индивидуальны для каждой рабочей копии.

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

Всё просто: нужно заменить .git/hooks на симлинк в соотвествующую папку в рабочей копии.

Решение, правда, не идеальное. Оно требует, чтобы свежая версия хуков жила во всех рабочих ветках. Иначе, по понятным причинам, будут происходить нехорошие вещи.

Первая превью-версия Lua 5.2

Опубликована первая превью-версия Lua 5.2.

Живёт вот здесь:

http://www.lua.org/work/lua-5.2.0-work1.tar.gz

Анонс здесь:

http://article.gmane.org/gmane.comp.lang.lua.general/61229

2010

С Новым Годом!

Ура!