>>> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]