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

Question

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

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

  myutil --longname

  myutil /longname

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

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

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

Другой проблемой кросс-платформенного переключателя, которая кажется немного странной, является "явное выключение", когда трейлинг "-msgstr "явно идентифицирует переключатель как" выключенный ":

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

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

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

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

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

  myutil -v-

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

  myutil -q

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

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

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

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

Answer 1

Я никогда не слышал о трейлинг - для выключения выключателя. В UNIX-земле, он использует перед ним no- как в --no-verbose выключает --verbose, По крайней мере, Руби 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Документация (при условии, что она вообще существует), чтобы знать, что здесь происходит.