[unix] почему пишут скрипты на shell вместо perl?
> почему все эти configure пишутся таким диким образом?
они ведь не пишутся, а генерируются, так?
> Ведь вроде как perl - такой же стандартный инструмент любой UNIX-системы как и shell.
нет
> (честно говоря, я вообще ни разу не видел shell-а в котором бы не работал echo, unset, поэтому малопонятно назначение всей этой ботвы из configure).
а много ты их видел?
я тоже не видел, но читал отцов в ru.unix например
они ведь не пишутся, а генерируются, так?
> Ведь вроде как perl - такой же стандартный инструмент любой UNIX-системы как и shell.
нет
> (честно говоря, я вообще ни разу не видел shell-а в котором бы не работал echo, unset, поэтому малопонятно назначение всей этой ботвы из configure).
а много ты их видел?
я тоже не видел, но читал отцов в ru.unix например
Видел проги, у которых эти скрипты на перле.
Читаются они ничуть не легче.
Читаются они ничуть не легче.
(честно говоря, я вообще ни разу не видел shell-а в котором бы не работал echo, unset,подозреваю, что именно в тех ОС, где shell обладает такими св-вами, perl не является стандартным инструментом.
P.S. В FreeBSD perl уже не является стандартным инструментом.
> они ведь не пишутся, а генерируются, так?
это конечно так, но очень часто эти скрипты глючат, работают не так как надо, и потому приходится в них лазить и ковырять, что там и где там не так пошло. а они для этого совершенно неприспособлены, порой приходится полдня потратить что бы понять почему программа не так конфигурится. я думаю, это типичное, явление, массовое, разработчики autoconf знают про него.
тем не менее - что это меняет: что мешает генерировать скрипт на perl?
по-моему, здесь типичное нарушение принципа KISS:
вместо того чтобы написать простенький, маленький, работающий скрипт на perl люди изобретают какие-то жуткие workaround для каких-то жутких shell-ов, где почему-то неправильно работает echo. вопрос в том, зачем все это надо, если можно, в 1000 раз проще?
> нет
почему? откуда такие сведения? ты видел машину, которая реально использовалась для работы и там не было perl?
> а много ты их видел?
мало
> я тоже не видел, но читал отцов в ru.unix например
ну то что такую машину можно специально соорудить - это понятно. и что кто-нибудь это сделал - тоже понятно.
вопрос в том, бывает ли такое на нормальных, реально используемые, повседневных машинах. я думаю, на всех них shell работает нормально.
если в shell нет echo - я думаю, он 10 летней давности. непонятно, зачем поддерживать такие архаизмы? заставить пользователя явно проапргейдиться до нормального shell. ведь бывает же что программа требует определенную версию libc, gcc. вроде как это считается нормально. почему нельзя требовать от shell чтобы он выполнял какие-то базовые вещи?
это конечно так, но очень часто эти скрипты глючат, работают не так как надо, и потому приходится в них лазить и ковырять, что там и где там не так пошло. а они для этого совершенно неприспособлены, порой приходится полдня потратить что бы понять почему программа не так конфигурится. я думаю, это типичное, явление, массовое, разработчики autoconf знают про него.
тем не менее - что это меняет: что мешает генерировать скрипт на perl?
по-моему, здесь типичное нарушение принципа KISS:
вместо того чтобы написать простенький, маленький, работающий скрипт на perl люди изобретают какие-то жуткие workaround для каких-то жутких shell-ов, где почему-то неправильно работает echo. вопрос в том, зачем все это надо, если можно, в 1000 раз проще?
> нет
почему? откуда такие сведения? ты видел машину, которая реально использовалась для работы и там не было perl?
> а много ты их видел?
мало
> я тоже не видел, но читал отцов в ru.unix например
ну то что такую машину можно специально соорудить - это понятно. и что кто-нибудь это сделал - тоже понятно.
вопрос в том, бывает ли такое на нормальных, реально используемые, повседневных машинах. я думаю, на всех них shell работает нормально.
если в shell нет echo - я думаю, он 10 летней давности. непонятно, зачем поддерживать такие архаизмы? заставить пользователя явно проапргейдиться до нормального shell. ведь бывает же что программа требует определенную версию libc, gcc. вроде как это считается нормально. почему нельзя требовать от shell чтобы он выполнял какие-то базовые вещи?
> Видел проги, у которых эти скрипты на перле.
Интересно, приведи пример.
> Читаются они ничуть не легче.
А чего там такое? Тоже сплошные workaround-ы от кривых perl-ов?
Интересно, приведи пример.
> Читаются они ничуть не легче.
А чего там такое? Тоже сплошные workaround-ы от кривых perl-ов?
> P.S. В FreeBSD perl уже не является стандартным инструментом.
можно поподробнее? ему нашли какую-то более удобную замену? или он сам по каким-то причинам непонравился? хотя бы в дистрибутиве-то оставили?
можно поподробнее? ему нашли какую-то более удобную замену? или он сам по каким-то причинам непонравился? хотя бы в дистрибутиве-то оставили?
Саша, ты тоже ненавидишь sh? Я считаю так - если скрипт длиннее одного экрана - нужно использовать perl. Конечно, если в perlе каждая вторая строчка будет system то лучше использовать sh.
Однако, я на работе вижу людей которые тратят кучу времени на написание огромных, непонятных скриптов на sh. Которые просто опасны, потому что программировать на sh очень небезопасно. Каждая вторая команда, это не команда языка а ОС. Которые страшно медленны, потому что для выполнения минимума действий делается вызов десятка внешних утилит. Которые трудно дебажить... и т.д. и т.п. А когда принимают на работу то интересуются навыками программирования на sh.
Однако, я на работе вижу людей которые тратят кучу времени на написание огромных, непонятных скриптов на sh. Которые просто опасны, потому что программировать на sh очень небезопасно. Каждая вторая команда, это не команда языка а ОС. Которые страшно медленны, потому что для выполнения минимума действий делается вызов десятка внешних утилит. Которые трудно дебажить... и т.д. и т.п. А когда принимают на работу то интересуются навыками программирования на sh.
Он занимает много места. А далеко не каждая инсталляция FreeBSD его использует. Например ему нечего делать на роутере. Поэтом его больше нет в базовой системе.
> Конечно, если в perlе каждая вторая строчка будет system то лучше использовать sh.
./configure именно так себя ведёт, как я понимаю
там ведь надо повызывать разные установленные программы, и посмотреть, что они делают
> потому что программировать на sh очень небезопасно.
с этим, похоже, уже ничего не поделать
./configure именно так себя ведёт, как я понимаю
там ведь надо повызывать разные установленные программы, и посмотреть, что они делают
> потому что программировать на sh очень небезопасно.
с этим, похоже, уже ничего не поделать
Да, действительно. Это первый серъезный довод против perl. Тут нечего возразить.
> Саша, ты тоже ненавидишь sh?
Правильнее сказать, я ненавижу длинные глючные нечитабельные скрипты на sh.
Возможно, что сам sh провоцирует людей так писать, но на счет этого я не уверен - я редко пишу на sh, если что-то нужно, обычно perl использую.
> Я считаю так - если скрипт длиннее одного экрана - нужно использовать perl. Конечно, если в perlе каждая вторая строчка будет system то лучше использовать sh.
Полностью поддерживаю такую точку зрения.
Правильнее сказать, я ненавижу длинные глючные нечитабельные скрипты на sh.
Возможно, что сам sh провоцирует людей так писать, но на счет этого я не уверен - я редко пишу на sh, если что-то нужно, обычно perl использую.
> Я считаю так - если скрипт длиннее одного экрана - нужно использовать perl. Конечно, если в perlе каждая вторая строчка будет system то лучше использовать sh.
Полностью поддерживаю такую точку зрения.
> ./configure именно так себя ведёт, как я понимаю
> там ведь надо повызывать разные установленные программы, и посмотреть, что они делают
это в идеале так должно быть.
в реальности configure на 1% состоит из проверок на всякие *.h и либы, и 99% он пытается сделать
exec, echo, если не работает echo, то print, а если нет print, то printf - итд. Т.е. если бы была стандартизированная функция для вывода текста и тому подобных вещей большую часть configure можно было бы спокойно убрать.
+ еще то, что configure обычно делает Makefile из Makefile.in при этом делается много замен по регэкспам, а для этого perl лучше подходит.
> там ведь надо повызывать разные установленные программы, и посмотреть, что они делают
это в идеале так должно быть.
в реальности configure на 1% состоит из проверок на всякие *.h и либы, и 99% он пытается сделать
exec, echo, если не работает echo, то print, а если нет print, то printf - итд. Т.е. если бы была стандартизированная функция для вывода текста и тому подобных вещей большую часть configure можно было бы спокойно убрать.
+ еще то, что configure обычно делает Makefile из Makefile.in при этом делается много замен по регэкспам, а для этого perl лучше подходит.
ну тебе ж уже объяснили, что perl - нестандартный компонет
со всякими древними юниксами его не поставляют
со всякими древними юниксами его не поставляют
Я говорю не про configure. Я про то, что shell программирования нужно избегать, заменяя sр на perl/ruby/make/с в зависимости от задачи. А вместо избегания у поступающих на работу спрашивают о их навыках программирования на sh и считают это важным моментом.
> Я про то, что shell программирования нужно избегать, заменяя sр на perl/ruby/make/с в зависимости от задачи.
Увы, когда основные объекты, к которыми работаешь - файлы, shell удобнее.
Поэтому на безопасность, и на производительность, часто забивают.
Ещё тезис, что программу на перле легче отлаживать, мне не понятен.
Чем легче?
Увы, когда основные объекты, к которыми работаешь - файлы, shell удобнее.
Поэтому на безопасность, и на производительность, часто забивают.
Ещё тезис, что программу на перле легче отлаживать, мне не понятен.
Чем легче?
Увы, когда основные объекты, к которыми работаешь - файлы, shell удобнее.Это иллюзия. Например хочется найти файлы с именем удовлетворяющим определенному regexp. Что делается ls в пайп sedу или grepу, потом разгребание выходного потока на токены. Да тут просто гнездо слабых мест - файлы с пробелами, не совместимость grepов и sedов между собой, ... и т.п.
А ведь в perl достаточно:
opendir(DIR, my $var) or die ;
while (defined( my $file = readdir(DIR {
next unless $file =~ /regex/;
[i] do something [/i]
}
И это намного проще прочесть человеку, который привык алгоритмическому программированию, а не нагромождению пайпов.
P.S. Кстати, заметил за собой и сотрудниками, что программировае на sh увлекательно. Человеку интересно собирать из плохосращиваемых конечностей работающего франкенштейна.
ну для упражнения неплохо бы наверное переписать все инит-скрипты от своей ОС на perl/python/ruby или что там ещё нравится
потом сравнить объём и читаемость
да ещё и какие-нибудь слабые места найти и устранить, иначе работа бессмысленная
например, тупо заменять source на require не годицца
так что там про отладку?
у sh есть опция -x например
потом сравнить объём и читаемость
да ещё и какие-нибудь слабые места найти и устранить, иначе работа бессмысленная
например, тупо заменять source на require не годицца
так что там про отладку?
у sh есть опция -x например
> > они ведь не пишутся, а генерируются, так?
> это конечно так, но очень часто эти скрипты глючат, работают не так как надо, и потому приходится в них лазить и ковырять, что там и где там не так пошло. а они для этого
> совершенно неприспособлены, порой приходится полдня потратить что бы понять почему
это общее свойство программ, которые генерируются, а не пишутся руками
если бы, например, у gcc не было бы опции -g, и не было бы gdb, который умеет этим пользоваться,
точно так же пришлось бы разгребать машинный код
> программа не так конфигурится. я думаю, это типичное, явление, массовое, разработчики autoconf знают про него.
не собираюсь защищать autoconf, но в таких случаях обычно даже мне понятно, что автор программы
не дочитал документацию, поэтому конфигурялка у него неправильная
> это конечно так, но очень часто эти скрипты глючат, работают не так как надо, и потому приходится в них лазить и ковырять, что там и где там не так пошло. а они для этого
> совершенно неприспособлены, порой приходится полдня потратить что бы понять почему
это общее свойство программ, которые генерируются, а не пишутся руками
если бы, например, у gcc не было бы опции -g, и не было бы gdb, который умеет этим пользоваться,
точно так же пришлось бы разгребать машинный код
> программа не так конфигурится. я думаю, это типичное, явление, массовое, разработчики autoconf знают про него.
не собираюсь защищать autoconf, но в таких случаях обычно даже мне понятно, что автор программы
не дочитал документацию, поэтому конфигурялка у него неправильная
стартовые скрипты это другое дело. Это обвязка для запуска приложений, тут sh самое лучшее.
"ssh +x" - это такой же дебаг, как я специалист-химик. Конечно, perldebug(1) не есть полноценный дебаггер, но на порядок лучше.
"ssh +x" - это такой же дебаг, как я специалист-химик. Конечно, perldebug(1) не есть полноценный дебаггер, но на порядок лучше.
> стартовые скрипты это другое дело
> Это обвязка для запуска приложений, тут sh самое лучшее.
1. многие проблемы вылезают несмотря не это
2. далеко не всегда простая обвязка, например в RH скрипты для поднятия сети
или скрипт из dhclient для того же - просто страхоужас
или например сколь-нибудь нетривиальный firewall, где обязательно циклы
> Конечно, perldebug(1) не есть полноценный дебаггер, но на порядок лучше.
буду втыкать
ещё особенность shell - плавный переход от интерактивной работы к программированию
что само по себе имхо есть важный аспект unix way
> Это обвязка для запуска приложений, тут sh самое лучшее.
1. многие проблемы вылезают несмотря не это
2. далеко не всегда простая обвязка, например в RH скрипты для поднятия сети
или скрипт из dhclient для того же - просто страхоужас
или например сколь-нибудь нетривиальный firewall, где обязательно циклы
> Конечно, perldebug(1) не есть полноценный дебаггер, но на порядок лучше.
буду втыкать
ещё особенность shell - плавный переход от интерактивной работы к программированию
что само по себе имхо есть важный аспект unix way
ещё особенность shell - плавный переход от интерактивной работы к программированию
что само по себе имхо есть важный аспект unix way
Это факт. Зачастую скрипт делается путем редактирования .bash_history
Вот как бы если бы был язык, пригодный для интерактивной работы, и расширяемый до
хорошего безопасного эффективного языка программирования, то был бы рулез.
Вот были лисп-машины, бейсик-машины - можно использовать этот опыт.
Решение возможно, я думаю, но оно будет ни разу не традиционным, и потому с внедрением будут проблемы.
хорошего безопасного эффективного языка программирования, то был бы рулез.
Вот были лисп-машины, бейсик-машины - можно использовать этот опыт.
Решение возможно, я думаю, но оно будет ни разу не традиционным, и потому с внедрением будут проблемы.
а еще есть cons (apt-cache show cons) написанный на perl'е Сегодня вот пришлось патчить один варез и с этим cons по ходу дела повозился - прикольно.
Сегодня вот пришлось патчить один варез и с этим cons по ходу дела повозился - прикольно.Вот как бы если бы был язык, пригодный для интерактивной работы, и расширяемый до
хорошего безопасного эффективного языка программирования, то был бы рулез.
http://www.google.com/search?q=perl+shell
Это если перл таковым считать.
то, что configure обычно делает Makefile из Makefile.in при этом делается много замен по регэкспам, а для этого perl лучше подходит.
Последние autoconf, не помню, с какой версии начиная, по умолчанию config.status (скрипт, который генерируется configure, и собственно он и производит все замены и созданрие файлов) генерят на перле. Такие скрипты еще вместо "Creating bla-bla-bla" пишут "Fastcreating bla-bla-bla".
это конечно так, но очень часто эти скрипты глючат, работают не так как надо, и потому приходится в них лазить и ковырять, что там и где там не так пошло.
Возможно я не понимаю твою конкретную ситуацию, но если у тебя есть исходник (configure.in или configure.ac для последних версий autoconf то залезать внутрь сгенерированного configure ни в коем случае не надо! autoconf - это очень стабильный, отлаженный код, и по исходнику скрипт он генерит очень и очень правильно. Если проблемы с configure скриптом, то залезай в configure.in/ac, aclocal.m4, *.m4, но не лезь в сам configure! Случаев, когда поставляется configure, но не поставляется его исходник мне не попадалось. Хотя, наверное, такое бывает. Еще про Makefile.in - там, если используется automake, та же петрушка. Не лезь в Makefile.in, правь Makefile.am, automake - это очень отлаженный и стабильный код.
psh - вещь классная, но последняя версия датирована январем 2003. А еще она у меня сдохла на zless /usr/share/doc/psh/changelog.gz
TCL, Lisp, Scheme.
Для умельцев-радикалов --- Forth.
---
...Я работаю антинаучным аферистом...
Для умельцев-радикалов --- Forth.
---
...Я работаю антинаучным аферистом...
Для умельцев-радикалов --- Forth.Скрипты на форте?
По-моему не очень удобно...Разве что таскать за собой готовый словарь всевозможных примочек...
А вот в плане гибкости и расширяемости Форту и правда равных мало.
Ты знаком с творчеством Немцева?
Там и есть они самые.
Правда, примеры у них написаны жутко коряво.
А что словарь придётся таскать,
так это и в юниксе не работают всегда через ядро.
---
...Я работаю антинаучным аферистом...
Там и есть они самые.
Правда, примеры у них написаны жутко коряво.
А что словарь придётся таскать,
так это и в юниксе не работают всегда через ядро.
---
...Я работаю антинаучным аферистом...
Кстати, по-моему, очень даже удобно.
Разметил файлы числами и вперёд.
А когда надо вспомнить, можно сказать что-то вроде "lsof."
---
...Я работаю антинаучным аферистом...
Разметил файлы числами и вперёд.
А когда надо вспомнить, можно сказать что-то вроде "lsof."
---
...Я работаю антинаучным аферистом...
Ты знаком с творчеством Немцева?
Там и есть они самые.
Нет. Можно подробнее?
Забавно, но ИМХО, это для маньяков
Кстати, когда-то был такой забавный язык rexx. Помню, многи мои знакомые тогда
им сильно восхищялись. Но как-то он тихо загнулся... Вместе с OS/2...
Кстати, когда-то был такой забавный язык rexx. Помню, многи мои знакомые тогда
им сильно восхищялись. Но как-то он тихо загнулся... Вместе с OS/2...
Вот были лисп-машины, бейсик-машины - можно использовать этот опыт.
уж лучше тогда какой-нить рефал, обработка текста на нем куда удобней.
На самом деле, это не самое лучшее из писаного на форте.
Даже на первый взгляд.
Это просто нечитаемо.
Можно сделать значительно красивее.
Очень неудачна попытка совместить форт с униксовостью.
Про REXX я слышал, смотрел как-то --- не понравился.
Кстати, должна быть погнутая версия.
Не помню, как зовётся.
---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."
Даже на первый взгляд.
Это просто нечитаемо.
Можно сделать значительно красивее.
Очень неудачна попытка совместить форт с униксовостью.
Про REXX я слышал, смотрел как-то --- не понравился.
Кстати, должна быть погнутая версия.
Не помню, как зовётся.
---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."
Прогресс. Это радует, буду пытаться использовать такой autoconf в своих программах.
у меня была примерно такая ситуация: в системе имелась куча разных компилеров, стоящих в разных местах + переменные окружения типа СС, PROGRAMNAME_CC, ANOTHER_CC, ONCEMORE_CC итп. И вот почему-то configure подбирал не тот компилятор, который мне был нужен. Я пытался понять откуда он его берет, и как надо поставить переменные окружения (включая PATH чтобы он собирался нужным компилятором. В configure.in там обычно ограничиваются строчкой типа AC_PROG_CC, типа найти компилятор, и потому непонятно как именно он его ищет.
А вообще да - всегда когда можно, читаю configure.in файлы, очень часто это решает проблему.
А вообще да - всегда когда можно, читаю configure.in файлы, очень часто это решает проблему.
autoconf - это очень стабильный, отлаженный код, и по исходнику скрипт он генерит очень и очень правильно.Бугага! недаром его существует парраллельно три версии и нужно быть магом, что бы знать когда какую следует использовать.
Лев, тебе совет на будущие флеймы с юниксоидами - дави на то, что autoconf говно, они не смогут отмазаться.
А ведь в perl достаточно:
opendir(DIR, my $var) or die ;
while (defined( my $file = readdir(DIR {
next unless $file =~ /regex/;
do something
}
И это намного проще прочесть человеку, который привык алгоритмическому программированию, а не нагромождению пайпов.
как вариант:
ls -1 | awk '/regex/ {do something}'
делает то же самое, и, как мне кажется, выглядит проще
> делает то же самое
нет
и вот если автор скрипта не отдаёт себе в этом отчёт, то и возникают проблемы
нет
и вот если автор скрипта не отдаёт себе в этом отчёт, то и возникают проблемы
> делает то же самое
нет
если не сложно: какого рода проблемы могут возникнуть? когда я писал, то ориентировался по фразе:
Это иллюзия. Например хочется найти файлы с именем удовлетворяющим определенному regexp. Что делается ls в пайп sedу или grepу, потом разгребание выходного потока на токены. Да тут просто гнездо слабых мест - файлы с пробелами, не совместимость grepов и sedов между собой, ... и т.п.
этих проблем здесь нет
Файлы с именами, начинающимися на '.' или содержащими '\n'
для '.' : ls -a1
а в чем проблема с \n я не понял: если это символ новой строки, то я не понял как он в названии файла появится, если это файл типа:
touch qqnale\\nqqnale
то тем более не понял проблемы ...
а в чем проблема с \n я не понял: если это символ новой строки, то я не понял как он в названии файла появится, если это файл типа:
touch qqnale\\nqqnale
то тем более не понял проблемы ...
> я не понял как он в названии файла появится
Например так:
Это изврат конечно, но насколько я помню, единственный запрещенный символ в названии файла это 0x00.
Например так:
echo q > 'Hello
world'
Это изврат конечно, но насколько я помню, единственный запрещенный символ в названии файла это 0x00.
точно! я не знал:)
тогда: ls -ab1
тогда: ls -ab1
Ты еще много чего не видел. Вот сравни:
и вот это:
ты по-прежнему за shell-скрипты?
% uname -a
Linux lxplus032 2.4.20-30.7.cernsmp SMP Thu Feb 19 12:36:51 CET 2004 i686 unknown
% ls -ab1 | grep Hello
Hello\nworld
и вот это:
% uname -a
SunOS sunrfcms9 5.6 Generic_105181-17 sun4m sparc SUNW,SPARCstation-4
% ls -ab1 | grep Hello
Hello\012world
ты по-прежнему за shell-скрипты?
осталось учесть, что и regexp, и часть do something нужно будет преобразовать, чтобы работать с
покорёженными именами
вот и получилось, что если стремиться к корректности, на шелле писать сложнее
и, как тут уже намекают, правила эскейпинга не документированы и не стандартны, поэтому
возможны всякие проблемы из-за этого
покорёженными именами
вот и получилось, что если стремиться к корректности, на шелле писать сложнее
и, как тут уже намекают, правила эскейпинга не документированы и не стандартны, поэтому
возможны всякие проблемы из-за этого
единственный запрещенный символ в названии файла это 0x00.еще '/'
perl - такой же стандартный инструмент любой UNIX-системы как и shellЛол. Попробуй в HP-классе мехмата поработать с Perl
ну ты и пример привёл 
в том НР вообще нихера нет
в том НР вообще нихера нет
Это HP-UX, и эта система тоже относится к UNIX-классу.
ты думаешь там есть autoconf/automake ?
это уже оффтоп пошёл
это уже оффтоп пошёл
Можно вопрос?
А причём здесь autoconf и automake?
Вроде как нужно говорить про sh и m4?
---
...Я работаю антинаучным аферистом...
А причём здесь autoconf и automake?
Вроде как нужно говорить про sh и m4?
---
...Я работаю антинаучным аферистом...
изначально тред был про perl vs configure (и сопутствующее)
на HP-UX нет ни перла ни всего остального (насколько я знаю, хотя могу и ошибаться)
к тому же я написал, что это оффтопик
на HP-UX нет ни перла ни всего остального
(насколько я знаю, хотя могу и ошибаться)к тому же я написал, что это оффтопик
Так извини меня.
Перла нет, но sh есть.
И я тебе могу сказать, что перл не всегда бывает даже на линуксах.
---
...Я работаю антинаучным аферистом...
Перла нет, но sh есть.
И я тебе могу сказать, что перл не всегда бывает даже на линуксах.
---
...Я работаю антинаучным аферистом...
а GNU make есть ? (отвечать не надо - знаю что нет). Может я этих кошек готовить не умею, но вот у меня всегда почему-то все эти умные configure хотели после именно GNU make. Кстати, отцы, может научите как делать так, чтобы оно и BSD make собиралось ?
Кстати, когда-то был такой забавный язык rexx. Помню, многи мои знакомые тогда
им сильно восхищялись. Но как-то он тихо загнулся... Вместе с OS/2...
помнят ещё... нада же...
клёвый язык... он у миня до сих пор с os/2 установлен
после него я и под винду скрипты под wsh на яве пишу... На этих HP например компилятор C не доставлен - не хватает, например, модуля поддержки ANSI C.
Точнее, не было, когда я сдавал прак.
Поэтому программы приходилось собирать компилятором С++.
С этим связан эпизод, который показывает вред мании величия.
Я решил, что смогу сдать прак, появившись там только в день сдачи.
Естественно, моя прога была написана на стандартном С, и работала правильно.
Принести прогу в класс попросил кореша.
За 10 минут, которые были до начала процедуры сдачи (комиссия) я не смог скомпилировать прогу.
Потом оказалось, что у меня была переменная с именем private.
Результат - задержка в 2 недели, до следующей комиссии.
Точнее, не было, когда я сдавал прак.
Поэтому программы приходилось собирать компилятором С++.
С этим связан эпизод, который показывает вред мании величия.
Я решил, что смогу сдать прак, появившись там только в день сдачи.
Естественно, моя прога была написана на стандартном С, и работала правильно.
Принести прогу в класс попросил кореша.
За 10 минут, которые были до начала процедуры сдачи (комиссия) я не смог скомпилировать прогу.
Потом оказалось, что у меня была переменная с именем private.
Результат - задержка в 2 недели, до следующей комиссии.
В FreeBSD configure используют 5168 портов, gmake используют 2296. Значит 2872 используют BSD make. Оценка приблизительная, получена с помощью find + grep + wc. Все порты собираются.
Возможно тебе просто кривой софт попадается, создатели которого думали что gmake единственный и не поставили проверку на то что make это GNU make?
Возможно тебе просто кривой софт попадается, создатели которого думали что gmake единственный и не поставили проверку на то что make это GNU make?
> Возможно тебе просто кривой софт попадается, создатели которого думали что gmake единственный и не поставили проверку на то что make это GNU make?
А разве не в том смысл autoconf, automake, libtool - избавить разработчика от изучения особенностей каждой платформы?
Потому что, если я знаю эти особенности - мне эти тулзы не нужны нафиг - я сразу мейкфайлы правильные напишу.
А разве не в том смысл autoconf, automake, libtool - избавить разработчика от изучения особенностей каждой платформы?
Потому что, если я знаю эти особенности - мне эти тулзы не нужны нафиг - я сразу мейкфайлы правильные напишу.
Дык AC_CHECK_MAKE (или как его там звать?) не вставляется автоматом
а почему?
нет, просто вот честно пишу руками все эти configure.in Makefile.am, далее automake....autoconf...и потом все это дело собирается только GNU make, а я хочу BSD make, т.к. основная target платформа - FreeBSD. Как заставить генерить Makefile для BSD make я не знаю.
При использовании autoconf совсем не обязательно пользоваться automake. Можно писать Makefile.in руками, и очень часто так и делают (для простых маленьких проектов это гораздо быстрее и проще). Вот в таких ситуациях и получаются Makefile.in, которые требуют конкретную версию make. automake генерит все более-менее правильно, по крайней мере получаемые Makefile.in совместимы с bsd make.
нет, просто вот честно пишу руками все эти configure.in Makefile.am, далее automake....autoconf...и потом все это дело собирается только GNU make, а я хочу BSD make, т.к. основная target платформа - FreeBSD. Как заставить генерить Makefile для BSD make я не знаю.Так это вопрос по automake. Я не знаю ответ. Только autoconf юзал.
а почему?Зачастую Makefile.in пишется руками, и automake не пользуются. Только autoconf.
Оставить комментарий
Landstreicher
В UNIX-системах очень часто используется скрипты на shell. Типичным примером может служить configure который входит в комплект почти каждой программы и определяет настройки необходимые для сборки на данном конкретном компе. Как правило, этот скрипт очень е@#$нутый изнутри и весь наполнен какими workaround-ами, типа работают ли unset, echo, exec итп подобные команды. Как результат скрипт становится очень большой, совершенно нечитабельный, и найти интересующее там место почти невозможно.После долгого и упорного трахания с разного рода сonfigure/autoconf итп утилитами - у меня возник вопрос: почему все эти configure пишутся таким диким образом? Почему бы не писать его на чем-нибудь более нормальном, например perl?
Ведь вроде как perl - такой же стандартный инструмент любой UNIX-системы как и shell. Было бы гораздо удобнее, не пришлось придумывать всякие проверки и workaround для разных больных shell-ов (честно говоря, я вообще ни разу не видел shell-а в котором бы не работал echo, unset, поэтому малопонятно назначение всей этой ботвы из configure). По-моему perl идеально подходит для написания такого типа вещей.
был заголовок: вопрос по unix