Почему некоторые утилиты анализируют операнды перед настройками?

Согласно нескольким источникам , в руководящих указаниях UNIX указывается, что операнды всегда должны обрабатываться после опций:

utility_name[OPTIONS][operands...] 

Известно, что некоторые устаревшие утилиты UNIX не следуют этим соглашениям, например, find , но более новые и хорошо зарекомендовавшие себя утилиты также нарушают правила без очевидного объяснения, например curl <url> .

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

One Solution collect form web for “Почему некоторые утилиты анализируют операнды перед настройками?”

Обычным соглашением является то, что аргументы всегда следуют за параметрами. Первая не-опция (первая строка в командной строке, которая не начинается с - ) завершает параметры и начинает аргументы.

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

Это соглашение позволяет вам написать сценарий оболочки, который содержит такую ​​строку:

 rm foobar ${more_things_to_remove} 

… и гарантируем, что вы не можете случайно добавить опции в команду rm даже если переменная shell more_things_to_remove имеет неприятное значение, например « -rf ».

Эта конвенция предшествует более позднему соглашению об использовании специального варианта -- прекратить обработку опций. -- это гораздо лучший способ четко обозначить конец опций:

 rm -- foobar ${more_things_to_remove} # and it works even if you don't need to delete something called "foobar": rm -- ${more_things_to_remove} 

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

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

  • Измените значение xml uttribut документа xml с помощью селектора
  • свободный вывод команды: gentoo (redhat?) vs debian
  • Как добавить несколько задач в одну команду на Taskwarrior?
  • Проверка порядка элементов в переменной среды оболочки
  • Существуют ли какие-либо инструменты cli для рисования графики на экране во время X-сессии?
  • Как я могу использовать sed для замены многострочной строки?
  • Вывести изменения в файл журнала
  • Почему в / bin есть сочетание символических ссылок и hardlinks?
  • Понимание вывода команды `who -a`
  • Как использовать утилиту командной строки ul
  • В чем разница между встроенной командой и тем, что нет?
  • губка из moreutils - в чем разница с перенаправлением оболочки? полезные примеры?
  • Linux и Unix - лучшая ОС в мире.