cramp пишет:
Многое из coreutils собрано под win32 (unxutils). Под виндой вполне
работает. (и grep, и sed, и awk ). Я пользуюсь ;)
А что шыбко критичного не умеет cmd.exe?
Ну, к примеру, создайте из cmd каталог имя которого будет текущей датой.
D:\tempFOR /F usebackq delims==
Многое из coreutils собрано под win32 (unxutils). Под виндой вполне
работает. (и grep, и sed, и awk ). Я пользуюсь ;)
А что шыбко критичного не умеет cmd.exe?
Ну, к примеру, создайте из cmd каталог имя которого будет текущей датой.
D:\tempFOR /F usebackq delims== %i IN (`date /t`) DO mkdir
,-[Mon, Oct 06, 2008 at 12:11 +0300, Игорь Чумак:]
Посыпаю голову пеплом ;)
Но получаем на самом деле 2 папки: Пн и 06.10.2008
Потомушто
echo %date%
Пн 06.10.2008
Похоже, что это малодокументированная функция cmd.exe (переменная %date%
по команде set не выводится)
--
у
On Wed, 01 Oct 2008 10:43:21 +0400
Artem Chuprina wrote:
GF Не драки ради, а токмо для самообразования.
GF Любопытно, как _негнутые_ утилиты обработают, скажем, файл с
GF именем -f Как справится гнутая (команда ключи -- файлы)
GF мне понятно, а какие есть инструменты для этого в
Artem Chuprina пишет:
Andrey Lyubimets - debian-russian@lists.debian.org @ Thu, 02 Oct 2008
12:49:43 +0700:
DEO а на кой фиг надо два MTA на одном хосте?
Я знаю по крайней мере три паттерна работы в такой позе - существенно
разные требования на прием и раздачу, существенно разные
Hello!
В сообщении от Friday 03 October 2008 01:21:47 Artem Chuprina написал(а):
GF Поднять в тестовом OVZ контейнере?
В Debian нет пригодного для этого ядра.
Предлагается делать в Debian все же подразумевает по умолчанию
средствами, имеющимися в дистрибутиве...
А как насчет virtualbox?
AC Да, именно. Это ваши проблемы. Если вы используете расширение,
AC идущее вразрез со стандартным поведением, будьте готовы к тому, что
AC инструментарий, расчитанный на нормальный sh с вашим zsh в этих
AC режимах работать не будет. Напишите себе zshquote и да пребудет с
AC вам ктулху.
Aleksey Cheusov wrote:
GF Поднять в тестовом OVZ контейнере?
В Debian нет пригодного для этого ядра.
Предлагается делать в Debian все же подразумевает по умолчанию
средствами, имеющимися в дистрибутиве...
А как насчет virtualbox? Привлекает возможность перетащить образ на
GF Поднять в тестовом OVZ контейнере?
В Debian нет пригодного для этого ядра.
Предлагается делать в Debian все же подразумевает по умолчанию
средствами, имеющимися в дистрибутиве...
А как насчет virtualbox? Привлекает возможность перетащить образ на любую
машину, и не только под
panic, это уж совсем ниже плинтуса. Ядро 2.4.27. Sarge, конечно,
старый, но официально поддерживается, .deb-ка лежит на скачку.
Sarge уже официально не поддерживается, ЕМНИП.
Я не про Debian а про SUN.
http://virtualbox.org/wiki/Linux_Downloads
--
Best regards, Aleksey Cheusov.
--
Andrey Lyubimets - debian-russian@lists.debian.org @ Fri, 03 Oct 2008
16:01:41 +0700:
Ну вот, собственно, один ставят на релеинг, за ним другой на
обработку локальной почты. Или один на обработку входящих
соединений, другой - на контент-фильтрацию. Или один на разгребание
очереди на
Aleksey Cheusov - debian-russian@lists.debian.org @ Fri, 03 Oct 2008 15:16:15
+0300:
Оно и само не исполняет что попало как попало. by design.
AC Выше было доказано обратное по крайней мере для perl-а.
AC Как раз таки by design небезопастная конструкция system
AC в перле есть.
В
В отличие от sh, который by design как раз исполняет.
AC Выше было показано, что при неаккуратном программировании на perl
AC дыра имеет место быть. Также выше было показано, что при аккуратном
AC программировании не shell дыра таки успешно заклепывается.
AC Следовательно. By design
Artem Chuprina пишет:
DEO а на кой фиг надо два MTA на одном хосте?
Я знаю по крайней мере три паттерна работы в такой позе - существенно
разные требования на прием и раздачу, существенно разные требования на
релеинг и прием себе, и этап смены MTA.
Расскажи поподробнее, а то я всю голову
Aleksey Cheusov - debian-russian@lists.debian.org @ Wed, 01 Oct 2008 18:50:04
+0300:
Я сказал СПИСКОВУЮ форму system.
AC Я это прекрасно понял. См. ниже.
Сравните результаты
$filename='innocentpic.jpg; echo Ha-Ha, you are hacked!';
system display, $filename;
и
system display
Andrey Lyubimets - debian-russian@lists.debian.org @ Thu, 02 Oct 2008
12:49:43 +0700:
DEO а на кой фиг надо два MTA на одном хосте?
Я знаю по крайней мере три паттерна работы в такой позе - существенно
разные требования на прием и раздачу, существенно разные требования на
релеинг и
Hello!
В сообщении от Thursday 02 October 2008 08:29:22 Victor Wagner написал(а):
Появившуюся возможность подстановки списков. В смысле подставить
n-элементный список в команду не как один параметр, а как n,
БЕЗ лишнего уровня evaluation для всего остального.
А как это делается?
AC Сравните результаты:
AC filename='innocentpic.jpg; echo Ha-Ha, you are hacked!'
AC display $filename
AC и
AC display $filename
AC Аналогично с eval-ом.
AC cmd=display \`shquote '$filename'`\
AC eval $cmd
shquote: command not found
Я подозреваю, что это тоже
Aleksey Cheusov - debian-russian@lists.debian.org @ Thu, 02 Oct 2008 12:22:41
+0300:
AC Сравните результаты:
AC filename='innocentpic.jpg; echo Ha-Ha, you are hacked!'
AC display $filename
AC и
AC display $filename
AC Аналогично с eval-ом.
AC cmd=display \`shquote
AC Да переносимость очевидна. shquote - это open source, 2-closure BSD
AC license. Если у вас ее нет, это сами знаете чьи проблемы.
По этой логике переносима любая виндовая программа - эмулятор же есть,
поставить можно...
Не надо передергивать. Если мне нужна программа X, которая требует
Aleksey Cheusov - debian-russian@lists.debian.org @ Thu, 02 Oct 2008 15:58:58
+0300:
AC Да переносимость очевидна. shquote - это open source, 2-closure BSD
AC license. Если у вас ее нет, это сами знаете чьи проблемы.
По этой логике переносима любая виндовая программа - эмулятор же есть,
Я правильно понимаю, что shquote рассчитана на квотинг только BSD'шного
шелла?
AC Нет в природе никакого BSD-шного шела. У всех *BSD шелы разные.
AC Квотинг же для всех шелов одинаковый. Или докажи мне обратное.
Доказываю. man zshoptions
/EXTENDED_GLOB
У тебя сомнения на счет того,
Aleksey Cheusov - debian-russian@lists.debian.org @ Thu, 02 Oct 2008 17:15:12
+0300:
Я правильно понимаю, что shquote рассчитана на квотинг только BSD'шного
шелла?
AC Нет в природе никакого BSD-шного шела. У всех *BSD шелы разные.
AC Квотинг же для всех шелов одинаковый. Или докажи мне
Hello Artem Chuprina!
On Thu, 02 Oct 2008 12:07:32 +0400 you wrote:
Реальная. Перехожу с postfix на exim. У поцфикса есть ограничения, в
которые я уткнулся, в exim с ними вроде проще. Система не
тривиальная, там и SA, и антивирус, и релеинг в разных позах, включая
UUCP. Как это делают
Artem Chuprina wrote:
Grigory Fateyev - debian-russian@lists.debian.org @ Thu, 2 Oct 2008
20:06:56 +0400:
[snip]
GF Поднять в тестовом OVZ контейнере?
В Debian нет пригодного для этого ядра.
Эээ... а зачем тогда -openvz ядро собрали в Debian?
--
Eugene V. Lyubimkin aka JackYF, Ukrainian
Grigory Fateyev - debian-russian@lists.debian.org @ Thu, 2 Oct 2008 20:06:56
+0400:
Реальная. Перехожу с postfix на exim. У поцфикса есть ограничения, в
которые я уткнулся, в exim с ними вроде проще. Система не
тривиальная, там и SA, и антивирус, и релеинг в разных позах, включая
Eugene V. Lyubimkin - debian-russian@lists.debian.org @ Fri, 03 Oct 2008
00:39:36 +0300:
GF Поднять в тестовом OVZ контейнере?
В Debian нет пригодного для этого ядра.
EVL Эээ... а зачем тогда -openvz ядро собрали в Debian?
Вот когда выйдет тот дистрибутив, в котором его собрали -
On Mon, Sep 29, 2008 at 11:26:34AM +0400, Grey Fenrir wrote:
Не драки ради, а токмо для самообразования.
Любопытно, как _негнутые_ утилиты обработают, скажем, файл с именем -f
Как справится гнутая (команда ключи -- файлы) мне понятно, а
какие есть инструменты для этого в стандарте?
Точно
On 2008.09.29 at 11:26:34 +0400, Grey Fenrir wrote:
Не драки ради, а токмо для самообразования.
Любопытно, как _негнутые_ утилиты обработают, скажем, файл с именем -f
Любая утилита прекрасно поймет что ./-f - это имя файла, а не опция.
Рекомендую этот прием запомнить и им пользоваться.
--
Alexey Pechnikov - debian-russian@lists.debian.org @ Tue, 30 Sep 2008
18:10:28 +0400:
AP P.S. А нет ли у вас ссылочки на грамотное руководство по созданию
AP make-файлов, не привязанных к шеллу? Хотелось бы понять, есть ли в
AP этом смысл или полученные мэйкфайлы непригодны на практике.
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Tue, 30 Sep 2008
20:22:41 +0400:
DEO а если говорить о make, то по этой аналогии получится и sh
DEO рекурсивный и тикль и perl и питон и тд итп
Не вопрос. Вопрос в том, что для make это harmful, а для sh, тикля,
перла и питона - нет.
Grey Fenrir - debian-russian@lists.debian.org @ Mon, 29 Sep 2008 11:26:34
+0400:
AC Почему не может? Может. Первый не-опциональный аргумент
AC командной строки заканчивает список опций.
DEO так это и растет от того что НЕ может
Нет. Это растет из того, что так специфицировано.
Aleksey Cheusov - debian-russian@lists.debian.org @ Tue, 30 Sep 2008 16:42:56
+0300:
Recursive Make Considered Harmful --- это в особенности раздражает).
Пока останусь при своём мнении: майк надо уметь
готовить. Хотя SCons надо будет попробовать...
http://makepp.sourceforge.net/
Dmitry Fedorov - Debian-russian List @ Tue, 30 Sep 2008 21:23:50 +0700:
В сообщении от Tuesday 30 September 2008 15:25:30 Dmitry Fedorov написал(а):
http://makepp.sourceforge.net/
Еще один язык программирования?
DF Да. И? Make тоже язык программирования.
DF Причём. rule-based expert
AC а если говорить о make, то по этой аналогии получится и sh
AC рекурсивный и тикль и perl и питон и тд итп
AC Не вопрос. Вопрос в том, что для make это harmful, а для sh, тикля,
AC перла и питона - нет.
необосновано (если рекурсией называть то что вы называете)
--
... mpd is off
. ''`.
Я думаю, вы выдаете желаемое за действительное. Я лично считаю вызов
внешнего шела гораздо более правильной практикой по сравнению с
изобретением собственных недоязыков программирования.
А вызвать внешний shell ничем не хуже, чем дернуть встроенный
интерпретатор java script, lua,
ACPROG = myprog
ACSRCS = file1.c file2.c
AC.include bsd.prog.mk
AC И ведь оно уже все умеет.
Так ведь оно само кем-то написано? Так вот, оно и есть сложный
мейкфайл.
Да. Это внешняя библиотека, которую переихобретают куча велосипедистов
вместо того, чтобы просто
1 октября 2008 г. 16:20 пользователь Aleksey Cheusov написал:
AC И ведь оно уже все умеет.
Хм. Бывший начальник рассказал. Экспертиза изобретения. Изобретатель
изобрёл установку фотоэлемента на ж/д локомотив. Он же всё видит! А
дальше уже ваше дело.
Да. Это внешняя библиотека, которую
Hello!
если то же самое можно делать на хорошо известном и используемом
ежедневно языке программирования общего назначения
Вот именно, что нельзя.
(и не таскать кучу зависимостей при этом)?
Нежелательные зависимости - это как раз таки многотонные интерпретаторы
perl/python/tcl/ruby с
On 2008.10.01 at 12:20:17 +0300, Aleksey Cheusov wrote:
Поскольку, опять же, никаких чудес.
Твоих проблем/задач не решает, да. Рекурсия там в полный рост -
bsd.subdir.mk. Автозависимостей для внутренностей .c/.cpp не доставляет.
Но эти проблемы меня беспокоят гораздо меньше, чем навозная
On 2008.10.01 at 12:20:17 +0300, Aleksey Cheusov wrote:
Поскольку, опять же, никаких чудес.
Твоих проблем/задач не решает, да. Рекурсия там в полный рост -
bsd.subdir.mk. Автозависимостей для внутренностей .c/.cpp не доставляет.
Но эти проблемы меня беспокоят гораздо меньше, чем
Да. Это внешняя библиотека, которую переихобретают куча велосипедистов
вместо того, чтобы просто воспользоваться.
Для того, чтобы ею воспользоваться, она должна быть оформлена как
отдельная библиотека и вне контекста fbsd,
иначе она частный велосипед только для бсдишников.
NetBSD-шники
1 октября 2008 г. 18:09 пользователь Aleksey Cheusov написал:
А во вторых, включение файлов в проект автоматически - по маске - это
ВЕСЬМА спорный момент. Это небезопастно. Вы же не добавляете
на CVS файлы по маске просто потому, что там присутствуют. Нет, вы требуете
'cvs add' - и это
Нежелательные зависимости - это как раз таки многотонные интерпретаторы
perl/python/tcl/ruby с многотонными же библиотеками.
$ ls -l /usr/lib/libtcl8.4.so.0
-rw-r--r-- 1 root root 733796 Май 1 12:17 /usr/lib/libtcl8.4.so.0
Вас пугают 700 килобайт?
Я не специалист по безопастности, но я
Aleksey Cheusov - Debian-Russian2 @ Wed, 01 Oct 2008 14:30:31 +0300:
Нежелательные зависимости - это как раз таки многотонные интерпретаторы
perl/python/tcl/ruby с многотонными же библиотеками.
$ ls -l /usr/lib/libtcl8.4.so.0
-rw-r--r-- 1 root root 733796 Май 1 12:17
А во вторых, включение файлов в проект автоматически - по маске - это
ВЕСЬМА спорный момент. Это небезопастно. Вы же не добавляете
на CVS файлы по маске просто потому, что там присутствуют. Нет, вы требуете
'cvs add' - и это правильно, так и должно быть.
Это не make-ово дело - за
1 октября 2008 г. 18:59 пользователь Aleksey Cheusov написал:
Я что-то не пойму. Что плохого в том, что файлы, из которых строится
exe файл или библиотека ЯВНО перчислены в Makefile-е. Так и должно
быть. Это норма.
Нет. Это привычка.
PROG= paexec
SRCS= paexec.c wrappers.c
AC Связь между размером исходного кода и
AC безопастностью прямая. Если уж выбирать что-то более мощное по
AC сравнению с shell-ом, я бы выбрал LUA или Java Script.
AC Но никак не TCL и тем более не python.
Если речь идет о безопасности, то начинать надо с выкидывания sh.
Вызов внешней
DF Я что-то не пойму. Что плохого в том, что файлы, из которых строится
DF exe файл или библиотека ЯВНО перчислены в Makefile-е. Так и должно
DF быть. Это норма.
DF Нет. Это привычка.
DF PROG= paexec
DF SRCS= paexec.c wrappers.c nonblock_helpers.c
DF .include bsd.prog.mk
DF
Dmitry Fedorov wrote:
1 октября 2008 г. 18:59 пользователь Aleksey Cheusov написал:
Я что-то не пойму. Что плохого в том, что файлы, из которых строится
exe файл или библиотека ЯВНО перчислены в Makefile-е. Так и должно
быть. Это норма.
Нет. Это привычка.
PROG= paexec
SRCS=
1 октября 2008 г. 19:37 пользователь Eugene V. Lyubimkin написал:
Меньший автоматизм.
Для добавления типичного файла в проект мне достаточно добавить его в CVS.
Вам же ещё нужно изменить ваш makefile - ручная работа.
Гм, а если у Вас лежат файлы в каталоге не под контролем версий, а
Это ваша
1 октября 2008 г. 19:23 пользователь Dmitry E. Oboukhov написал:
SRC = $(wildcard *.c)
и забыли про редактирование
Вы невнимательны.
У меня так и я спорю с теми, у кого не так.
DF SRC = $(wildcard *.c)
DF и забыли про редактирование
DF Вы невнимательны.
DF У меня так и я спорю с теми, у кого не так.
ах, сорри я вклинился не прочитав контекст :)
ну считаем что нас уже двое :)
--
... mpd is off
. ''`. Dmitry E. Oboukhov
: :’ : email:
Aleksey Cheusov - debian-russian@lists.debian.org @ Wed, 01 Oct 2008 15:22:46
+0300:
AC Связь между размером исходного кода и безопастностью прямая. Если
AC уж выбирать что-то более мощное по сравнению с shell-ом, я бы
AC выбрал LUA или Java Script. Но никак не TCL и тем более не
AC
DF Вы страдаете, глядя на изобретателей велосипедов?
DF А я - на руками выписанные имена файлов, иногда - 2-3 раза.
точно точно
на лоре обсуждали blockout2
так там makefile выглядел так:
SRC := a.c b.c c.c d.c e.c \
и так пол экрана перечисление сишный файлов, а ниже
OBJ := a.o b.o ...
и еще
1 октября 2008 г. 18:59 пользователь Aleksey Cheusov написал:
Я что-то не пойму. Что плохого в том, что файлы, из которых строится
exe файл или библиотека ЯВНО перчислены в Makefile-е. Так и должно
быть. Это норма.
Нет. Это привычка.
Покажите мне _хотя бы одну_ систему сборки (можно
AC А смысл решать на получившемся винегрете задачи, которые решает awk?
AC Если их на авке решать сложно, вон для желающих лаконичности есть perl,
AC а для желающих ясности - tcl.
лаконичность и ясность это разве не две стороны одного и того же?
--
... mpd is off
. ''`.
AC Я что-то не пойму. Что плохого в том, что файлы, из которых строится
AC exe файл или библиотека ЯВНО перчислены в Makefile-е. Так и должно
AC быть. Это норма.
AC Нет. Это привычка.
AC Покажите мне _хотя бы одну_ систему сборки (можно даже IDE), где был
AC бы реализован такой вот автоматизм.
Я могу представить другие поводы выкинуть perl из базовой системы.
Размер, например. Но выкинуть perl _по соображениям безопасности_ и
оставить при этом sh - это, извините, идиотизм.
Читай соответствующие списки рассылки.
А Java Script безопасен только в песочнице. Но в песочнице он
On 2008.10.01 at 14:59:33 +0300, Aleksey Cheusov wrote:
А во вторых, включение файлов в проект автоматически - по маске - это
ВЕСЬМА спорный момент. Это небезопастно. Вы же не добавляете
на CVS файлы по маске просто потому, что там присутствуют. Нет, вы
требуете
'cvs add' - и это
AC А смысл решать на получившемся винегрете задачи, которые решает awk?
AC Если их на авке решать сложно, вон для желающих лаконичности есть perl,
AC а для желающих ясности - tcl.
лаконичность и ясность это разве не две стороны одного и того же?
Нет. есть один волшебный пример - притча во
On 2008.10.01 at 15:22:46 +0300, Aleksey Cheusov wrote:
AC Связь между размером исходного кода и
AC безопастностью прямая. Если уж выбирать что-то более мощное по
AC сравнению с shell-ом, я бы выбрал LUA или Java Script.
AC Но никак не TCL и тем более не python.
Если речь идет о
OBJ := a.o b.o ...
и еще пол экрана
Вот за это бить нужно. Палкой. Больно. И долго.
--
Best regards, Aleksey Cheusov.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On 2008.10.01 at 16:43:38 +0400, Artem Chuprina wrote:
Безопасность JS базируется на том, что у него нет средств доступа к
системе. Но если у него нет средств доступа к системе, он не сможет
этой системой рулить.
Вообще-то это не совсем так. Оно все же несколько более типизировано,
чем
AC OBJ := a.o b.o ...
AC и еще пол экрана
AC Вот за это бить нужно. Палкой. Больно. И долго.
самое интересное что когда я отправил патч автор его не принял
написал что ему так больше нравится, поскольку более управляемо
(дословно) :(
--
... mpd is off
. ''`. Dmitry
Если речь идет о безопасности, то начинать надо с выкидывания sh.
Вызов внешней утилы не является дырой в безопастности.
По крайней мере речь _сейчас_ не об этом, контект не тот.
Дырой в безопасности является строковая подстановка с неявным
репарсингом после неё. Чуть автор скрипта на
On 2008.10.01 at 17:34:46 +0300, Aleksey Cheusov wrote:
Если речь идет о безопасности, то начинать надо с выкидывания sh.
Вызов внешней утилы не является дырой в безопастности.
По крайней мере речь _сейчас_ не об этом, контект не тот.
Дырой в безопасности является строковая
On 2008.10.01 at 17:57:01 +0300, Aleksey Cheusov wrote:
любом скриптовом языке. Ни в tcl ни в perl разыменование переменной не
смотрит, пуста строка, или нет. И проблема, как следствие та же.
Вопрос не в том, пуста строка или нет, а в том, будет ли она передана
в выполняемую внешнюю
Я сказал СПИСКОВУЮ форму system.
Я это прекрасно понял. См. ниже.
Сравните результаты
$filename='innocentpic.jpg; echo Ha-Ha, you are hacked!';
system display, $filename;
и
system display $filename;
Сравните результаты:
filename='innocentpic.jpg; echo Ha-Ha, you are hacked!'
display
Hello!
В сообщении от Wednesday 01 October 2008 19:27:28 Victor Wagner написал(а):
Там надо соблюдать три (ну в 8.5 четыре) математически строгих правила.
А что в 8.5 нужно дополнительно учесть? А то я еще не смотрел его...
Best regards, Alexey.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
On 2008.10.01 at 23:11:12 +0400, Alexey Pechnikov wrote:
Hello!
В сообщении от Wednesday 01 October 2008 19:27:28 Victor Wagner написал(а):
Там надо соблюдать три (ну в 8.5 четыре) математически строгих правила.
А что в 8.5 нужно дополнительно учесть? А то я еще не смотрел его...
Hello!
В сообщении от Wednesday 01 October 2008 23:42:18 Victor Wagner написал(а):
А что в 8.5 нужно дополнительно учесть? А то я еще не смотрел его...
Появившуюся возможность подстановки списков. В смысле подставить
n-элементный список в команду не как один параметр, а как n,
БЕЗ лишнего
On 2008.10.02 at 00:06:30 +0400, Alexey Pechnikov wrote:
Hello!
В сообщении от Wednesday 01 October 2008 23:42:18 Victor Wagner написал(а):
А что в 8.5 нужно дополнительно учесть? А то я еще не смотрел его...
Появившуюся возможность подстановки списков. В смысле подставить
On Sat, 27 Sep 2008, Andrey Kiselev wrote:
Форматирование безусловно раздражает. Раздражает зависимость от shell'а.
На самом деле, много чего ещё раздражает (например, рекомендую почитать
Recursive Make Considered Harmful --- это в особенности раздражает).
Кроме этого, как и в случае с
30 сентября 2008 г. 15:19 пользователь yuri.nefedov написал:
On Sat, 27 Sep 2008, Andrey Kiselev wrote:
Recursive Make Considered Harmful --- это в особенности раздражает).
Пока останусь при своём мнении: майк надо уметь
готовить. Хотя SCons надо будет попробовать...
Dmitry Fedorov wrote:
30 сентября 2008 г. 15:19 пользователь yuri.nefedov написал:
On Sat, 27 Sep 2008, Andrey Kiselev wrote:
Recursive Make Considered Harmful --- это в особенности раздражает).
Пока останусь при своём мнении: майк надо уметь
готовить. Хотя SCons надо будет попробовать...
[EMAIL PROTECTED] - debian-russian@lists.debian.org @ Tue, 30 Sep 2008
12:19:34 +0400 (MSD):
Форматирование безусловно раздражает. Раздражает зависимость от shell'а.
На самом деле, много чего ещё раздражает (например, рекомендую почитать
Recursive Make Considered Harmful --- это в
On Mon, Sep 29, 2008 at 07:03:32PM +0300, Dmitry Nezhevenko wrote:
Как раз в общем случае --- да, а Вы привели случай частный.
У каждого свое понятие общего и частного случаев.
Да ничего подобного. Общий случай как раз указан в документация на make
и я его уже цитировал:
Command execution
Hello!
В сообщении от Monday 29 September 2008 10:29:05 Artem Chuprina написал(а):
Кстати, открой для себя xtail. tail, вообще-то, не для того
предназначен...
Прелесть какая. Есть все, чего мне не хватало в tail.
Best regards, Alexey.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Eugene V. Lyubimkin - debian-russian@lists.debian.org @ Tue, 30 Sep 2008
12:12:02 +0300:
Recursive Make Considered Harmful --- это в особенности раздражает).
Пока останусь при своём мнении: майк надо уметь
готовить. Хотя SCons надо будет попробовать...
30 сентября 2008 г. 16:12 пользователь Eugene V. Lyubimkin написал:
http://makepp.sourceforge.net/
Не увидел, чем оно лучше, чем make для написания make-файлов.
1. Возможность написания make-файлов без рекурсивного вызова make
(каковой считать вредным) для подкаталогов с собственными
DF http://makepp.sourceforge.net/
DF Не увидел, чем оно лучше, чем make для написания make-файлов.
DF 1. Возможность написания make-файлов без рекурсивного вызова make
DF (каковой считать вредным) для подкаталогов с собственными makepp-файлами.
кстати ковыряясь с многими deb-пакетами натыкался на
On Sat, Sep 27, 2008 at 09:11:39PM +0400, Andrey Kiselev wrote:
On Fri, Sep 26, 2008 at 07:14:05PM +0400, Dmitry E. Oboukhov wrote:
назови платформу где не работает make?
Любая, на которой не работает shell.
Это Ваши слова?
Вы все еще продолжаете утверждать, что make (кстати какой
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Tue, 30 Sep 2008
15:50:27 +0400:
DF http://makepp.sourceforge.net/
DF Не увидел, чем оно лучше, чем make для написания make-файлов.
DF 1. Возможность написания make-файлов без рекурсивного вызова make
DF (каковой считать вредным) для
30 сентября 2008 г. 18:50 пользователь Dmitry E. Oboukhov написал:
DF http://makepp.sourceforge.net/
кстати ковыряясь с многими deb-пакетами натыкался на рекурсии в make
в 100% случаев введением дополнительных целей или зависимостей рекурсии
отлично убирались
может кто-то показать мне
AC Но вообще мне довольно сложно себе представить, как ты без рекурсивного
AC вызова make одним лишь введением дополнительных целей или зависимостей
AC собираешь проект, расположенный по нескольким директориям, где у каждой
AC директории свой makefile.
вызов внешнего makefile это отнюдь не
30 сентября 2008 г. 19:49 пользователь Dmitry E. Oboukhov написал:
рекурсивного вызова make
вызов внешнего makefile это отнюдь не рекурсивный вызов
Вызывается точно такая же утилита make с другим makefile.
в энциклопедию, читать определение слова рекурсия
В данном контексте (читать
Eugene V. Lyubimkin - debian-russian@lists.debian.org @ Tue, 30 Sep 2008
12:12:02 +0300:
Recursive Make Considered Harmful --- это в особенности раздражает).
Пока останусь при своём мнении: майк надо уметь
готовить. Хотя SCons надо будет попробовать...
30 сентября 2008 г. 20:42 пользователь Aleksey Cheusov написал:
А зачем, пардон, писать сложные Makefile-ы?
Для сложных задач.
А любая задача - не такая уж простая.
Надо писать простые.
Ну можно ли проще?
PROG = myprog
SRCS = file1.c file2.c
.include bsd.prog.mk
Можно:
PROG_NAME
Hello!
В сообщении от Tuesday 30 September 2008 16:00:34 Dmitry Nezhevenko
написал(а):
Это лишь говорит о том, что make для некоторой части
команд (в которых используется синтаксис шелла) шелл нужен. В то же
время GNU make умеет в большей части случаев обходиться без шелла. И ни
кто не
Hello!
В сообщении от Tuesday 30 September 2008 15:25:30 Dmitry Fedorov написал(а):
http://makepp.sourceforge.net/
Не увидел, чем оно лучше, чем make для написания make-файлов.
1. Возможность написания make-файлов без рекурсивного вызова make
(каковой считать вредным) для подкаталогов с
30 сентября 2008 г. 21:12 пользователь Alexey Pechnikov написал:
В сообщении от Tuesday 30 September 2008 15:25:30 Dmitry Fedorov написал(а):
http://makepp.sourceforge.net/
Еще один язык программирования?
Да. И? Make тоже язык программирования.
Причём. rule-based expert system :)
Все-таки
On Tue, Sep 30, 2008 at 06:10:28PM +0400, Alexey Pechnikov wrote:
В сообщении от Tuesday 30 September 2008 16:00:34 Dmitry Nezhevenko
написал(а):
Это лишь говорит о том, что make для некоторой части
команд (в которых используется синтаксис шелла) шелл нужен. В то же
время GNU make умеет в
On Tue, Sep 30, 2008 at 03:00:34PM +0300, Dmitry Nezhevenko wrote:
назови платформу где не работает make?
Любая, на которой не работает shell.
Это Ваши слова?
Вы все еще продолжаете утверждать, что make (кстати какой make? GNU?)
не работает на платформах, где нет шелла? Несмотря на
может кто-то показать мне make-задачу/случай нерешабельный без
рекурсивного перевызова того же make?
Оно решабельно без рекурсии, но я не хочу решать это таким способом.
И я что-то склоняюсь к тому, что рекурсия не так плоха для типичных
проектов.
0. Мои makefiles гладкие, все общие
On Tue, Sep 30, 2008 at 05:30:01PM +0300, Dmitry Nezhevenko wrote:
P.S. А нет ли у вас ссылочки на грамотное руководство по созданию
make-файлов, не привязанных к шеллу? Хотелось бы понять, есть ли в
этом смысл или полученные мэйкфайлы непригодны на практике.
Нету. В качестве начала могу
DF рекурсивного вызова make
DF вызов внешнего makefile это отнюдь не рекурсивный вызов
DF Вызывается точно такая же утилита make с другим makefile.
это не рекурсия, это новый процесс.
от любого другого компилятора не отличается ничем
новый процесс make - совершенно независимый, переменные
А любая задача - не такая уж простая.
Вот именно в этом есть сомнение.
Может дело в подходе? ;-)
PROG_NAME = myprog
BUILD_TYPE = MULTI_SRC_BIN
include $(DEFS)
# а тут ваши дополнительные правила, если нужно
include $(RULES)
Это абсолютно то же самое. Переизобретенный велосипед.
Не говорю,
Еще один язык программирования? Все-таки вызов внешнего шелла как вынужденная
необходимость потихоньку отмирает.
Я думаю, вы выдаете желаемое за действительное. Я лично считаю вызов
внешнего шела гораздо более правильной практикой по сравнению с
изобретением собственных недоязыков
On Fri, 26 Sep 2008 18:02:52 +0400
Artem Chuprina wrote:
AC Почему не может? Может. Первый не-опциональный аргумент
AC командной строки заканчивает список опций.
DEO так это и растет от того что НЕ может
Нет. Это растет из того, что так специфицировано.
Гнутая утилита, кстати, тоже
Результаты 1 - 100 из 644 matches
Mail list logo
