AK>>>>> ssh host ls -A AK>>>> AK>>>>> "правильная" утилита (ssh в данном случае) должна понимать -A как ключ AK>>>>> ls или как ключ ssh? Ответ обосновать. AK>>>> как ключ ls, ибо это команда в команде AK>> AK>>> Становится страшно за Debian, раз у него пояляются разработчики, AK>>> выдающие такие перлы. AK>> AK>>>> и в линуксе это прекрасно работает AK>> AK>>> В линуксе это работает вот так: AK>> в линуксе _другой_ ssh чем в BSD? нет? а в чем вопрос?
AK> Я не вижу смысла продолжать разговор. Вы либо придуриваетесь, либо AK> демонстрируете чудовищную некомпетентность. вот придуриваешься как раз ты смотри: ты говоришь "это неправильно поскольку не будет работать" я прошу пример ты начинаешь что-то про ssh я спрашиваю "в линуксе другой ssh? или в линуксе он не работает?" ты не видишь смысла продолжать разговор. странная логика, вернее полное ее отсутствие :( AK> ssh НЕ БУДЕТ РАБОТАТЬ с AK> линуксовым getopt, но работает? работает читд а то как он там внутрях реализован дело десятое если разработчики ssh сами парсят опции то это значит что getopt их не устроил никакой AK> т.к. этот getopt не соотвествует стандарту и под него AK> надо специально адаптироваться. стандарт тут вообще не при чем AK> И примеров таких программ, которые не смогут нормально работать с getopt AK> из glibc, можно привести множество. Это все программы, с синтаксисом AK> командной строки вида эти все программы под линуксом РАБОТАЮТ. как это решается внутри них мало кого волнует, важно что этих программ на фоне остальных - считанные проценты, а остальные теперь стали гораздо УДОБНЕЕ в использовании -- . ''`. Dmitry E. Oboukhov : :’ : [EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
signature.asc
Description: Digital signature
