Re: Нужен ли bash

2008-10-06 Пенетрантность Игорь Чумак

cramp пишет:
Многое из coreutils собрано под win32 (unxutils). Под виндой вполне 
работает. (и grep, и sed, и awk ). Я пользуюсь ;)

А что шыбко критичного не умеет cmd.exe?
  


  

Ну, к примеру, создайте из cmd каталог имя которого будет текущей датой.

D:\tempFOR /F usebackq delims== %i IN (`date /t`) DO mkdir %i
D:\tempmkdir Пт 26.09.2008 

Запускать прямо из cmd, не из файла.



  

C:\Temp\mkdir %DATE%
  



  

Работает?? Это что за ОС и что за шелл?
Если %DATE% == переменная окружения, то чему (и за счёт чего) она у вас 
равна?



Винда 2000, cmd.exe, руками нигде не прописана такая переменная

Получаем папку вида 06.10.2008

  


Шайтан!
Посыпаю голову пеплом ;)

Но получаем на самом деле 2 папки: Пн и  06.10.2008
Потомушто
echo %date%
Пн 06.10.2008

Похоже, что это малодокументированная функция cmd.exe (переменная %date% 
по команде set не выводится)


--



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



RE: Нужен ли bash

2008-10-06 Пенетрантность cramp
 Многое из coreutils собрано под win32 (unxutils). Под виндой вполне 
 работает. (и grep, и sed, и awk ). Я пользуюсь ;)
 А что шыбко критичного не умеет cmd.exe?

 Ну, к примеру, создайте из cmd каталог имя которого будет текущей датой.

 D:\tempFOR /F usebackq delims== %i IN (`date /t`) DO mkdir %i
 D:\tempmkdir Пт 26.09.2008 

 Запускать прямо из cmd, не из файла.

 C:\Temp\mkdir %DATE%


 Работает?? Это что за ОС и что за шелл?
 Если %DATE% == переменная окружения, то чему (и за счёт чего) она у вас 
 равна?

Винда 2000, cmd.exe, руками нигде не прописана такая переменная

Получаем папку вида 06.10.2008


ГУП РК ТП НИЦ



Re: Нужен ли bash

2008-10-06 Пенетрантность Evgeniy M. Solodookhin
,-[Mon, Oct 06, 2008 at 12:11 +0300, Игорь Чумак:]
 Посыпаю голову пеплом ;)

 Но получаем на самом деле 2 папки: Пн и  06.10.2008
 Потомушто
 echo %date%
 Пн 06.10.2008

 Похоже, что это малодокументированная функция cmd.exe (переменная %date%  
 по команде set не выводится)

 -- 
у меня с виндового сервака архивится 7zip и rar в архивы вида
06.10.2008.7zip
двух архивов не делает.
)
%DATE%.7zip выходное имя для архива.
)
чудесо на чудесе.
)

-- 
__
mpd status: [stopped]
**
*  jabber:  [EMAIL PROTECTED]   *
*   Registered linux user #450844*
**


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-05 Пенетрантность Grey Fenrir
On Wed, 01 Oct 2008 10:43:21 +0400
Artem Chuprina wrote:

  GF Не драки ради, а токмо для самообразования.
  GF Любопытно, как _негнутые_ утилиты обработают, скажем, файл с
  GF именем -f Как справится гнутая (команда ключи -- файлы)
  GF мне понятно, а какие есть инструменты для этого в стандарте?
  GF Разумеется, если не использовать финты с указанием путей.
 
 Почему разумеется?  Это стандартный способ указывать такие файлы.
Потому, что именно _такие_. Если юзер вручную набирает имя файла то
скорее всего (но тоже не 100%) он осознаёт его схожесть с опцией (и
добавляет путь), а вот если несколько имён подставляются
шеллом 
Из слов Andrey Kiselev следует, что -- вполне себе является
переносимым способом. Он указывается всего один раз да и читабельность
(на мой взгляд) повышает. Кстати, дисциплина пользователя тоже (в
теории) растёт, ибо ключи будут указаны _до_ файлов. Поэтому если
аргументов против -- нету, то этот вариант я буду считать
предпочтительным (как минимум - для скриптов).


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-03 Пенетрантность Andrey Lyubimets

Artem Chuprina пишет:

Andrey Lyubimets - debian-russian@lists.debian.org  @ Thu, 02 Oct 2008 
12:49:43 +0700:

   DEO а на кой фиг надо два MTA на одном хосте?
 
  Я знаю по крайней мере три паттерна работы в такой позе - существенно
  разные требования на прием и раздачу, существенно разные требования на
  релеинг и прием себе, и этап смены MTA.
 AL Расскажи поподробнее, а то я всю голову сломал, но паттернов, где
 AL был бы нужен более другой МТА не вижу.

У разных MTA при разработке имелись в виду разные назначения.  Так,
скажем, поцфикс оптимизировался под мощную почтомолотилку, а exim -
скорее под гибкость настройки, и на больших нагрузках ведет себя
плоховато.  Особенно - если это exim-heavy.

расскажи это в [EMAIL PROTECTED], там много народу с большим трафиком,
никто не жалуется. Или это проблемы дебиановского пакета?


Ну вот, собственно, один ставят на релеинг, за ним другой на обработку
локальной почты.  Или один на обработку входящих соединений, другой - на
контент-фильтрацию.  Или один на разгребание очереди на отправку, другой
на прием (exim, скажем, имеет очень так себе алгоритм разгребания
очереди).  Кто что лучше умеет.
Ну не верю я, что один против другого что-то настолько лучше умеет (при этом 
нечто другое настолько хуже) что бы требовалось запускать два МТА. Для 
сложной системы можно обойтись запуском одного с разными конфигами в 99,9% 
случаев.


  Первые два мне и самому не актуальны, но мы действительно хотим, чтобы
  на серьезных почтовых узлах приходилось пользоваться редхатом или
  соляркой не потому, что оно сертифицировано (это серьезным почтовым
  узлам как раз пофигу), а потому, что работает без геморроя, в отличие от
  дебиана?
 
  А третий вот мне, любимому, вот ровно сейчас как раз актуален...
 AL Ну вот хотя бы про третий напиши поподробнее, что бы проблема была не
 AL надуманная для примера, а реальная.

Реальная.  Перехожу с postfix на exim.  У поцфикса есть ограничения, в
которые я уткнулся, в exim с ними вроде проще.  Система не тривиальная,
там и SA, и антивирус, и релеинг в разных позах, включая UUCP.  Как это
делают нормальные админы?  Правильно, ставят новый MTA рядом, но на
другой порт, прикрытый файрволом, отлаживают конфигурацию, после чего
кладут старый MTA, меняют порт у нового, запускают его в работу,
запускают старый на разгребание очереди, дожидаются, когда разгребет,
сносят.

Внимание, вопрос.  Как это предлагается делать в Debian?
Ставить mta тестовый сервер, отладить конфигурацию, перенести её на рабочий 
сервер,затем запретить на нем входящие соединения, дождаться пока он 
разберётся с очередью (помочь ручками, если надо), заменить mta,. Так 
например. Хотя согласен, в случае сложной сетевой конфигурации не всегда её 
можно реализвать в тестовой среде ( или будет сильно накладно)







--
С уважением, Любимец Андрей Алексеевич


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-03 Пенетрантность Alexey Pechnikov
Hello!

В сообщении от Friday 03 October 2008 01:21:47 Artem Chuprina написал(а):
  GF Поднять в тестовом OVZ контейнере?

 В Debian нет пригодного для этого ядра.

 Предлагается делать в Debian все же подразумевает по умолчанию
 средствами, имеющимися в дистрибутиве...

А как насчет virtualbox? Привлекает возможность перетащить образ на любую 
машину, и не только под линукс. Ну или chroot.

Best regards, Alexey.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-03 Пенетрантность Aleksey Cheusov

 AC Да, именно. Это ваши проблемы. Если вы используете расширение,
 AC идущее вразрез со стандартным поведением, будьте готовы к тому, что
 AC инструментарий, расчитанный на нормальный sh с вашим zsh в этих
 AC режимах работать не будет. Напишите себе zshquote и да пребудет с
 AC вам ктулху.

 Так вот.  Для tcl и perl мне ничего писать и даже собирать не надо.
Это не аргумент. В шеле - бери готовое и не собирай.
Нету и нет желания собрать самому? Меняй систему.

 Оно и само не исполняет что попало как попало.  by design.
Выше было доказано обратное по крайней мере для perl-а.
Как раз таки by design небезопастная конструкция system
в перле есть.

  В отличие от sh, который by design как раз исполняет.
Выше было показано, что при неаккуратном программировании на perl
дыра имеет место быть. Также выше было показано, что при аккуратном
программировании не shell дыра таки успешно заклепывается.
Следовательно. By design дырявость инструментов perl и shell таки
одинакова - то есть, оставляет желать лучшего в обоих случаях.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-03 Пенетрантность Eugene V. Lyubimkin
Aleksey Cheusov wrote:
GF Поднять в тестовом OVZ контейнере?
  
   В Debian нет пригодного для этого ядра.
  
   Предлагается делать в Debian все же подразумевает по умолчанию
   средствами, имеющимися в дистрибутиве...
 
 А как насчет virtualbox? Привлекает возможность перетащить образ на любую 
 машину, и не только под линукс. Ну или chroot.
 
 Сырой он IMHO. Буквально неделю назад поставил его на sarge.  В нем
 хотел поставить на поиграться opensolaris-20080508.  Мало того, что
 модуль ядра сам не собрался - ошибка в Makefile-е. Пришлось исходники
 подпиливать. Так еще при инсталляции соляры внутрь получил kernel
 panic, это уж совсем ниже плинтуса.  Ядро 2.4.27. Sarge, конечно,
 старый, но официально поддерживается, .deb-ка лежит на скачку.
 
Sarge уже официально не поддерживается, ЕМНИП.

-- 
Eugene V. Lyubimkin aka JackYF



signature.asc
Description: OpenPGP digital signature


Re: Нужен ли bash

2008-10-03 Пенетрантность Aleksey Cheusov

   GF Поднять в тестовом OVZ контейнере?
 
  В Debian нет пригодного для этого ядра.
 
  Предлагается делать в Debian все же подразумевает по умолчанию
  средствами, имеющимися в дистрибутиве...

 А как насчет virtualbox? Привлекает возможность перетащить образ на любую 
 машину, и не только под линукс. Ну или chroot.

Сырой он IMHO. Буквально неделю назад поставил его на sarge.  В нем
хотел поставить на поиграться opensolaris-20080508.  Мало того, что
модуль ядра сам не собрался - ошибка в Makefile-е. Пришлось исходники
подпиливать. Так еще при инсталляции соляры внутрь получил kernel
panic, это уж совсем ниже плинтуса.  Ядро 2.4.27. Sarge, конечно,
старый, но официально поддерживается, .deb-ка лежит на скачку.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-03 Пенетрантность Aleksey Cheusov
  panic, это уж совсем ниже плинтуса.  Ядро 2.4.27. Sarge, конечно,
  старый, но официально поддерживается, .deb-ка лежит на скачку.
  
 Sarge уже официально не поддерживается, ЕМНИП.

Я не про Debian а про SUN.

http://virtualbox.org/wiki/Linux_Downloads

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-03 Пенетрантность Artem Chuprina
Andrey Lyubimets - debian-russian@lists.debian.org  @ Fri, 03 Oct 2008 
16:01:41 +0700:

  Ну вот, собственно, один ставят на релеинг, за ним другой на
  обработку локальной почты.  Или один на обработку входящих
  соединений, другой - на контент-фильтрацию.  Или один на разгребание
  очереди на отправку, другой на прием (exim, скажем, имеет очень так
  себе алгоритм разгребания очереди).  Кто что лучше умеет.
 AL Ну не верю я, что один против другого что-то настолько лучше умеет
 AL (при этом нечто другое настолько хуже) что бы требовалось запускать
 AL два МТА. Для сложной системы можно обойтись запуском одного с
 AL разными конфигами в 99,9% случаев.

Ну, не верь.  Я тебя обращать в какую-либо веру не собираюсь.  Ты
спросил - я ответил.

  Внимание, вопрос.  Как это предлагается делать в Debian?
 AL Ставить mta тестовый сервер, отладить конфигурацию, перенести её на
 AL рабочий сервер,затем запретить на нем входящие соединения,
 AL дождаться пока он разберётся с очередью (помочь ручками, если
 AL надо), заменить mta,. Так например. Хотя согласен, в случае сложной
 AL сетевой конфигурации не всегда её можно реализвать в тестовой среде
 AL ( или будет сильно накладно)

То есть купить сервер, поставить на него, перенастроить, продать сервер?..

Чтобы продать что-нибудь ненужное, надо сначала купить что-нибудь
ненужное...

(Виртуальный сервер, типа предлагавшегося VZ-контейнера - тоже штука
сильно небесплатная.  По трудозатратам на ее подъем и настройку.)

Кстати, ты в последовательности действий ошибся.  Причем грубо.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Functional programming is like describing your problem to a
mathematician.  Imperative programming is like giving instructions to
an idiot.
 -- arcus, #scheme on Freenode


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-03 Пенетрантность Artem Chuprina
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 дырявость инструментов perl и shell таки
 AC одинакова - то есть, оставляет желать лучшего в обоих случаях.

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

В перле небезопасная конструкция есть, но пользуются ею только полные
чайники, у них это сильно не первая проблема.  Это - проще не
раскладывать.  В sh в поставке нет даже средства обойти.  Можно взять
откуда-то со стороны.  По слухам, оно даже соберется.  Это - сложно
обойти.

А с точки зрения теоретических возможностей и грабель они не различаются
- оба Тьюринг-полны...  Вон недавно в ЖЖ показывали ссылку на тетрис,
реализованный на sed...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Нужны две программы - одна с интерфейсом, а другая чтобы работу делала.
Victor Wagner в [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-03 Пенетрантность Aleksey Cheusov
   В отличие от sh, который by design как раз исполняет.
 AC Выше было показано, что при неаккуратном программировании на perl
 AC дыра имеет место быть. Также выше было показано, что при аккуратном
 AC программировании не shell дыра таки успешно заклепывается.
 AC Следовательно. By design дырявость инструментов perl и shell таки
 AC одинакова - то есть, оставляет желать лучшего в обоих случаях.

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

 В перле небезопасная конструкция есть, но пользуются ею только полные
 чайники

С этим согласен. И на этой радостной ноте предлагаю эту часть
дискуссии завершить.  Достигнут консенсус.  Ошибки - они удел полных
чайников.  Мы ошибок не допускаем! ;-) ;-)

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Andrey Lyubimets

Artem Chuprina пишет:


 DEO а на кой фиг надо два MTA на одном хосте?

Я знаю по крайней мере три паттерна работы в такой позе - существенно
разные требования на прием и раздачу, существенно разные требования на
релеинг и прием себе, и этап смены MTA.
Расскажи поподробнее, а то я всю голову сломал, но паттернов, где был бы 
нужен более другой МТА не вижу.


Первые два мне и самому не актуальны, но мы действительно хотим, чтобы
на серьезных почтовых узлах приходилось пользоваться редхатом или
соляркой не потому, что оно сертифицировано (это серьезным почтовым
узлам как раз пофигу), а потому, что работает без геморроя, в отличие от
дебиана?

А третий вот мне, любимому, вот ровно сейчас как раз актуален...
Ну вот хотя бы про третий напиши поподробнее, что бы проблема была не 
надуманная для примера, а реальная.


Нет, я понимаю, у настоящих дзен-буддистам ни одна из этих задач не
встает в принципе...  Но дебиан вроде пока не позиционируется как
дистрибутив только для них...




--
С уважением, Любимец Андрей Алексеевич


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Artem Chuprina
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 $filename;
 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

Я подозреваю, что это тоже вскрывается, но без shquote проверить не
могу...  Непереносимость, впрочем, надеюсь, очевидна.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

/dev/null-транспортировка


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Artem Chuprina
Andrey Lyubimets - debian-russian@lists.debian.org  @ Thu, 02 Oct 2008 
12:49:43 +0700:

   DEO а на кой фиг надо два MTA на одном хосте?
 
  Я знаю по крайней мере три паттерна работы в такой позе - существенно
  разные требования на прием и раздачу, существенно разные требования на
  релеинг и прием себе, и этап смены MTA.
 AL Расскажи поподробнее, а то я всю голову сломал, но паттернов, где
 AL был бы нужен более другой МТА не вижу.

У разных MTA при разработке имелись в виду разные назначения.  Так,
скажем, поцфикс оптимизировался под мощную почтомолотилку, а exim -
скорее под гибкость настройки, и на больших нагрузках ведет себя
плоховато.  Особенно - если это exim-heavy.

Ну вот, собственно, один ставят на релеинг, за ним другой на обработку
локальной почты.  Или один на обработку входящих соединений, другой - на
контент-фильтрацию.  Или один на разгребание очереди на отправку, другой
на прием (exim, скажем, имеет очень так себе алгоритм разгребания
очереди).  Кто что лучше умеет.

  Первые два мне и самому не актуальны, но мы действительно хотим, чтобы
  на серьезных почтовых узлах приходилось пользоваться редхатом или
  соляркой не потому, что оно сертифицировано (это серьезным почтовым
  узлам как раз пофигу), а потому, что работает без геморроя, в отличие от
  дебиана?
 
  А третий вот мне, любимому, вот ровно сейчас как раз актуален...
 AL Ну вот хотя бы про третий напиши поподробнее, что бы проблема была не
 AL надуманная для примера, а реальная.

Реальная.  Перехожу с postfix на exim.  У поцфикса есть ограничения, в
которые я уткнулся, в exim с ними вроде проще.  Система не тривиальная,
там и SA, и антивирус, и релеинг в разных позах, включая UUCP.  Как это
делают нормальные админы?  Правильно, ставят новый MTA рядом, но на
другой порт, прикрытый файрволом, отлаживают конфигурацию, после чего
кладут старый MTA, меняют порт у нового, запускают его в работу,
запускают старый на разгребание очереди, дожидаются, когда разгребет,
сносят.

Внимание, вопрос.  Как это предлагается делать в Debian?

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Феаноринги думают руками, арфинги - сердцем, а нолфинги - головой. (С)энта


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Alexey Pechnikov
Hello!

В сообщении от Thursday 02 October 2008 08:29:22 Victor Wagner написал(а):
   Появившуюся возможность подстановки списков. В смысле подставить
   n-элементный список в команду не как один параметр, а как n,
   БЕЗ лишнего уровня evaluation для всего остального.
 
  А как это делается? Когда будет раскрывать список?

 Специальным синтаксисом подстановки. Что-то вроде {}$list
 У меня сейчас man Tcl от 8.5 под рукой нету.

Спасибо, этого достаточно.

Best regards, Alexey.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Aleksey Cheusov
 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

 Я подозреваю, что это тоже вскрывается, но без shquote проверить не
 могу...  Непереносимость, впрочем, надеюсь, очевидна.

Да переносимость очевидна. shquote - это open source, 2-closure BSD license.
Если у вас ее нет, это сами знаете чьи проблемы.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Artem Chuprina
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 '$filename'`\
 AC   eval $cmd

  shquote: command not found

  Я подозреваю, что это тоже вскрывается, но без shquote проверить не
  могу...  Непереносимость, впрочем, надеюсь, очевидна.

 AC Да переносимость очевидна. shquote - это open source, 2-closure BSD
 AC license.  Если у вас ее нет, это сами знаете чьи проблемы.

По этой логике переносима любая виндовая программа - эмулятор же есть,
поставить можно...

Я правильно понимаю, что shquote рассчитана на квотинг только BSD'шного
шелла?

Вскрываться вроде не вскрывается...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Нужны две программы - одна с интерфейсом, а другая чтобы работу делала.
Victor Wagner в [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Aleksey Cheusov
 AC Да переносимость очевидна. shquote - это open source, 2-closure BSD
 AC license.  Если у вас ее нет, это сами знаете чьи проблемы.

 По этой логике переносима любая виндовая программа - эмулятор же есть,
 поставить можно...

Не надо передергивать.  Если мне нужна программа X, которая требует
для своей работы программу Y, _МОЯ_ задача раздобыть таки программу Y,
поставщик программы X (автор) должен прямым текстом заявить мне нужна
программа Y, что я и сделал. То же самое касается библиотек перла,
тикля, руби и всех без исключения.

 Я правильно понимаю, что shquote рассчитана на квотинг только BSD'шного
 шелла?
Нет в природе никакого BSD-шного шела. У всех *BSD шелы разные.
Квотинг же для всех шелов одинаковый.  Или докажи мне обратное.

 Вскрываться вроде не вскрывается...
Что не вскрывается?

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Artem Chuprina
Aleksey Cheusov - debian-russian@lists.debian.org  @ Thu, 02 Oct 2008 15:58:58 
+0300:

 AC Да переносимость очевидна. shquote - это open source, 2-closure BSD
 AC license.  Если у вас ее нет, это сами знаете чьи проблемы.

  По этой логике переносима любая виндовая программа - эмулятор же есть,
  поставить можно...

 AC Не надо передергивать.  Если мне нужна программа X, которая требует
 AC для своей работы программу Y, _МОЯ_ задача раздобыть таки программу Y,
 AC поставщик программы X (автор) должен прямым текстом заявить мне нужна
 AC программа Y, что я и сделал. То же самое касается библиотек перла,
 AC тикля, руби и всех без исключения.

  Я правильно понимаю, что shquote рассчитана на квотинг только BSD'шного
  шелла?
 AC Нет в природе никакого BSD-шного шела. У всех *BSD шелы разные.
 AC Квотинг же для всех шелов одинаковый.  Или докажи мне обратное.

Доказываю.  man zshoptions
/EXTENDED_GLOB

По крайней мере, в некоторых режимах квотинга у zsh надо квотить больше 
символов.

  Вскрываться вроде не вскрывается...
 AC Что не вскрывается?

Банка.  В смысле, получить из указанной тобой конструкции исполнение
команды мне не удалось.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

русская народная глупость
Кнышев


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Aleksey Cheusov

  Я правильно понимаю, что shquote рассчитана на квотинг только BSD'шного
  шелла?
 AC Нет в природе никакого BSD-шного шела. У всех *BSD шелы разные.
 AC Квотинг же для всех шелов одинаковый.  Или докажи мне обратное.

 Доказываю.  man zshoptions
 /EXTENDED_GLOB

У тебя сомнения на счет того, что я тебе отвечу в этом случае? 8-)
Да, именно. Это ваши проблемы. Если вы используете расширение, идущее
вразрез со стандартным поведением, будьте готовы к тому, что
инструментарий, расчитанный на нормальный sh с вашим zsh в этих
режимах работать не будет. Напишите себе zshquote и да пребудет с вам
ктулху.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Artem Chuprina
Aleksey Cheusov - debian-russian@lists.debian.org  @ Thu, 02 Oct 2008 17:15:12 
+0300:

  Я правильно понимаю, что shquote рассчитана на квотинг только BSD'шного
  шелла?
 AC Нет в природе никакого BSD-шного шела. У всех *BSD шелы разные.
 AC Квотинг же для всех шелов одинаковый.  Или докажи мне обратное.

  Доказываю.  man zshoptions
  /EXTENDED_GLOB

 AC У тебя сомнения на счет того, что я тебе отвечу в этом случае? 8-)
 AC Да, именно. Это ваши проблемы. Если вы используете расширение,
 AC идущее вразрез со стандартным поведением, будьте готовы к тому, что
 AC инструментарий, расчитанный на нормальный sh с вашим zsh в этих
 AC режимах работать не будет. Напишите себе zshquote и да пребудет с
 AC вам ктулху.

Так вот.  Для tcl и perl мне ничего писать и даже собирать не надо.  Оно
и само не исполняет что попало как попало.  by design.  В отличие от sh,
который by design как раз исполняет.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Молодой, дикорастущий организм...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Grigory Fateyev
Hello Artem Chuprina!
On Thu, 02 Oct 2008 12:07:32 +0400 you wrote:

 Реальная.  Перехожу с postfix на exim.  У поцфикса есть ограничения, в
 которые я уткнулся, в exim с ними вроде проще.  Система не
 тривиальная, там и SA, и антивирус, и релеинг в разных позах, включая
 UUCP.  Как это делают нормальные админы?  Правильно, ставят новый MTA
 рядом, но на другой порт, прикрытый файрволом, отлаживают
 конфигурацию, после чего кладут старый MTA, меняют порт у нового,
 запускают его в работу, запускают старый на разгребание очереди,
 дожидаются, когда разгребет, сносят.
 
 Внимание, вопрос.  Как это предлагается делать в Debian?

Поднять в тестовом OVZ контейнере?

-- 
Всего наилучшего! Григорий
greg [at] anastasia [dot] ru
Письмо отправлено: 2008/10/02 20:05


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Eugene V. Lyubimkin
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 C++ developer.



signature.asc
Description: OpenPGP digital signature


Re: Нужен ли bash

2008-10-02 Пенетрантность Artem Chuprina
Grigory Fateyev - debian-russian@lists.debian.org  @ Thu, 2 Oct 2008 20:06:56 
+0400:

  Реальная.  Перехожу с postfix на exim.  У поцфикса есть ограничения, в
  которые я уткнулся, в exim с ними вроде проще.  Система не
  тривиальная, там и SA, и антивирус, и релеинг в разных позах, включая
  UUCP.  Как это делают нормальные админы?  Правильно, ставят новый MTA
  рядом, но на другой порт, прикрытый файрволом, отлаживают
  конфигурацию, после чего кладут старый MTA, меняют порт у нового,
  запускают его в работу, запускают старый на разгребание очереди,
  дожидаются, когда разгребет, сносят.
  
  Внимание, вопрос.  Как это предлагается делать в Debian?

 GF Поднять в тестовом OVZ контейнере?

В Debian нет пригодного для этого ядра.

Предлагается делать в Debian все же подразумевает по умолчанию
средствами, имеющимися в дистрибутиве...

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

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Реляционная база данных - это не единственный способ сделать дурацкий поиск.
Victor Wagner


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-02 Пенетрантность Artem Chuprina
Eugene V. Lyubimkin - debian-russian@lists.debian.org  @ Fri, 03 Oct 2008 
00:39:36 +0300:

   GF Поднять в тестовом OVZ контейнере?
  
  В Debian нет пригодного для этого ядра.
 EVL Эээ... а зачем тогда -openvz ядро собрали в Debian?

Вот когда выйдет тот дистрибутив, в котором его собрали - тогда и будет
ответ на этот вопрос...

P.S. Нет, его собрали не за этим...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

When C++ is your hammer, everything looks like a thumb
 -- Latest seen from Steven M. Haflich, in c.l.l


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Andrey Kiselev
On Mon, Sep 29, 2008 at 11:26:34AM +0400, Grey Fenrir wrote:
 Не драки ради, а токмо для самообразования.
 Любопытно, как _негнутые_ утилиты обработают, скажем, файл с именем -f
 Как справится гнутая (команда ключи -- файлы) мне понятно, а
 какие есть инструменты для этого в стандарте?

Точно такие же.

The getopt() function shall return the next option character (if one is
found) from argv that matches a character in optstring, if there is one
that matches. If the option takes an argument, getopt() shall  set  the
variable optarg to point to the option-argument as follows:

 1. If the option was the last character in the string pointed to by an
element of argv, then optarg shall  contain  the  next  element  of
argv,  and optind shall be incremented by 2. If the resulting value
of optind is greater than argc, this indicates  a  missing  option-
argument, and getopt() shall return an error indication.

 2. Otherwise,  optarg  shall  point to the string following the option
character in that element of argv, and optind shall be  incremented
by 1.

If, when getopt() is called:

   argv[optind]  is a null pointer*
   argv[optind]  is not the character -
   argv[optind]  points to the string -

getopt() shall return -1 without changing optind. If:

   argv[optind]   points to the string --

getopt() shall return -1 after incrementing optind.

-- 
Andrey V. Kiselev
ICQ# 26871517


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Victor Wagner
On 2008.09.29 at 11:26:34 +0400, Grey Fenrir wrote:

 Не драки ради, а токмо для самообразования.
 Любопытно, как _негнутые_ утилиты обработают, скажем, файл с именем -f

Любая утилита прекрасно поймет что ./-f - это имя файла, а не опция.
Рекомендую этот прием запомнить и им пользоваться.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Artem Chuprina
Alexey Pechnikov - debian-russian@lists.debian.org  @ Tue, 30 Sep 2008 
18:10:28 +0400:

 AP P.S. А нет ли у вас ссылочки на грамотное руководство по созданию
 AP make-файлов, не привязанных к шеллу? Хотелось бы понять, есть ли в
 AP этом смысл или полученные мэйкфайлы непригодны на практике.

Воспользоваться заменителем мейка, написанным без сохранения
совместимости.  scons, bras...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Historically, languages designed for other people to use have been
bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those
that were designed for their own creators: C, Perl, Smalltalk, Lisp.
 -- Paul Graham


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Artem Chuprina
Dmitry E. Oboukhov - debian-russian@lists.debian.org  @ Tue, 30 Sep 2008 
20:22:41 +0400:

 DEO а если говорить о make, то по этой аналогии получится и sh
 DEO рекурсивный и тикль и perl и питон и тд итп

Не вопрос.  Вопрос в том, что для make это harmful, а для sh, тикля,
перла и питона - нет.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Чем отличается свобода от независимости? 
Независимость - это когда за тебя не платят.
А свобода - когда за тебя не думают.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Artem Chuprina
Grey Fenrir - debian-russian@lists.debian.org  @ Mon, 29 Sep 2008 11:26:34 
+0400:

   AC Почему не может?  Может.  Первый не-опциональный аргумент
   AC командной строки заканчивает список опций.
   DEO так это и растет от того что НЕ может
  
  Нет.  Это растет из того, что так специфицировано.
  
  Гнутая утилита, кстати, тоже не поймет ключа в конце, если в середине
  было сказано --...
  
 GF Не драки ради, а токмо для самообразования.
 GF Любопытно, как _негнутые_ утилиты обработают, скажем, файл с именем -f
 GF Как справится гнутая (команда ключи -- файлы) мне понятно, а
 GF какие есть инструменты для этого в стандарте?
 GF Разумеется, если не использовать финты с указанием путей.

Почему разумеется?  Это стандартный способ указывать такие файлы.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Если ты не боишься синего экрана, то почему боишься черного?
 -- Д.Белявский


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Artem Chuprina
Aleksey Cheusov - debian-russian@lists.debian.org  @ Tue, 30 Sep 2008 16:42:56 
+0300:

  Recursive Make Considered Harmful --- это в особенности раздражает).
   Пока останусь при своём мнении: майк надо уметь
   готовить. Хотя SCons надо будет попробовать...
  
  http://makepp.sourceforge.net/
 EVL Не увидел, чем оно лучше, чем make для написания make-файлов.

  Это ты, значит, сложных не писал...  Тому, кто писал, ключевые места
  очевидны.

 AC А зачем, пардон, писать сложные Makefile-ы?  Надо писать простые.

 AC Ну можно ли проще?

 ACPROG = myprog
 ACSRCS = file1.c file2.c

 AC.include bsd.prog.mk

 AC И ведь оно уже все умеет.

Так ведь оно само кем-то написано?  Так вот, оно и есть сложный
мейкфайл.

 AC Для простых проектов и проектов средней величины нет ничего лучше
 AC  MK-скриптов BSD make-а IMHO.

Возможно.  Вот только моих задач оно не решает.  Не рассчитано.
Впрочем, насколько я понимаю, что тех же проблем, что у recursive make,
оно с тем же успехом не решает.  Поскольку в этих скриптах, в общем,
никаких чудес.

А если оно, паче чаяния, не сложное, а простое, то оно вообще решает
только задачу однократной сборки.  Поскольку, опять же, никаких чудес.

 AC Интересно, есть ли в природе аналог mk скриптам для GNU make-а?

В природе - есть.  Не публиковалось за ненадобностью, но можно, думаю, и
показать.  Нет, оно сложнее bsd'шных, ибо поддерживает несколько более
навороченную систему сборки (в одном дереве, раздаваемом по NFS, на
несколько платформ).  Оно очень сильно заточено под местные условия,
поскольку никогда не предполагалось к универсальности, но все идеи
оттуда вычитать можно.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Рюкзак не пересобирают, рюкзак укладывают! (c)Руна


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Artem Chuprina
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 system :)

Если бы expert...  А то dumb...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

An ideal world is left as an exercise to the reader.
Paul Graham, On Lisp


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Dmitry E. Oboukhov
AC а если говорить о make, то по этой аналогии получится и sh
AC рекурсивный и тикль и perl и питон и тд итп

AC Не вопрос.  Вопрос в том, что для make это harmful, а для sh, тикля,
AC перла и питона - нет.
необосновано (если рекурсией называть то что вы называете)
--
... mpd is off

. ''`.   Dmitry E. Oboukhov
: :’  :   email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED]
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature


Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov
  Я думаю, вы выдаете желаемое за действительное.  Я лично считаю вызов
  внешнего шела гораздо более правильной практикой по сравнению с
  изобретением собственных недоязыков программирования.
 
  А вызвать внешний shell ничем не хуже, чем дернуть встроенный
  интерпретатор java script, lua, scheme, lisp etc.
  Но и то и другое лучше изобретения велосипедов.

 В чем смысл изучения синтаксиса кучи специфичных языков make, bash, sed, awk, 
 grep, etc.,
Э-э-э-э... Ну-у-у-у-у. Даже не знаю, что и сказать.
Каждое средство хорошо на своем месте.

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

 (и не таскать кучу зависимостей при этом)?
Нежелательные зависимости - это как раз таки многотонные интерпретаторы
perl/python/tcl/ruby с многотонными же библиотеками.

BSD make/GNU make зависимостями не считаются :)

 Под линуксом один make, под бсд-клонами, как выясняется, другой,
Вообще-то, это общеизвестно. Ну, по крайне мере за пределами Линукса
все знают о разнообразии make-ов ;)

 в винде nmake
offtopic

, да еще синтаксис внешних утилит разный - получается, что задача
написать переносимый мэйкфайл требует огромных трудозатрат.
При всем моем уважении к стандартам, не советую ставить
задачу написания портабельных Makefile-в. Ни к чему хорошему для
вашего продукта это не принесет, и никому это не нужно.
Уж слишком убог стандартный make.

В настоящее время стандартами де факто являются GNU make и BSD make.
Мне гораздо больше нравится BSD make и особенно его MK скрипты.
С ужасом вспоминаю GNU-make-овский eval/call и прочие его прелести.

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

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov
 ACPROG = myprog
 ACSRCS = file1.c file2.c

 AC.include bsd.prog.mk

 AC И ведь оно уже все умеет.

 Так ведь оно само кем-то написано?  Так вот, оно и есть сложный
 мейкфайл.

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

 AC Для простых проектов и проектов средней величины нет ничего лучше
 AC  MK-скриптов BSD make-а IMHO.

 Возможно.  Вот только моих задач оно не решает.
...
  Поскольку, опять же, никаких чудес.
Твоих проблем/задач не решает, да. Рекурсия там в полный рост -
bsd.subdir.mk.  Автозависимостей для внутренностей .c/.cpp не доставляет.

Но эти проблемы меня беспокоят гораздо меньше, чем навозная куча
automake, как реализация изначально кривого подхода генерируем
Makefile.  MK скрипты BSD make-а против automake-а.
Вот что больше заботит меня.

 AC Интересно, есть ли в природе аналог mk скриптам для GNU make-а?

 В природе - есть.
...
 Оно очень сильно заточено под местные условия,
 поскольку никогда не предполагалось к универсальности, но все идеи
 оттуда вычитать можно.
Если бы был аналог MK скриптов для GNU make-а, чудовище
automake не родилось бы на свет.

autotools must die! Вот новая тема для дружелюбной беседы! 8-)

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Dmitry Fedorov
1 октября 2008 г. 16:20 пользователь Aleksey Cheusov написал:
  AC И ведь оно уже все умеет.

Хм. Бывший начальник рассказал. Экспертиза изобретения. Изобретатель
изобрёл установку фотоэлемента на ж/д локомотив. Он же всё видит! А
дальше уже ваше дело.

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

Для того, чтобы ею воспользоваться, она должна быть оформлена как
отдельная библиотека и вне контекста fbsd,
иначе она частный велосипед только для бсдишников.

  AC Для простых проектов и проектов средней величины нет ничего лучше
  AC  MK-скриптов BSD make-а IMHO.

Вы страдаете, глядя на изобретателей велосипедов?
А я - на руками выписанные имена файлов, иногда - 2-3 раза.


Re: Нужен ли bash

2008-10-01 Пенетрантность Alexey Pechnikov
Hello!

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

 Вот именно, что нельзя.

  (и не таскать кучу зависимостей при этом)?

 Нежелательные зависимости - это как раз таки многотонные интерпретаторы
 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 килобайт?

В то время, как
$ ls -l `which bash`
-rwxr-xr-x 1 root root 700492 Май 12 23:02 /bin/bash

То есть шелл, который без внешних утилит нежизнеспособен, весит столько же!

Далее,
 ls -l /usr/bin/gawk
-rwxr-xr-x 1 root root 303196 Мар 20  2008 /usr/bin/gawk

$ ls -l `which grep`
-rwxr-xr-x 1 root root 100468 Авг 31 21:06 /bin/grep

$ ls -l `which sed`
-rwxr-xr-x 1 root root 40468 Мар  3  2008 /bin/sed

$ ls -l `which less`
-rwxr-xr-x 1 root root 120816 Янв 22  2008 /usr/bin/less

Если вы посчитаете суммарный размер необходимых утилит, то увидите, что 
использовать tclsh вместо связки bash+туча утилит как раз логично. 

Best regards, Alexey.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Victor Wagner
On 2008.10.01 at 12:20:17 +0300, Aleksey Cheusov wrote:
   Поскольку, опять же, никаких чудес.
 Твоих проблем/задач не решает, да. Рекурсия там в полный рост -
 bsd.subdir.mk.  Автозависимостей для внутренностей .c/.cpp не доставляет.
 
 Но эти проблемы меня беспокоят гораздо меньше, чем навозная куча

В смысле, твои проблемы - это проблемы админа, ставящего чужой софт,
и собирающего его только при выходе новой версии, 
а не проблемы разработчика, который софт (не важно, свой или чужой)
модифицирует, и пересобирает по 50 раз на дню?


 autotools must die! Вот новая тема для дружелюбной беседы! 8-)

Э, неужели найдется хотя бы один пользователь в списке рассылки,
который будет высказывать хоть какие-то вменяемые аргументы ЗА
autotools?

Даже если рассматривать только autoconf - наиболее вменяемое средство
из этой компании, то обнаружится, что для того, чтобы написать вменяемый
configure.in требуется много больше квалификации, чем имеют 90% авторов 
OpenSource пакетов.

Простейший пример - посчитайте сколько пакетов исходных текстов в
дистрибутиве, базирующихся на autoconf, из коробки правильно
сконфигурируются с --host=i386-linux --taget=i586-mingw32msvc 
(и сколько из них при этом нормально сконфигурируются в Native Mingw32).

Про более хитрые случаи кросскомпиляции я пока помолчу. Достаточно того,
для которого есть готовый тулчейн в дистрибутиве.

Хотя да, в идеологии autoconf есть все необходимые закладки под
кросс-компиляцию. Но пользоваться ими люди не умеют.

Результатом этого бардака являются такие ублюдства как маемовский
scratchbox. Вместо того, чтобы положить нормальный тулчейн для
кросс-сборки под maemo, плюс, может быть, небольшие патчики к
dpkg-cross,
нокиевцам пришлось изобретать извращенный эмулятор, потому что мало
какой софт (из пользующегося autotools) можно честно собрать в пакет под
чужую платформу.

Впрочем., тут претензии не только к autotools, а и к dpkg тоже.

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

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

А ведь это не только кросс-разработка. Это еще бы пригодилось при
ремонте порушенной системы с загрузкой с livecd с busybox-ом.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov
 On 2008.10.01 at 12:20:17 +0300, Aleksey Cheusov wrote:
Поскольку, опять же, никаких чудес.
  Твоих проблем/задач не решает, да. Рекурсия там в полный рост -
  bsd.subdir.mk.  Автозависимостей для внутренностей .c/.cpp не доставляет.
  
  Но эти проблемы меня беспокоят гораздо меньше, чем навозная куча

 В смысле, твои проблемы - это проблемы админа, ставящего чужой софт,
 и собирающего его только при выходе новой версии, 
 а не проблемы разработчика, который софт (не важно, свой или чужой)
 модифицирует, и пересобирает по 50 раз на дню?

Не админа, а скорее человека, пакетирующего пакет с целью, чтобы оно
собиралось и работало на многих многих платформах, в том числе
для кросссборки. pkgsrc - игрушка, в которую я играю последнее время.

Как бы там ни было, проблемы с отсутствием авто-зависимостей для С/С++
и прочие я прекрасно осознаю.

  autotools must die! Вот новая тема для дружелюбной беседы! 8-)

 Э, неужели найдется хотя бы один пользователь в списке рассылки,
 который будет высказывать хоть какие-то вменяемые аргументы ЗА
 autotools?
Так как же так случилось, что 90% софта сейчас собирается
именно с autotools?

 Даже если рассматривать только autoconf - наиболее вменяемое средство
 из этой компании, то обнаружится, что для того, чтобы написать вменяемый
 configure.in требуется много больше квалификации, чем имеют 90% авторов 
 OpenSource пакетов.
Угу. Запредельный софт :-) Я уже приводил статистику по этому поводу.
55% autotools-based пакетов pkgsrc патчатся на предмет configure/Makefile.
При этом на отлично поддерживаются только две
системы - NetBSD и DragonFlyBSD. Статистика очени 2007-ого.
Патчи чаще всего заключаются в том, чтобы отключить сверхинтеллект
апстрима к чертям. Ну вот дали людям попрограммировать на shell и m4,
а получилось как обычно - допрограммировались, каждый изъеживается
на что горазд, а какие там перлы... просто не передать...

Блин, вот я бы каждого автора ПО заставил бы смеху ради попакетить
свое же детище для pkgsrc и посмотреть, как оно собирается (хотя бы
собирается!) под разными платформами с экзотическими и не очень
компиляторами и прочими инструментами. Вот смеху было бы.

 Опять же - инсталляционные скрипты кучи пакетов совершенно не заточены
 под то, что исполняться они будут не в том окружении, в котором потом
 тому пакету работать.
Да-да-да. Библиотечный декларативный подход таки рулит.
На свалку систему, в которой процедура конфигурации-сборки-инсталляции
прибита гвоздями.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov

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

 Для того, чтобы ею воспользоваться, она должна быть оформлена как
 отдельная библиотека и вне контекста fbsd,
 иначе она частный велосипед только для бсдишников.

NetBSD-шники уже давным давно сделали то, о чем вы просите.
http://www.crufty.net/ftp/pub/sjg/

Именно NetBSD-ый make распространяется под именем pmake
и присутствует во многих линукс-дистрибутивах, включая собственно
Debian. Правда, несколько тухлых версий.

FreeBSD-ый make AFAIK используется только под фрей.

   AC Для простых проектов и проектов средней величины нет ничего лучше
   AC  MK-скриптов BSD make-а IMHO.

 Вы страдаете, глядя на изобретателей велосипедов?
Да.

 А я - на руками выписанные имена файлов, иногда - 2-3 раза.
Если это опять про SRCS, то, во-первых, я уже ответил.

А во вторых, включение файлов в проект автоматически  - по маске - это
ВЕСЬМА спорный момент. Это небезопастно. Вы же не добавляете
на CVS файлы по маске просто потому, что там присутствуют. Нет, вы требуете
'cvs add' - и это правильно, так и должно быть.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Dmitry Fedorov
1 октября 2008 г. 18:09 пользователь Aleksey Cheusov написал:

 А во вторых, включение файлов в проект автоматически  - по маске - это
 ВЕСЬМА спорный момент. Это небезопастно. Вы же не добавляете
 на CVS файлы по маске просто потому, что там присутствуют. Нет, вы требуете
 'cvs add' - и это правильно, так и должно быть.

Это не make-ово дело - за списком файлов в проекте следить.


Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov

  Нежелательные зависимости - это как раз таки многотонные интерпретаторы
  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 килобайт?

Я не специалист по безопастности, но я точно знаю, за что
perl выбросили из базовых систем NetBSD и FreeBSD.
Нет, это точно не его размер. 

Связь между размером исходного кода и
безопастностью прямая. Если уж выбирать что-то более мощное по
сравнению с shell-ом, я бы выбрал LUA или Java Script.
Но никак не TCL и тем более не python.

И, кстати, я никогда не утверждал, что как язык POSIX shell
совершенен.  Кое в чем я бы его поправил. Но в целом он на своем месте.

Что касается размеров.  размер баша и GNU awk вообще не показатель.
GNU utils традиционно выделяются своей далеко не всегда оправданной
жирностью.

Debian:
0 ~ls -lL /bin/sh
-rwxr-xr-x 1 root root 80200 Feb  2  2007 /bin/sh
0 ~

NetBSD:
0 ~ls -la /bin/sh
-r-xr-xr-x  1 root  wheel  135793 Apr 28  2007 /bin/sh
0 ~ls -la /usr/bin/awk
-r-xr-xr-x  1 root  wheel  133927 Apr 28  2007 /usr/bin/awk
0 ~

FreeBSD:
0 cheusovls -la /bin/sh
-r-xr-xr-x  1 root  wheel  106164 May 23  2007 /bin/sh
0 cheusovls -la /usr/bin/awk
-r-xr-xr-x  2 root  wheel  119164 May 23  2007 /usr/bin/awk
0 cheusov

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Artem Chuprina
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 /usr/lib/libtcl8.4.so.0

  Вас пугают 700 килобайт?

 AC Я не специалист по безопастности, но я точно знаю, за что
 AC perl выбросили из базовых систем NetBSD и FreeBSD.
 AC Нет, это точно не его размер. 

 AC Связь между размером исходного кода и
 AC безопастностью прямая. Если уж выбирать что-то более мощное по
 AC сравнению с shell-ом, я бы выбрал LUA или Java Script.
 AC Но никак не TCL и тем более не python.

Если речь идет о безопасности, то начинать надо с выкидывания sh.  И
только потом - perl...  А tcl как раз один из наиболее безопасных.

А Java Script безопасен только в песочнице.  Но в песочнице он
бесполезен.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Не сломалось - не чини.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov
  А во вторых, включение файлов в проект автоматически  - по маске - это
  ВЕСЬМА спорный момент. Это небезопастно. Вы же не добавляете
  на CVS файлы по маске просто потому, что там присутствуют. Нет, вы требуете
  'cvs add' - и это правильно, так и должно быть.

 Это не make-ово дело - за списком файлов в проекте следить.

Я что-то не пойму. Что плохого в том, что файлы, из которых строится
exe файл или библиотека ЯВНО перчислены в Makefile-е. Так и должно
быть.  Это норма.

  PROG= paexec
  SRCS= paexec.c wrappers.c nonblock_helpers.c
  .include bsd.prog.mk

Что не так?

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Dmitry Fedorov
1 октября 2008 г. 18:59 пользователь Aleksey Cheusov написал:
 Я что-то не пойму. Что плохого в том, что файлы, из которых строится
 exe файл или библиотека ЯВНО перчислены в Makefile-е. Так и должно
 быть.  Это норма.

Нет. Это привычка.

  PROG= paexec
  SRCS= paexec.c wrappers.c nonblock_helpers.c
  .include bsd.prog.mk

 Что не так?

Меньший автоматизм.
Для добавления типичного файла в проект мне достаточно добавить его в  CVS.
Вам же ещё нужно изменить ваш makefile - ручная работа.


Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov

 AC Связь между размером исходного кода и
 AC безопастностью прямая. Если уж выбирать что-то более мощное по
 AC сравнению с shell-ом, я бы выбрал LUA или Java Script.
 AC Но никак не TCL и тем более не python.

 Если речь идет о безопасности, то начинать надо с выкидывания sh.
Вызов внешней утилы не является дырой в безопастности.
По крайней мере речь _сейчас_ не об этом, контект не тот.

 И только потом - perl...  А tcl как раз один из наиболее безопасных.
Речь не о самом языке, а о реализации транслятора и библиотеках,
реализованных на C.

 А Java Script безопасен только в песочнице.  Но в песочнице он
 бесполезен.
Расшифруй.

Я бы вот с удовольствием заменил awk java script-ом, если бы к нему
добавить awk-шную data-driven логику и нормальные (POSIX compatible)
регулярные выражения.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Dmitry E. Oboukhov
DF Я что-то не пойму. Что плохого в том, что файлы, из которых строится
DF exe файл или библиотека ЯВНО перчислены в Makefile-е. Так и должно
DF быть.  Это норма.

DF Нет. Это привычка.

DF  PROG= paexec
DF  SRCS= paexec.c wrappers.c nonblock_helpers.c
DF  .include bsd.prog.mk
DF 
DF Что не так?

DF Меньший автоматизм.
DF Для добавления типичного файла в проект мне достаточно добавить его в  CVS.
DF Вам же ещё нужно изменить ваш makefile - ручная работа.
SRC = $(wildcard *.c) 
и забыли про редактирование make на добавлении файлов в проект :]
--
... mpd is off

. ''`.   Dmitry E. Oboukhov
: :’  :   email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED]
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature


Re: Нужен ли bash

2008-10-01 Пенетрантность Eugene V. Lyubimkin
Dmitry Fedorov wrote:
 1 октября 2008 г. 18:59 пользователь Aleksey Cheusov написал:
 Я что-то не пойму. Что плохого в том, что файлы, из которых строится
 exe файл или библиотека ЯВНО перчислены в Makefile-е. Так и должно
 быть.  Это норма.
 
 Нет. Это привычка.
 
  PROG= paexec
  SRCS= paexec.c wrappers.c nonblock_helpers.c
  .include bsd.prog.mk

 Что не так?
 
 Меньший автоматизм.
 Для добавления типичного файла в проект мне достаточно добавить его в  CVS.
 Вам же ещё нужно изменить ваш makefile - ручная работа.
Гм, а если у Вас лежат файлы в каталоге не под контролем версий, а
просто так, временные или на будущее?

-- 
Eugene V. Lyubimkin aka JackYF



signature.asc
Description: OpenPGP digital signature


Re: Нужен ли bash

2008-10-01 Пенетрантность Dmitry Fedorov
1 октября 2008 г. 19:37 пользователь Eugene V. Lyubimkin написал:
 Меньший автоматизм.
 Для добавления типичного файла в проект мне достаточно добавить его в  CVS.
 Вам же ещё нужно изменить ваш makefile - ручная работа.
 Гм, а если у Вас лежат файлы в каталоге не под контролем версий, а

Это ваша проблема. У меня всё под контролем :)

 просто так, временные или на будущее?

Не держите их там. Там все файлы - часть проекта.
Если очень нужно (не лень), можно сделать исключение в makefile
для некоторых файлов. Но это нетипично.


Re: Нужен ли bash

2008-10-01 Пенетрантность Dmitry Fedorov
1 октября 2008 г. 19:23 пользователь Dmitry E. Oboukhov написал:
 SRC = $(wildcard *.c)
 и забыли про редактирование

Вы невнимательны.
У меня так и я спорю с теми, у кого не так.


Re: Нужен ли bash

2008-10-01 Пенетрантность Dmitry E. Oboukhov
DF SRC = $(wildcard *.c)
DF и забыли про редактирование

DF Вы невнимательны.
DF У меня так и я спорю с теми, у кого не так.
ах, сорри я вклинился не прочитав контекст :)
ну считаем что нас уже двое :)
--
... mpd is off

. ''`.   Dmitry E. Oboukhov
: :’  :   email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED]
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature


Re: Нужен ли bash

2008-10-01 Пенетрантность Artem Chuprina
Aleksey Cheusov - debian-russian@lists.debian.org  @ Wed, 01 Oct 2008 15:22:46 
+0300:

 AC Связь между размером исходного кода и безопастностью прямая. Если
 AC уж выбирать что-то более мощное по сравнению с shell-ом, я бы
 AC выбрал LUA или Java Script.  Но никак не TCL и тем более не
 AC python.

  Если речь идет о безопасности, то начинать надо с выкидывания sh.
 AC Вызов внешней утилы не является дырой в безопастности.  По крайней
 AC мере речь _сейчас_ не об этом, контект не тот.

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

А во-вторых, у всякой утилиты, принимающей решения на основании файлов
из fs (включая их исполнение), немалая часть ее безопасности состоит из
того, что она берется исполнять, а что - нет.  Для ssh и sudo ошибки в
тщательном анализе прав - это ошибки в безопасности.  В sh механизма
анализа, что мы выполняем, нет как класса.  Это даже не ошибка в
безопасности, это design flaw.  Если в случае ssh и sudo это лечится
патчами, то в случае sh - только гильотиной.

Чтобы быть яснее.  Если на проблему все закрывают глаза - это не значит,
что проблемы не существует.

Я могу представить другие поводы выкинуть perl из базовой системы.
Размер, например.  Но выкинуть perl _по соображениям безопасности_ и
оставить при этом sh - это, извините, идиотизм.

  И только потом - perl...  А tcl как раз один из наиболее безопасных.
 AC Речь не о самом языке, а о реализации транслятора и библиотеках,
 AC реализованных на C.

Ну и?  Можно предъявить мне место, в котором tcl менее безопасен, чем
sh?

  А Java Script безопасен только в песочнице.  Но в песочнице он
  бесполезен.
 AC Расшифруй.

Безопасность JS базируется на том, что у него нет средств доступа к
системе.  Но если у него нет средств доступа к системе, он не сможет
этой системой рулить.

Ну и движки JS'ные по размеру - perl отдыхает...

 AC Я бы вот с удовольствием заменил awk java script-ом, если бы к нему
 AC добавить awk-шную data-driven логику и нормальные (POSIX
 AC compatible) регулярные выражения.

А смысл решать на получившемся винегрете задачи, которые решает awk?
Если их на авке решать сложно, вон для желающих лаконичности есть perl,
а для желающих ясности - tcl.  Где тут ниша для JS?

Ну, понятно, есть другие задачи, которые действительно может быть удобно
решать на JS (человеку, испорченному сишным синтаксисом и плюсовой
парадигмой - а я предпочту, в зависимости от задачи, либо perl, либо
lisp/tcl, либо python).  Но к ним непонятно, как пришить awk...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Обновление Windows изменило интуитивно ясный интерфейс Вашего компьютера.
Загрузите обновление интуиции с сайта Microsoft.
(С)энта


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Dmitry E. Oboukhov
DF Вы страдаете, глядя на изобретателей велосипедов?
DF А я - на руками выписанные имена файлов, иногда - 2-3 раза.
точно точно

на лоре обсуждали blockout2

так там makefile выглядел так:

SRC := a.c b.c c.c d.c e.c \
и так пол экрана перечисление сишный файлов, а ниже

OBJ := a.o b.o ...
и еще пол экрана

:)

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

. ''`.   Dmitry E. Oboukhov
: :’  :   email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED]
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature


Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov
 1 октября 2008 г. 18:59 пользователь Aleksey Cheusov написал:
  Я что-то не пойму. Что плохого в том, что файлы, из которых строится
  exe файл или библиотека ЯВНО перчислены в Makefile-е. Так и должно
  быть.  Это норма.

 Нет. Это привычка.

Покажите мне _хотя бы одну_ систему сборки (можно даже IDE), где был
бы реализован такой вот автоматизм.  Хотя бы одну.

   PROG= paexec
   SRCS= paexec.c wrappers.c nonblock_helpers.c
   .include bsd.prog.mk
 
  Что не так?

 Меньший автоматизм.

Пожалуй я категорически против такого рода автоматизма.
И спорить здесь бесполезно. Компромиса не будет.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Dmitry E. Oboukhov
AC А смысл решать на получившемся винегрете задачи, которые решает awk?
AC Если их на авке решать сложно, вон для желающих лаконичности есть perl,
AC а для желающих ясности - tcl. 
лаконичность и ясность это разве не две стороны одного и того же?
--
... mpd is off

. ''`.   Dmitry E. Oboukhov
: :’  :   email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED]
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature


Re: Нужен ли bash

2008-10-01 Пенетрантность Dmitry E. Oboukhov
AC Я что-то не пойму. Что плохого в том, что файлы, из которых строится
AC exe файл или библиотека ЯВНО перчислены в Makefile-е. Так и должно
AC быть.  Это норма.

AC Нет. Это привычка.

AC Покажите мне _хотя бы одну_ систему сборки (можно даже IDE), где был
AC бы реализован такой вот автоматизм.  Хотя бы одну.
программ собирающихся с использованием wildcard? их много
а систем сборки это что имеется ввиду?

де-факто стандарт - один проект в одном каталоге (пусть даже проект из
подпроектов состоит)
то есть внутри него обычно wildcard'ы хорошо ложаться

да конечно сборка с wildcard'ами не дает оставлять ненужных .c (скажем)
файлов в той же дире, но и переименовать никто не мешает с одной
стороны, а с другой это не дает развиваться мусору (и артефактам)

(типа файл давно уже не используется но продолжает наличествовать в
каталоге явно мешая на всяких грепах по исходникам, вводя в заблуждение
других разработчиков)

--
... mpd is off

. ''`.   Dmitry E. Oboukhov
: :’  :   email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED]
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature


Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov
 Я могу представить другие поводы выкинуть perl из базовой системы.
 Размер, например.  Но выкинуть perl _по соображениям безопасности_ и
 оставить при этом sh - это, извините, идиотизм.

Читай соответствующие списки рассылки.

  А Java Script безопасен только в песочнице.  Но в песочнице он
  бесполезен.
 AC Расшифруй.

 Безопасность JS базируется на том, что у него нет средств доступа к
 системе.
Нет. Есть соответствующие расширения.
И файлы JS открывать может и все прочее.
Я не помню, как эти расширения именуются.

  Но если у него нет средств доступа к системе, он не сможет
 этой системой рулить.

 Ну и движки JS'ные по размеру - perl отдыхает...

0 ~grep Size /srv/pkgsrc/lang/ossp-js/distinfo 
Size (js-1.6.20070208.tar.gz) = 1109930 bytes
0 ~grep Size /srv/pkgsrc/lang/js/distinfo  
Size (js-0.2.5.tar.gz) = 689982 bytes
0 ~grep Size /srv/pkgsrc/lang/perl5/distinfo 
Size (perl-5.8.8.tar.bz2) = 10123359 bytes
0 ~

 AC Я бы вот с удовольствием заменил awk java script-ом, если бы к нему
 AC добавить awk-шную data-driven логику и нормальные (POSIX
 AC compatible) регулярные выражения.

 А смысл решать на получившемся винегрете задачи, которые решает awk?
 Если их на авке решать сложно, вон для желающих лаконичности есть perl,
 а для желающих ясности - tcl.  Где тут ниша для JS?
Мне не нравится язык perl, мне не очень нравится tcl.
JS _КАК ЯЗЫК_ мне нравится гораздо больше.
Но мне ОЧЕНЬ хочется иметь data-driven логику,
присутствующую в awk от рождения.
Что до awk-а - я его очень широко использую, и пожалуй хорошо знаю, где
заканчиваются его возможности. У меня на нем натурально сотни скриптов.
Как язык программирования он все же убог. JS гораздо лучше.
Скрестить бы ужа с ежом.

 Ну, понятно, есть другие задачи, которые действительно может быть удобно
 решать на JS (человеку, испорченному сишным синтаксисом и плюсовой
 парадигмой - а я предпочту, в зависимости от задачи, либо perl, либо
 lisp/tcl, либо python).
А я уж лучше буду писать на sh+awk.
Эта связка дает мне почти все, что нужно. Чего не дает - дает С и С++.
И в этой связке я бы хотел awk заменить на какой-то вариант java script.
Для большей мощности, так скажем.

  Но к ним непонятно, как пришить awk...

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Victor Wagner
On 2008.10.01 at 14:59:33 +0300, Aleksey Cheusov wrote:

   А во вторых, включение файлов в проект автоматически  - по маске - это
   ВЕСЬМА спорный момент. Это небезопастно. Вы же не добавляете
   на CVS файлы по маске просто потому, что там присутствуют. Нет, вы 
 требуете
   'cvs add' - и это правильно, так и должно быть.
 
  Это не make-ово дело - за списком файлов в проекте следить.
 
 Я что-то не пойму. Что плохого в том, что файлы, из которых строится
 exe файл или библиотека ЯВНО перчислены в Makefile-е. Так и должно

А почему собственно вы думаете что у меня строится EXE-файл?
PDF у меня строится, описывающий использование этого EXE-файла, 
и в нем 55, нет уже 58 скриншотов.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov
 AC А смысл решать на получившемся винегрете задачи, которые решает awk?
 AC Если их на авке решать сложно, вон для желающих лаконичности есть perl,
 AC а для желающих ясности - tcl. 
 лаконичность и ясность это разве не две стороны одного и того же?

Нет. есть один волшебный пример - притча во языцах, как товарищ в
далеком 74-м году несколько часов разбирался в 4(!!!) строках на APL.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Victor Wagner
On 2008.10.01 at 15:22:46 +0300, Aleksey Cheusov wrote:

 
  AC Связь между размером исходного кода и
  AC безопастностью прямая. Если уж выбирать что-то более мощное по
  AC сравнению с shell-ом, я бы выбрал LUA или Java Script.
  AC Но никак не TCL и тем более не python.
 
  Если речь идет о безопасности, то начинать надо с выкидывания sh.
 Вызов внешней утилы не является дырой в безопастности.
 По крайней мере речь _сейчас_ не об этом, контект не тот.

Дырой в безопасности является строковая подстановка с неявным
репарсингом после неё. Чуть автор скрипта на кавычках поэкономил, и
привет - arbitrary command execution.

Был у меня случай лет десять назад, когда растаскивание скрипта по двум
машинам, общавшимся по ssh привело к тому, что посредством ввода
специального значения в поле на веб-страничке я получил у себя на
десктопе xterm  c бэкэнд-сервера с правами юзера wais.

ssh один уровень кавычек скушал и привет.


Вот у Tcl НЕЯВНОГО репарсинга нет. Только явным subst или eval.

Поэтому проблем со строковыми подстановками много меньше, чем в shell

  А Java Script безопасен только в песочнице.  Но в песочнице он
  бесполезен.
 Расшифруй.
 
 Я бы вот с удовольствием заменил awk java script-ом, если бы к нему
 добавить awk-шную data-driven логику и нормальные (POSIX compatible)

Какие проблемы? Придумай объектную модель, реализующую эту логику и
вперед.

 регулярные выражения.

Э, а разве там они ненормальные? Они там по-моему как бы не pcre.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov
 OBJ := a.o b.o ...
 и еще пол экрана
Вот за это бить нужно. Палкой. Больно. И долго.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Victor Wagner
On 2008.10.01 at 16:43:38 +0400, Artem Chuprina wrote:

 Безопасность JS базируется на том, что у него нет средств доступа к
 системе.  Но если у него нет средств доступа к системе, он не сможет
 этой системой рулить.


Вообще-то это не совсем так. Оно все же несколько более типизировано,
чем perl/tcl и несколько меньше зарекается на строковую подстановку.
Так что подсунуть под JS правильную объектную модель того, чем рулить, и
результат может быть весьма неплохим.

 
 Ну и движки JS'ные по размеру - perl отдыхает...
 
apt-cache show libjs0 ngs-js
Package: libjs0
Priority: optional
Section: libs
Installed-Size: 360
Maintainer: Pierre Habouzit [EMAIL PROTECTED]
Architecture: i386
Source: ngs-js
Version: 0.2.5-8
Depends: libc6 (= 2.3.6-6), libncurses5 (= 5.4-5)
...
Package: ngs-js
Priority: optional
Section: interpreters
Installed-Size: 120
Maintainer: Pierre Habouzit [EMAIL PROTECTED]
Architecture: i386
Version: 0.2.5-8
Depends: libc6 (= 2.3.6-6), libncurses5 (= 5.4-5), libjs0 (= 0.2.5-8)

360+120=480Кб

А у perl-base 1880.

 А смысл решать на получившемся винегрете задачи, которые решает awk?
 Если их на авке решать сложно, вон для желающих лаконичности есть perl,
 а для желающих ясности - tcl.  Где тут ниша для JS?

Веб-дизастеры^H^H^H^H^Hйнеры эта ниша.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Dmitry E. Oboukhov
AC OBJ := a.o b.o ...
AC и еще пол экрана
AC Вот за это бить нужно. Палкой. Больно. И долго.
самое интересное что когда я отправил патч автор его не принял
написал что ему так больше нравится, поскольку более управляемо
(дословно) :(
--
... mpd is off

. ''`.   Dmitry E. Oboukhov
: :’  :   email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED]
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature


Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov
   Если речь идет о безопасности, то начинать надо с выкидывания sh.
  Вызов внешней утилы не является дырой в безопастности.
  По крайней мере речь _сейчас_ не об этом, контект не тот.

 Дырой в безопасности является строковая подстановка с неявным
 репарсингом после неё. Чуть автор скрипта на кавычках поэкономил, и
 привет - arbitrary command execution.

Ах вот оно в чем дело. Тут согласен. Но ведь это практически только
тогда, когда eval и прочие ssh/rsh. И эти проблемы есть практически в
любом скриптовом языке. Ни в tcl ни в perl разыменование переменной не
смотрит, пуста строка, или нет. И проблема, как следствие та же.

   А Java Script безопасен только в песочнице.  Но в песочнице он
   бесполезен.
  Расшифруй.
  
  Я бы вот с удовольствием заменил awk java script-ом, если бы к нему
  добавить awk-шную data-driven логику и нормальные (POSIX compatible)

 Какие проблемы? Придумай объектную модель, реализующую эту логику и
 вперед.

Проблем, в принципе, никаких. Лениво :-)
Пока с другими игрушками не наигрался.
А по работе не особо надо.

  регулярные выражения.

 Э, а разве там они ненормальные? Они там по-моему как бы не pcre.

Это дело надо уточнить. В зависимостях на построение нет ни pcre,
ни какой бы то ни было другой внешней библиотеки. Похоже, как всегда самопал.
Надо посмотреть, что полагается по ECMA-262.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Victor Wagner
On 2008.10.01 at 17:34:46 +0300, Aleksey Cheusov wrote:

Если речь идет о безопасности, то начинать надо с выкидывания sh.
   Вызов внешней утилы не является дырой в безопастности.
   По крайней мере речь _сейчас_ не об этом, контект не тот.
 
  Дырой в безопасности является строковая подстановка с неявным
  репарсингом после неё. Чуть автор скрипта на кавычках поэкономил, и
  привет - arbitrary command execution.
 
 Ах вот оно в чем дело. Тут согласен. Но ведь это практически только
 тогда, когда eval и прочие ssh/rsh. И эти проблемы есть практически в
 любом скриптовом языке. Ни в tcl ни в perl разыменование переменной не
 смотрит, пуста строка, или нет. И проблема, как следствие та же.

Вопрос не в том, пуста строка или нет, а в том, будет ли она передана
в выполняемую внешнюю команду как один параметр, или как произвольный
набор таковых. В Tcl, если не предпринимать специальных мер, 
будет как один. В Perl, если использовать списковую форму system/exec -
как один. В shell - да хоть как двадцать восемь отдельных шелловских
команд. Главное понапихать во вводимое значение побольше точек с запятой
и бэктиков.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Victor Wagner
On 2008.10.01 at 17:57:01 +0300, Aleksey Cheusov wrote:

   любом скриптовом языке. Ни в tcl ни в perl разыменование переменной не
   смотрит, пуста строка, или нет. И проблема, как следствие та же.
 
  Вопрос не в том, пуста строка или нет, а в том, будет ли она передана
  в выполняемую внешнюю команду как один параметр, или как произвольный
  набор таковых.
 В целом я понимаю проблему, но в частностях - не вижу никакой разницы.
 
 
 0 ~cat ~/tmp/1.perl
 $str = echo trtrtr; echo brbrbr;
 system($str);

Я сказал СПИСКОВУЮ форму system.

Если там один параметр то оно вызывает shell и приехали.

Рассмотрим более реалистичный пример.

Допустим, мы ожидаем в строке имя файла и хотим его посмотреть. Для
определенности display. Злобный хакер подсовывает нам
вместо имени файла кострукцию coolchildporn.jpg; rm -rf /.

Нет, это слишком жестоко. Пусть будет

innocentpic.jpg; echo Ha-Ha, you are hacked!

Сравните результаты

$filename='innocentpic.jpg; echo Ha-Ha, you are hacked!';
system display, $filename;
и 
system display $filename;


В первом случае получаем 
display: unable to open file `innocentpic.jpg; echo Ha-Ha, you are
hacked!': No such file or directory.


Во втором Ha-Ha, you are hacked! на stdout.


 P.S.  До сих пор помню стоны товарищей, которые по работе писали на
 tcl В этом ^%$^* языке пустые строки пропадают. Это насчет передачи

Ну, Quoting hell в Tcl - это проблема известная. Лечится одним
единственным путем. Заменой кодера на заведомо исправного. Который перед
тем как начать писать на этом языке, читает man Tcl и осознает, что 
интерпретатор сделает ему ровно то, что там написано, и не более того.

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

Там надо соблюдать три (ну в 8.5 четыре) математически строгих правила.

-- 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Aleksey Cheusov
 Я сказал СПИСКОВУЮ форму 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 $filename
  и 
  display $filename

Аналогично с eval-ом.

  cmd=display \`shquote '$filename'`\
  eval $cmd

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

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Alexey Pechnikov
Hello!

В сообщении от Wednesday 01 October 2008 19:27:28 Victor Wagner написал(а):
 Там надо соблюдать три (ну в 8.5 четыре) математически строгих правила.

А что в 8.5 нужно дополнительно учесть? А то я еще не смотрел его...

Best regards, Alexey.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Victor Wagner
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 нужно дополнительно учесть? А то я еще не смотрел его...

Появившуюся возможность подстановки списков. В смысле подставить
n-элементный список в команду не как один параметр, а как n,
БЕЗ лишнего уровня evaluation для всего остального.

Еще там dictionaries появились, т.е. ассоциативные массивы как
first-class object. Если раньше массив можно было передавать только по
имени, теперь можно и по значению.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Alexey Pechnikov
Hello!

В сообщении от Wednesday 01 October 2008 23:42:18 Victor Wagner написал(а):
  А что в 8.5 нужно дополнительно учесть? А то я еще не смотрел его...

 Появившуюся возможность подстановки списков. В смысле подставить
 n-элементный список в команду не как один параметр, а как n,
 БЕЗ лишнего уровня evaluation для всего остального.

А как это делается? Когда будет раскрывать список?


 Еще там dictionaries появились, т.е. ассоциативные массивы как
 first-class object. Если раньше массив можно было передавать только по
 имени, теперь можно и по значению.

Да, на эту возможность давно облизываюсь, но пока задач не было.

Best regards, Alexey.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-10-01 Пенетрантность Victor Wagner
On 2008.10.02 at 00:06:30 +0400, Alexey Pechnikov wrote:

 Hello!
 
 В сообщении от Wednesday 01 October 2008 23:42:18 Victor Wagner написал(а):
   А что в 8.5 нужно дополнительно учесть? А то я еще не смотрел его...
 
  Появившуюся возможность подстановки списков. В смысле подставить
  n-элементный список в команду не как один параметр, а как n,
  БЕЗ лишнего уровня evaluation для всего остального.
 
 А как это делается? Когда будет раскрывать список?

Специальным синтаксисом подстановки. Что-то вроде {}$list
У меня сейчас man Tcl от 8.5 под рукой нету.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность yuri . nefedov

On Sat, 27 Sep 2008, Andrey Kiselev wrote:



Форматирование безусловно раздражает. Раздражает зависимость от shell'а.
На самом деле, много чего ещё раздражает (например, рекомендую почитать
Recursive Make Considered Harmful --- это в особенности раздражает).
Кроме этого, как и в случае с shell'ом, очень хочется иметь под рукой
более мощный язык программирования, поскольку сборка сложной системы,
особенно кроссплатформенная, частенко требует всяческих нетривиальных
действий и пляски с shell'ом и make'ом зачастую пустая трата времени.

--


  Отличная статья. Я про неё не знал, прочитал с удовольствием.
  Однако хочу обратить внимание, вот цитата из статьи:

It must be emphasized that this paper does not
suggest that make itself is the problem. This
paper is working from the premise that make does
not have a bug, that make does not have a design
flaw. The problem is not in make at all, but rather
in the input given to make - the way make is
being used.

  Пока останусь при своём мнении: майк надо уметь
  готовить. Хотя SCons надо будет попробовать...

 Ю.

Re: Нужен ли bash

2008-09-30 Пенетрантность Dmitry Fedorov
30 сентября 2008 г. 15:19 пользователь  yuri.nefedov написал:
 On Sat, 27 Sep 2008, Andrey Kiselev wrote:

 Recursive Make Considered Harmful --- это в особенности раздражает).

  Пока останусь при своём мнении: майк надо уметь
  готовить. Хотя SCons надо будет попробовать...

http://makepp.sourceforge.net/


Re: Нужен ли bash

2008-09-30 Пенетрантность Eugene V. Lyubimkin
Dmitry Fedorov wrote:
 30 сентября 2008 г. 15:19 пользователь  yuri.nefedov написал:
 On Sat, 27 Sep 2008, Andrey Kiselev wrote:

 Recursive Make Considered Harmful --- это в особенности раздражает).
  Пока останусь при своём мнении: майк надо уметь
  готовить. Хотя SCons надо будет попробовать...
 
 http://makepp.sourceforge.net/
Не увидел, чем оно лучше, чем make для написания make-файлов.

-- 
Eugene V. Lyubimkin aka JackYF



signature.asc
Description: OpenPGP digital signature


Re: Нужен ли bash

2008-09-30 Пенетрантность Artem Chuprina
[EMAIL PROTECTED] - debian-russian@lists.debian.org  @ Tue, 30 Sep 2008 
12:19:34 +0400 (MSD):

  Форматирование безусловно раздражает. Раздражает зависимость от shell'а.
  На самом деле, много чего ещё раздражает (например, рекомендую почитать
  Recursive Make Considered Harmful --- это в особенности раздражает).
  Кроме этого, как и в случае с shell'ом, очень хочется иметь под рукой
  более мощный язык программирования, поскольку сборка сложной системы,
  особенно кроссплатформенная, частенко требует всяческих нетривиальных
  действий и пляски с shell'ом и make'ом зачастую пустая трата времени.
 
  --

 y   Отличная статья. Я про неё не знал, прочитал с удовольствием.
 y   Однако хочу обратить внимание, вот цитата из статьи:

 y It must be emphasized that this paper does not
 y suggest that make itself is the problem. This
 y paper is working from the premise that make does
 y not have a bug, that make does not have a design
 y flaw. The problem is not in make at all, but rather
 y in the input given to make - the way make is
 y being used.

 y   Пока останусь при своём мнении: майк надо уметь
 y   готовить. Хотя SCons надо будет попробовать...

Мне вот тут Витус показал bras.  На первый взгляд, он интереснее.  Скунс
и waf, похоже, сильно заточены под C++ и одну конкретную модель расклада
исходников.  И написаны на питоне, что уже само по себе по ранее мною
описанным причинам для меня подозрительно.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Self-referencing
Five, seven, five syllables
This haiku contains


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Andrey Kiselev
On Mon, Sep 29, 2008 at 07:03:32PM +0300, Dmitry Nezhevenko wrote:
  Как раз в общем случае --- да, а Вы привели случай частный.
 
 У каждого свое понятие общего и частного случаев.

Да ничего подобного. Общий случай как раз указан в документация на make
и я его уже цитировал:

Command execution shall be as if the makefile command line were the
argument to the system() function.

Поэтому Ваш случай --- это лишь один из возможных вариантов.

 make -- штука достаточно универсальная. Им можно собирать софт из
 исходников, LaTeX документы, ну и др. Им же можно и шелл запускать
 (явно или неявно).

Кто с этим спорит?

 Вот тебе другой пример (который как раз выполнят то, для чего был
 придуман make):

 make тут запускает компилятор и линкер. И шелл ему тут нафиг не нужен.

С этим никто не спорит. В некоторых случаях некоторые реализации make
сумеют обойтись без шелла.

  Да, согласен, в этом случае make разберётся и выполнит команду напрямую,
  однако если записать так:
  
  all:
  sleep 60; sleep 60
 
 Cлив защитан (c). Можно было и явно тут /bin/sh вызвать. Впрочем
 ладна.. Я тоже буду передергивать =)

Никакого передёргивания нет и в помине. Явного указания на вызов шелла
не было. Тем не менее, какой святой дух подсказал make'у, что это
следует сделать? Он принял это решение, проанализировав СИНТАКСИС
команды. Самостоятельно. Более того, в документации описано, как он это
делает:

Some implementations do not use system() for all command lines, as
required by the portable makefile format; as a performance enhancement,
they select lines without shell metacharacters for direct execution by
execve(). There is no requirement that system() be used specifically,
but merely that the same results be achieved. The metacharacters
typically used to bypass the direct execve() execution have been any of:
  =  |  ^  (  )  ;*  ?  [  ] :  $  ‘  ’\  \n

К чему ещё относится это сакральное знание, как не к POSIX-шеллу?
Более того, make, вообще-то, довольно много знает про шелл. Если
написать такой makefile:

all:
test -f /etc/passwd

то он исполнит его шеллом, а не станет вызывать /usr/bin/test.

 import os
 os.system('sleep 30; sleep 30')
 
 Бидону придется вызывать шелл (и он его таки вызывает). А это значит,
 что синтаксис бидона непосредственно связан с синтаксисом POSIX-шелла.

Здесь нет синтаксического анализа исполняемой команды. Если написать

  os.system('sleep 30')

то шелл всё равно будет вызван.

 /* Дальше бред поскипан */

Вы собирались что-то ещё написать, но передумали?



-- 
Andrey V. Kiselev
ICQ# 26871517


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Alexey Pechnikov
Hello!

В сообщении от Monday 29 September 2008 10:29:05 Artem Chuprina написал(а):
 Кстати, открой для себя xtail.  tail, вообще-то, не для того
 предназначен...

Прелесть какая. Есть все, чего мне не хватало в tail.

Best regards, Alexey.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Artem Chuprina
Eugene V. Lyubimkin - debian-russian@lists.debian.org  @ Tue, 30 Sep 2008 
12:12:02 +0300:

  Recursive Make Considered Harmful --- это в особенности раздражает).
   Пока останусь при своём мнении: майк надо уметь
   готовить. Хотя SCons надо будет попробовать...
  
  http://makepp.sourceforge.net/
 EVL Не увидел, чем оно лучше, чем make для написания make-файлов.

Это ты, значит, сложных не писал...  Тому, кто писал, ключевые места
очевидны.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

The last good thing written in C was Franz Schubert's Symphony number 9.
 -- Erwin Dieterich


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Dmitry Fedorov
30 сентября 2008 г. 16:12 пользователь Eugene V. Lyubimkin написал:

 http://makepp.sourceforge.net/
 Не увидел, чем оно лучше, чем make для написания make-файлов.

1. Возможность написания make-файлов без рекурсивного вызова make
(каковой считать вредным) для подкаталогов с собственными makepp-файлами.
2. Совместимостью с GNU make (автор к этому стремится).
'use subdir/Makepp' а не include.
3. Всяческий сахар, как-то весьма продвинутые встроенные функции.


Re: Нужен ли bash

2008-09-30 Пенетрантность Dmitry E. Oboukhov
DF http://makepp.sourceforge.net/
DF Не увидел, чем оно лучше, чем make для написания make-файлов.

DF 1. Возможность написания make-файлов без рекурсивного вызова make
DF (каковой считать вредным) для подкаталогов с собственными makepp-файлами.
кстати ковыряясь с многими deb-пакетами натыкался на рекурсии в make
в 100% случаев введением дополнительных целей или зависимостей рекурсии
отлично убирались

может кто-то показать мне make-задачу/случай нерешабельный без
рекурсивного перевызова того же make?

DF 3. Всяческий сахар, как-то весьма продвинутые встроенные функции.
вот это наверно интересно
--
... mpd is off

. ''`.   Dmitry E. Oboukhov
: :’  :   email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED]
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature


Re: Нужен ли bash

2008-09-30 Пенетрантность Dmitry Nezhevenko

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 (кстати какой make? GNU?) не
работает на платформах, где нет шелла? Несмотря на то, что я привел два
примера (реальный и не очень), где make легко применяется без наличия
шелла. 

Таким образом, make может работать на платформах без шелла. Да, он не
будет поддерживать все его фичи, но он будет работать. Например, им можно
будет собирать софт из исходников :)

On Tue, Sep 30, 2008 at 01:21:10PM +0400, Andrey Kiselev wrote:
  make -- штука достаточно универсальная. Им можно собирать софт из
  исходников, LaTeX документы, ну и др. Им же можно и шелл запускать
  (явно или неявно).
 
 Кто с этим спорит?

Вы :)

 Some implementations do not use system() for all command lines, as
 required by the portable makefile format; as a performance enhancement,
 they select lines without shell metacharacters for direct execution by
 execve(). There is no requirement that system() be used specifically,
 but merely that the same results be achieved. The metacharacters
 typically used to bypass the direct execve() execution have been any of:
   =  |  ^  (  )  ;*  ?  [  ] :  $  ‘  ’\  \n

Спасибо, читал. Это лишь говорит о том, что make для некоторой части
команд (в которых используется синтаксис шелла) шелл нужен. В то же
время GNU make умеет в большей части случаев обходиться без шелла. И ни
кто не запрещает использовать в make только шелл-независимые вещи.
 
-- 
WBR, Dmitry


signature.asc
Description: Digital signature


Re: Нужен ли bash

2008-09-30 Пенетрантность Artem Chuprina
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 (каковой считать вредным) для подкаталогов с собственными
 DF makepp-файлами.
 DEO кстати ковыряясь с многими deb-пакетами натыкался на рекурсии в
 DEO make в 100% случаев введением дополнительных целей или
 DEO зависимостей рекурсии отлично убирались

У deb-пакетов есть одна особенность.  Они _как правило_ собираются
один раз после clean.  Задача обеспечить адекватную сборку с минимумом
затрат после мелких изменений у них не стоит, у них стоит задача
гарантированно обеспечить однократную сборку с нуля.

Эта задача прекрасно решается рекурсивным вызовом make, никаких проблем
он при этом не создает.

Но вообще мне довольно сложно себе представить, как ты без рекурсивного
вызова make одним лишь введением дополнительных целей или зависимостей
собираешь проект, расположенный по нескольким директориям, где у каждой
директории свой makefile.  Причем, что характерно, поскольку
debian/rules - это мейкфайл, любой дебиановский пакет, если оригинал
собирается мейком, будет дергать рекурсивный вызов.  Можно показать
пример такого пакета, который без рекурсивного вызова обходится?

Нет, _в теории_ можно переписать оригинальные мейкфайлы так, чтобы.
Может быть, в большинстве случаев (там, где мейкфайл генерируется гнутой
конфигурой, и потому туп как пятка, ибо специально сделан пригодным для
любого мейка, и стандартен), это даже делается в полном автопилоте.

Но, к сожалению, гнутая конфигура тоже _гарантированно_ решает только
задачу однократной сборки с чистого листа.  Ну и мелких патчей, если
повезет.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

У кошки четыре ноги: ввод, вывод, земля и питание.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Dmitry Fedorov
30 сентября 2008 г. 18:50 пользователь Dmitry E. Oboukhov  написал:
 DF http://makepp.sourceforge.net/

 кстати ковыряясь с многими deb-пакетами натыкался на рекурсии в make
 в 100% случаев введением дополнительных целей или зависимостей рекурсии
 отлично убирались

 может кто-то показать мне make-задачу/случай нерешабельный без
 рекурсивного перевызова того же make?

Оно решабельно без рекурсии, но я не хочу решать это таким способом.

0. Мои makefiles гладкие, все общие правила и определения переменных
вынесены во включаемые defs.make и rules.make
и они параметризуются использующим их Makefile через определения
управляющих переменных.

1. Каждый непустой подкаталог проекта имеет свой makefile
со своими особенностями (типом подпроекта) и мне нужны
пространства имен для управляющих переменных.

Для обычного (традиционного) make я не вижу другого способа, кроме
рекурсивного вызова make.

2. Я не хочу засорять корневой makefile проекта явным включением
makefiles подкаталогов, делая как бы namespace префиксами в именах
переменных да и вручную перечислять файлы я тоже не хочу.

И так, решается это всё одним из следующих способов:

0. Рекурсивно вызываем make. Признано вредным.

1. Генерим Makefiles. Но тогда мы неправильно выбрали инструмент и
этот make не нужен, а нужен тот язык, из которого makefiles генерятся.
Причем тут make вообще?

2. Используем другие make-подобные утилиты: SCons, makepp, ...
где можно без рекурсии и есть namespaces.


Re: Нужен ли bash

2008-09-30 Пенетрантность Dmitry E. Oboukhov
AC Но вообще мне довольно сложно себе представить, как ты без рекурсивного
AC вызова make одним лишь введением дополнительных целей или зависимостей
AC собираешь проект, расположенный по нескольким директориям, где у каждой
AC директории свой makefile.
вызов внешнего makefile это отнюдь не рекурсивный вызов


AC Причем, что характерно, поскольку
AC debian/rules - это мейкфайл, любой дебиановский пакет, если оригинал
AC собирается мейком, будет дергать рекурсивный вызов.
в энциклопедию, читать определение слова рекурсия

--
... mpd is off

. ''`.   Dmitry E. Oboukhov
: :’  :   email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED]
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature


Re: Нужен ли bash

2008-09-30 Пенетрантность Dmitry Fedorov
30 сентября 2008 г. 19:49 пользователь Dmitry E. Oboukhov написал:

 рекурсивного вызова make

 вызов внешнего makefile это отнюдь не рекурсивный вызов

Вызывается точно такая же утилита make с другим makefile.

 в энциклопедию, читать определение слова рекурсия

В данном контексте (читать определение слова контекст)
одна программа make вызывает программу make, точно такую-же.


Re: Нужен ли bash

2008-09-30 Пенетрантность Aleksey Cheusov
 Eugene V. Lyubimkin - debian-russian@lists.debian.org  @ Tue, 30 Sep 2008 
 12:12:02 +0300:

  Recursive Make Considered Harmful --- это в особенности раздражает).
   Пока останусь при своём мнении: майк надо уметь
   готовить. Хотя SCons надо будет попробовать...
  
  http://makepp.sourceforge.net/
 EVL Не увидел, чем оно лучше, чем make для написания make-файлов.

 Это ты, значит, сложных не писал...  Тому, кто писал, ключевые места
 очевидны.

А зачем, пардон, писать сложные Makefile-ы?  Надо писать простые.

Ну можно ли проще?

   PROG = myprog
   SRCS = file1.c file2.c

   .include bsd.prog.mk

И ведь оно уже все умеет.

Для простых проектов и проектов средней величины нет ничего лучше
 MK-скриптов BSD make-а IMHO.

Интересно, есть ли в природе аналог mk скриптам для GNU make-а?

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Dmitry Fedorov
30 сентября 2008 г. 20:42 пользователь Aleksey Cheusov написал:
 А зачем, пардон, писать сложные Makefile-ы?

Для сложных задач.
А любая задача - не такая уж простая.

 Надо писать простые.

 Ну можно ли проще?

   PROG = myprog
   SRCS = file1.c file2.c

   .include bsd.prog.mk

Можно:

PROG_NAME = myprog
BUILD_TYPE = MULTI_SRC_BIN
include $(DEFS)

# а тут ваши дополнительные правила, если нужно

include $(RULES)



 И ведь оно уже все умеет.

Не всё - само список файлов не составляет, приходится руками вводить.

 Для простых проектов и проектов средней величины нет ничего лучше
  MK-скриптов BSD make-а IMHO.

Вот-вот - используют makefiles вместо скриптов
и скрипты вместо makefiles.

 Интересно, есть ли в природе аналог mk скриптам для GNU make-а?

mk-СКРИПТЫ - не интересуют. Назовите по другому.


Re: Нужен ли bash

2008-09-30 Пенетрантность Alexey Pechnikov
Hello!

В сообщении от Tuesday 30 September 2008 16:00:34 Dmitry Nezhevenko 
написал(а):
 Это лишь говорит о том, что make для некоторой части
 команд (в которых используется синтаксис шелла) шелл нужен. В то же
 время GNU make умеет в большей части случаев обходиться без шелла. И ни
 кто не запрещает использовать в make только шелл-независимые вещи.

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

P.S. А нет ли у вас ссылочки на грамотное руководство по созданию make-файлов, 
не привязанных к шеллу? Хотелось бы понять, есть ли в этом смысл или 
полученные мэйкфайлы непригодны на практике.

Best regards, Alexey.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Alexey Pechnikov
Hello!

В сообщении от Tuesday 30 September 2008 15:25:30 Dmitry Fedorov написал(а):
  http://makepp.sourceforge.net/
 
  Не увидел, чем оно лучше, чем make для написания make-файлов.

 1. Возможность написания make-файлов без рекурсивного вызова make
 (каковой считать вредным) для подкаталогов с собственными makepp-файлами.
 2. Совместимостью с GNU make (автор к этому стремится).
 'use subdir/Makepp' а не include.
 3. Всяческий сахар, как-то весьма продвинутые встроенные функции.

Еще один язык программирования? Все-таки вызов внешнего шелла как вынужденная 
необходимость потихоньку отмирает.

Best regards, Alexey.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Dmitry Fedorov
30 сентября 2008 г. 21:12 пользователь Alexey Pechnikov написал:

 В сообщении от Tuesday 30 September 2008 15:25:30 Dmitry Fedorov написал(а):
  http://makepp.sourceforge.net/

 Еще один язык программирования?

Да. И? Make тоже язык программирования.
Причём. rule-based expert system :)

 Все-таки вызов внешнего шелла как вынужденная
 необходимость потихоньку отмирает.

Не вижу связи.
Если бы я проектировал make, шелл бы вызывался только по явному
указанию пользователя. Или не шелл.


Re: Нужен ли bash

2008-09-30 Пенетрантность Dmitry Nezhevenko
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 умеет в большей части случаев обходиться без шелла. И ни
  кто не запрещает использовать в make только шелл-независимые вещи.
 
 В большинстве случаев шелл таки нужен. 

Опять же большинство -- понятие относительное ;) В любом случае make можно
применять без шелла для решения определенного круга задач (достаточно
немалого). 

Например, Makefile, которые генерирует Qt-ный qmake, в GNU make не
используют шелл. А это уже достаточно большая куча софта.

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

А я где-то говорил, что нужно переделывать мейкфайлы для всего
существующего софта? И опять же make нужен не только для сборки софта.

 P.S. А нет ли у вас ссылочки на грамотное руководство по созданию 
 make-файлов, 
 не привязанных к шеллу? Хотелось бы понять, есть ли в этом смысл или 
 полученные мэйкфайлы непригодны на практике.
 

Нету. В качестве начала могу предложить не использовать символы:

 The metacharacters typically used to bypass the direct execve()
 execution have been any of: =  |  ^  (  )  ;*  ?  [  ] :  $
 ‘  ’\  \n

Фичи шелла в make нужны далеко не всегда.

-- 
WBR, Dmitry


signature.asc
Description: Digital signature


Re: Нужен ли bash

2008-09-30 Пенетрантность Andrey Kiselev
On Tue, Sep 30, 2008 at 03:00:34PM +0300, Dmitry Nezhevenko wrote:
   назови платформу где не работает make?
  
  Любая, на которой не работает shell.
 
 Это Ваши слова?
  
 Вы все еще продолжаете утверждать, что make (кстати какой make? GNU?)
 не работает на платформах, где нет шелла? Несмотря на то, что я привел
 два примера (реальный и не очень), где make легко применяется без
 наличия шелла. 

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

 Таким образом, make может работать на платформах без шелла. Да, он не
 будет поддерживать все его фичи, но он будет работать. Например, им
 можно будет собирать софт из исходников :)

Соберите мне GNU hello без шелла.

   make -- штука достаточно универсальная. Им можно собирать софт из
   исходников, LaTeX документы, ну и др. Им же можно и шелл запускать
   (явно или неявно).
  
  Кто с этим спорит?
 
 Вы :)

Неправда. Где я сказал, что мейком нельзя собирать что-то из исходников
или компилировать документы LaTeX? Я утверждаю только, что эта система
сборки непереносима, т.к. вплотную завязана на шелл.

  Some implementations do not use system() for all command lines, as
  required by the portable makefile format; as a performance enhancement,
  they select lines without shell metacharacters for direct execution by
  execve(). There is no requirement that system() be used specifically,
  but merely that the same results be achieved. The metacharacters
  typically used to bypass the direct execve() execution have been any of:
=  |  ^  (  )  ;*  ?  [  ] :  $  ‘  ’\  \n
 
 Спасибо, читал. Это лишь говорит о том, что make для некоторой части
 команд (в которых используется синтаксис шелла) шелл нужен. В то же
 время GNU make умеет в большей части случаев обходиться без шелла. И
 ни кто не запрещает использовать в make только шелл-независимые вещи.

Так ведь это как раз и есть непереносимость. Стандарт говорит: правила
исполняются шеллом. Значит, шелл должен быть. Правда
_некоторые_реализации_ могут исполнить _часть_ команд и без шелла, но
это всего лишь частный случай, особенность реализации. Такой мейкфайл
можно написать, но произвольный мейкфайл, взятый наугад из произвольного
проекта с вероятностью 99,9% таким свойством обладать не будет.


-- 
Andrey V. Kiselev
ICQ# 26871517


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Aleksey Cheusov
  может кто-то показать мне make-задачу/случай нерешабельный без
  рекурсивного перевызова того же make?

 Оно решабельно без рекурсии, но я не хочу решать это таким способом.
И я что-то склоняюсь к тому, что рекурсия не так плоха для типичных
проектов.

 0. Мои makefiles гладкие, все общие правила и определения переменных
 вынесены во включаемые defs.make и rules.make
 и они параметризуются использующим их Makefile через определения
 управляющих переменных.
JFYI: именно так и делается в MK скриптах BSD make-а.
bsd.prog.mk
bsd.lib.mk
bsd.subdirs.mk
...

Для GNU make-а по-моему аналог отсутствует. А жаль.
Возможно потому, что в GNU make нет нормальной удобной директивы .for
как в BSD make-е.

GNU make-овский eval - это чудовищное уродство.

 1. Каждый непустой подкаталог проекта имеет свой makefile
 со своими особенностями (типом подпроекта)
см. выше. Особенности - это тип включаемого инклюда.

 0. Рекурсивно вызываем make. Признано вредным.
Непризнано. Это всего лишь мнение одного или группы разработчиков.

 1. Генерим Makefiles.
Это будет кошмар :)

 2. Используем другие make-подобные утилиты: SCons, makepp, ...
 где можно без рекурсии и есть namespaces.
Есть сомнение, что оно того стоит.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Andrey Kiselev
On Tue, Sep 30, 2008 at 05:30:01PM +0300, Dmitry Nezhevenko wrote:
  P.S. А нет ли у вас ссылочки на грамотное руководство по созданию
  make-файлов, не привязанных к шеллу? Хотелось бы понять, есть ли в
  этом смысл или полученные мэйкфайлы непригодны на практике.
 
 Нету. В качестве начала могу предложить не использовать символы:
 
  The metacharacters typically used to bypass the direct execve()
  execution have been any of: =  |  ^  (  )  ;*  ?  [  ] :  $
  ‘  ’\  \n

...а также целый ряд ключевых слов-встроенных команд шелла (в случае GNU
make). Причём список метасимволов и ключевых слов ещё и разный на разных
платформах (прекрасная переносимость!). Детали смотреть в исходниках:

http://www.google.com/codesearch?hl=ruq=show:WVlsTmrp7Lk:KX8ooB_G96Q:EDKUAV5sQywsa=Nct=rdcs_p=ftp://ftp.gnu.org/gnu/make/make-3.81.tar.bz2cs_f=make-3.81/job.c

Искать sh_chars/sh_cmds.


-- 
Andrey V. Kiselev
ICQ# 26871517


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Dmitry E. Oboukhov
DF рекурсивного вызова make

DF вызов внешнего makefile это отнюдь не рекурсивный вызов

DF Вызывается точно такая же утилита make с другим makefile.
это не рекурсия, это новый процесс.
от любого другого компилятора не отличается ничем

новый процесс make - совершенно независимый, переменные передаются
только явно

makefile - суть скрипт
рекурсия - вызов себя же (то есть того же makefile)

а если говорить о make, то по этой аналогии получится и sh рекурсивный и
тикль и perl и питон и тд итп

все что использует вызов system может вызвать аналогичный объект, но
никому в голову не приходит назвать шелл рекурсивным только на том
основании что из одного скрипта кто-то вызвает _другой_.
--
... mpd is off

. ''`.   Dmitry E. Oboukhov
: :’  :   email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED]
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature


Re: Нужен ли bash

2008-09-30 Пенетрантность Aleksey Cheusov
 А любая задача - не такая уж простая.
Вот именно в этом есть сомнение.
Может дело в подходе? ;-)

 PROG_NAME = myprog
 BUILD_TYPE = MULTI_SRC_BIN
 include $(DEFS)

 # а тут ваши дополнительные правила, если нужно

 include $(RULES)
Это абсолютно то же самое. Переизобретенный велосипед.
Не говорю, что плохой или хороший, но переизобретение уже готового налицо.

  И ведь оно уже все умеет.

 Не всё - само список файлов не составляет, приходится руками вводить.
Да не приходится. Если исходный файл один - достаточно указать просто PROG.
Если больше, можно SRCS!= echo *.c
Если echo не нравится, его можно спрятать в myownrules.mk
Подход от этого не меняется.

  Для простых проектов и проектов средней величины нет ничего лучше
   MK-скриптов BSD make-а IMHO.

 Вот-вот - используют makefiles вместо скриптов
 и скрипты вместо makefiles.
make - это и есть язык программирования. В чем-то уникальный, в чем то
декларативный. На нем тоже программируют. В этом нет ничего плохого.
И здесь я не вижу никаких противоречий.

  Интересно, есть ли в природе аналог mk скриптам для GNU make-а?

 mk-СКРИПТЫ - не интересуют. Назовите по другому.
Что назвать по-другому? Что не интересует? Ничего не понял.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Aleksey Cheusov
 Еще один язык программирования? Все-таки вызов внешнего шелла как вынужденная 
 необходимость потихоньку отмирает.
Я думаю, вы выдаете желаемое за действительное.  Я лично считаю вызов
внешнего шела гораздо более правильной практикой по сравнению с
изобретением собственных недоязыков программирования.

А вызвать внешний shell ничем не хуже, чем дернуть встроенный
интерпретатор java script, lua, scheme, lisp etc.
Но и то и другое лучше изобретения велосипедов.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Нужен ли bash

2008-09-30 Пенетрантность Grey Fenrir
On Fri, 26 Sep 2008 18:02:52 +0400
Artem Chuprina wrote:

  AC Почему не может?  Может.  Первый не-опциональный аргумент
  AC командной строки заканчивает список опций.
  DEO так это и растет от того что НЕ может
 
 Нет.  Это растет из того, что так специфицировано.
 
 Гнутая утилита, кстати, тоже не поймет ключа в конце, если в середине
 было сказано --...
 
Не драки ради, а токмо для самообразования.
Любопытно, как _негнутые_ утилиты обработают, скажем, файл с именем -f
Как справится гнутая (команда ключи -- файлы) мне понятно, а
какие есть инструменты для этого в стандарте?
Разумеется, если не использовать финты с указанием путей.
 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



  1   2   3   4   5   6   7   >