[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Нужен ли bash



 >>> getopt-то у юниксов(tm) стандартный.  Но вот применяется он, вместе
 >>> с этими юниксами(tm), только по дальним пыльным углам.
 AC>> Он применяется абсолютно везде, а не только по пыльным углам.

> Он не может применяться везде, поскольку наличествует только в юниксах,
> применяемых по пыльным углам.  Ну, может, фрюха еще под кроватью
> попадается...

Понятненько. Пошло мерянье пиписьками. Обухову это простительно.  Но и
ты туда же?.. И чем современный линупс отличается в таком случае от
M$.  Те тоже измывались над kerberos и не только с лучшими
намерениями. И у них тоже есть на то обоснование, и не одно.

 >>> И то бинарники там гнутые через один...
 AC>> Лицензия позволяет, а в чем проблема то? Мы не на ЛОРе.

> Ну, сиречь не соблюдающие этого стандарта.

Расшифруй.

 >>> И смысл с этим стандартом совмещаться?  Чем плох гнутый getopt,
 >>> понятно - ssh, sudo, cdrecord...  Твой пример с -eq мне
 >>> представляется искусственным, а эти три вполне понятны.
 AC>> Я уже говорил неоднократно, твой пример хорош, он более типичен
 AC>> и распространен.
 AC>> Но мой от этого не становится искуственным.
 AC>> Мы что, в детском саду?

> Эээ...  Покажи мне хотя бы одну программу с таким синтаксисом.  test не
> годится, у него нет [OPTIONS].

Ну просто ясельная группа какая-то.

 >>> У данного конкретного есть другая ценность, но все же если выбирать
 >>> между гнутым решением с перестановкой и длинными опциями и стандартным
 >>> без перестановки и с короткими - я бы предпочел гнутый.
 AC>> А слабо предпочесть вариант, который предлагает _расширение_,
 AC>> которое не ломает стандарт, а?

> Ключевое слово - "если".

Расшифруй. Я повторю вопрос. Что мешает принимать решения, основываясь
не на соображениях типа "мы ничего никогда не возьмем от бздюков,
просто из нашего прЫнцыпа, Мы и только Мы всех умнее, всей красивее и
белее _по определению_", а основавываясь на на технических соображениях?

hint: Покажи как мне, к примеру, в GNU utils 'sed -E' или 'xargs -J'.

 AC>> Неужели так дорога священная корова "_своё потому что GNU_", что
 AC>> напрочь отключает в голове здравый смысл?  Скажем, добавляем
 AC>> getopt_long, но при этом не проявляем сверхествественного
 AC>> интеллекта по перестановке аргументов? Именно так и сделали _все_
 AC>> *BSD давным давно.  В данном конкретном примере *BSD-ники (включая
 AC>> Mac OS-X) сделали совершенно логично и правильно.  Точно так же как
 AC>> _все_ *BSD и GNU-шники/Linux-оиды переняли в свое время OpenBSD-ные
 AC>> find -print0 и xargs -0.

> Видишь ли, в чем фигня...  Оно к libc прибито гвоздями.

Это намек на GNU-тый getdelim(3)? Насколько я знаю, рассматривается в
качестве расширения текущего стандарта, наравне с getline(3). В любом
случае, не понятно, о чем ты. Тому, кто хотел реализовать xargs -0 не
помешало отсутствие getdelim в libc.

> Посмотрел повнимательнее man 3 getopt.  И там можно выбирать.
Ты посмотрел в man GNU getopt. Теперь посмотри (пальцем в небо) в ман
Mac OS-X. И представь, что разрабатываешь софт сидя в Mac OS X.
И такие простые вещи нужно разжевывать? Людям, чей код почти ушел
в апстрим openssl??? Это упорство мне не понятно.

 >>>Тем более что в наше время частенько в мане описаны сильно не все
 >>>опции...
 AC>> В правильных местах описаны все до единой.

> Покажи мне, пожалуйста, правильное место для openssl.  Нет, не те
> его маны, которые правились мной лично именно на этот предмет...
Значит openssl - место неправильное. Но ты ведь его уже починил, правда?

-- 
Best regards, Aleksey Cheusov.


Reply to: