Префикс у выводимых команд

Можно использовать `@', чтобы подавлять вывод на экран выполняемой команды (вывод самой команды не подавляется)

Это я помню с детства и '@echo', но хотелось бы именно префикс, а не подавление (делать @echo $ command лень, но сойдёт на крайний случай).

Жаль, конечно, что в GNU не принято такие проблемы решать редактированием исходников (да и какой смысл, все равно в этом болоте ничего не найдешь).

Так как все равно по делу мне сказать нечего, то покажу, как эта проблема решалась бы в Plan 9:

Найдем каталог с исходниками mk (так называется местный make):

% cd `{basename -d `{src -n mk}}

Ничего не зная о структуре исходников, пойдем в run.c и найдем там следующий фрагмент:

	shprint(j->r->recipe, e, buf);
	if(!tflag && (nflag || !(j->r->attr&QUIET)))
		Bwrite(&bout, buf->start, (long)strlen(buf->start));

Да, это то, что нам нужно. Если не QUIET (см. rhead в parse.c), то буфер с собранной командой печатается. Осталось пририсовать нужный нам префикс (см. bio(2):

	shprint(j->r->recipe, e, buf);
	if(!tflag && (nflag || !(j->r->attr&QUIET))){
		Bprint(&bout, "@ %s", buf->start);

И пересобрать и установить наш mk:

% mk install

Все, теперь mk печатает с префиксом. Ура!

Если кто-то может описать аналогичную процедуру, но для GNU Make в среде GNU/Linux, мне было бы очень интересно почитать.

Замени SHELL на свой скрипт, и можешь из него хоть человеческим голосом говорить :)

Замени SHELL на свой скрипт, и можешь из него хоть человеческим голосом говорить :)

Гентушники будут в восторге!;-)

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

описать аналогичную процедуру, но для GNU Make в среде GNU/Linux

Буду говорить лишь про Debian GNU/Linux.

$ apt-get source make # получаем исходники
$ cd make-dfsg-3.82/ # Переходим к ним
$ ls # оглядываемся и понимаем что скорее всего нам нужен job.c
$ $EDITOR job.c

В файле ищем функцию «start*» или «run*». Находим start_job_command. Просматриваем код функции на наличие вывода сообщения. Находим комментарий

  /* Print out the command.  If silent, we call `message' with null so it

   message (0, (just_print_flag || (!(flags & COMMANDS_SILENT) && !silent_flag))
	   ? "%s" : (char *) 0, p);

Заменяем «%s» на «@ %s». Дальше

$ dpkg-buildpackage # собираем пакет
$ dpkg -i ../make_3.82-1_i386.deb # и устанавливаем. На этом шаге нужен root

И получаем то же самое что и у тебя.

Жаль, конечно, что в GNU не принято такие проблемы решать редактированием исходников (да и какой смысл, все равно в этом болоте ничего не найдешь).

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

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

Не-а. Так не делают по одной простой причине: ни один вменяемый прогер не станет ставить сборку программы в зависимость от патчей на тулччейн.

P.S. нет, теоретики-фанаты Plan9 к вменяемым прогерам не относятся.

То, что ты натворил, непортабельно совершенно. Пожалуйста, никогда так не делай.

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

Так речь о патчах косметических, а не функциональных. Функциональные патчи в подобных задачах предлагал делать только дедушка Кнут.

а colormake не подойдет?

Так речь о патчах косметических, а не функциональных

Откуда ты знаешь, что именно зависит от этого патча?

Откуда ты знаешь, что именно зависит от этого патча?

То есть ты хочешь сказать, что ТС нужен префикс не для более удобного просмотра глазами, а для того, чтобы потом по префиксу грепать вывод make? Тогда ТС явно что-то делает не правильно.

Спасибо! Очень полезно и наглядно.

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

Но все-таки в мелочах есть неприятности — src(1) из Plan 9 отправит меня именно к исходникам, из которых получился нынешний бинарник, а в Debian, насколько я понимаю, если через полгода я захочу выяснить, какой дебил добавил печать @ перед строчкой рецепта и сделаю apt-get source, то получу «исходный» исходный код, без моих изменений, что несколько менее удобно, но, очевидно, обходимо (наверное, можно ведь и source-пакет как-то собрать вместо со сборкой бинарного).

Безусловно, в общем, что все это можно сделать и не только в Plan 9, и, может быть, даже с известными преимуществами, но вот кажется, что небольшие изменения вроде доступного по умолчанию исходного кода позволили бы пользоваться GNU с гораздо большим комфортом. (Мой прежний тезис про сравнительную развесистость кода, впрочем, остается в силе).

То, что ты натворил, непортабельно совершенно.

В ТЗ я не обнаружил ничего похожего на требования «портабельности». Да и что в данном случае такое требование может означать? Переносимость на другую машину? На другую систему?

Если речь идет про невозможность поделиться столь важным улучшением с остальным миром, то есть ведь теперь git pull requests, которые в Plan 9 появились немного раньше и по-другому называются:

% patch/create mk-recipeprefix anonymous@lor /sys/src/cmd/mk/run.c 
Make mk(1) prefix each recipe line reported with '@ ' for better visibility.
^d

Теперь любой желающий может воспользоваться плодами моего труда, сказав

 % patch/apply mk-recipeprefix 

Вообще очень полезно было бы составить словарик всяких идиом в разных системах, но не низкого уровня (как заменить с помощью sed(1) отсутствующий в Plan 9 head(1)), а более высокого — как выполнить ту или иную системную операцию, причем с объяснениями, что происходит.

Во-первых, польза от него будет непосредственной — особенно если там будет столбец про Debian, а то у меня просто руки опускаются всякий раз, когда нужно сделать что-то совершенно очевидное, и надо гуглить непонятно что, копипастя потом непонятные магические строчки. Естественно, можно почитать руководство, но как правило это плохое решение как по временным затратам (обычно необходимость что-то сделать не в «своей» системе возникает не в самое свободное время), так и из-за того, что оное руководство все, как правило, написано в терминологии, принятой в описываемой системе, и эти-то культурные различия как правило и есть самое неприятное.

Речь о том, что это улучшение есть только на твоей машине и работает корректно только для твоего mkfile (остальные не требовали этой принудительной фичи).

git

В 9front есть hg: http://man.aiju.de/1/hg
---
А так да, с исходниками всё очень удобно сделано.

(дописать что-то сил не хватило) :-)

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

восторг выразится патчем makefile в files

Речь о том, что это улучшение есть только на твоей машине

Нет, я показал, как его опубликовать (будет в каталоге патчей)

и работает корректно только для твоего mkfile (остальные не требовали этой принудительной фичи).

Так как это чисто эстетическое украшательство, то «корректность» его вовсе не определена. На других mkfile, очевидно, все будет работать точно так же, как и на моем.

В 9front есть hg: http://man.aiju.de/1/hg

Есть. Но пока основным механизмом распространения является replica, sources и, в частности, patch. Хотя я не очень слежу за 9front. Может, оно уже и обновляется через hg?

Может, оно уже и обновляется через hg?

Именно так: http://code.google.com/p/plan9front/source/browse/rc/bin/sysupdate

На других mkfile, очевидно, все будет работать точно так же, как и на моем.

Хотя там это совершенно и не планировалось. В этом-то и проблема.
---
А главное то, что там есть terminus и dejavu, так что глазам больше не нужно кровоточить от жуткой lucida, что была раньше.
И да, ссылок:
http://code.google.com/p/ports2plan9/ (у них там работы по портированию Netsurf?)
http://code.google.com/p/nix-os/

а colormake не подойдет?

Укажу как вариант, спасибо.