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

Согласно нескольким источникам , в руководящих указаниях 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} 

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

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

  • Есть ли опция с командой ls, которую я вижу только в каталогах?
  • Откуда берется команда «экспорт»?
  • TUI Tool для изменения правил разрешения каталога?
  • Как изменить длину строки по умолчанию для od и hexdump
  • tr аналог для символов Unicode?
  • Есть ли независимый от дистрибутива инструмент для автокомпиляции + установки зависимостей?
  • Когда `sort -k 2,3b` и` sort -k 2,3` отличаются?
  • Пакеты и т. П. Для настройки новых систем
  • Как использовать утилиту командной строки ul
  • альтернативы wgetpaste?
  • Сравнение образцов .wav из командной строки
  • Linux и Unix - лучшая ОС в мире.