Следует ли считать «явное отключение» переключателя командной строки вредным?

Question

Мы стараемся следовать «стандартам» как можно лучше для обработки аргументов и переключений из командной строки. Например, по умолчанию мы используем стандарты Posix2 и GNU для анализа командной строки.

Однако, поскольку наши утилиты являются кроссплатформенными, и мы хотим, чтобы они были доступны из кроссплатформенных скриптов, мы также стараемся быть «надежными». Итак, мы неявно разрешаем обе формы:

  myutil --longname

  myutil /longname

Это не идеально во всех случаях, так как это может быть несколько неоднозначно, например, поддержка Posix для свертывания «коротких» имен переключателей (это одно и то же):

  myutil -abcd
  myutil -a -b -c -d
  myutil /a /b /c /d

(... мы не поддерживаем свертывание "коротких имен" на платформах Win, потому что это неоднозначно.)

Еще одна проблема кроссплатформенного переключателя, которая кажется немного странной, - это переключатель «явное выключение», где завершающий «-» явно определяет переключатель как «выключенный»:

  myutil -a-
  myutil --longname-
  myutil /a-
  myutil /longname-

Это однозначно, поэтому мы решили, что это приемлемо. («Явное выключение» из «/a/» и «/longname/» выглядело действительно странно, поэтому мы использовали конечный «-» как «кроссплатформенный внутренний стандарт».)

Напомним, что это историческое «явное отключение» для переключателей иногда было полезно явно «отключить» значение, которое по умолчанию установлено на «вкл», или удалить переключатель, который ранее мог быть добавлен к существующей командной строке. собран (например, при сборке командной строки из скрипта, где позднее принимается решение «удалить» ранее добавленный ключ).

ОДНАКО, после проверки: Может ли этот «явный выключатель» считаться вредным (плохая форма)?

Например, если утилита по умолчанию имеет значение «-v» (--verbose) как «вкл», у нас может быть « отрицательный переключатель » для его отключения :

  myutil -v-

... или мы можем просто определить "-q" (--quiet) как " положительный переключатель ", который неявно включает " вкл"a" quiet"(что подразумевает" off"для переключателя" -v "):

  myutil -q

Конечно, для любой данной утилиты было бы избыточным для поддержки форм "-v-" и "-q", так как они делали бы то же самое. (В этом примере другим вариантом будет несколько «многословных уровней», при этом один уровень будет «тихим», но цель состоит в том, чтобы проиллюстрировать природу «включения / выключения» явного отключения переключателя.)

После исчерпывающего поиска в Интернете, который потратил слишком много времени, кажется, что переключатель "явное отключение" в наши дни в значительной степени утратил популярность (например, он даже не упоминается в (Gnu) "стандартах" для интерфейсов командной строки ". )

ВОПРОС: Следует ли считать историческое «явное выключение» для переключателей вредным?

Вместо того, чтобы поддерживать «отрицательный ключ», должны ли новые утилиты командной строки вместо этого «положительный ключ» или параметр командной строки для включения в качестве «хорошей формы»?) Если это так, Есть ли еще причина поддерживать «явное отключение» переключателей (для новых утилит, созданных сегодня)?

Answer 1

Я никогда не слышал о трейлинге - за выключение переключателя.В UNIX-земле используется предшествующее ему no-, как в --no-verbose отключается --verbose.По крайней мере, Ruby's OptionParser поддерживает это напрямую;не уверен насчет других.

Что касается этого паттерна "быть вредным": абсолютно нет.Всегда хорошо иметь свободный интерфейс строки комментариев.Рассмотрим более разрушительную опцию, например --force, которая перезаписывает существующие файлы.Рассмотрим далее схему, в которой пользователь может указать свои параметры командной строки по умолчанию для данной команды.Теперь, если она настроена на --force для включения по умолчанию;как отключить его в каждом конкретном случае?

Мы не хотим, чтобы она редактировала свой конфигурационный файл, чтобы отключить --force, поэтому мы предоставляем --no-force, чтобы переопределить его.

Отрицательные параметры длинных форм также могут быть полезны в других сценариях или crontabs, чтобы прояснить, что происходит:

3 * 1 * * awesome_script.sh --force my_files
0 * * * * awesome_script.sh --no-force my_files

Бедному сисадмину, который должен поддерживать это, не нужно будет охотитьсядля документации awesome_script.sh (при условии, что она вообще существует), чтобы знать, что здесь происходит.