Общие сведения о синтаксисе командной строки для System.CommandLine

В этой статье объясняется синтаксис командной строки, который System.CommandLine распознает. Эти сведения будут полезны пользователям, а также разработчикам приложений командной строки .NET, включая интерфейс командной строки .NET.

Токены

System.CommandLine анализирует входные данные командной строки в маркеры, которые являются строками, разделенными пробелами. Например, рассмотрим следующую командную строку:

dotnet tool install dotnet-suggest --global --verbosity quiet

Эти входные данные анализируются приложением dotnet в маркеры tool, install, , dotnet-suggest, --verbosity--globalи quiet.

Маркеры интерпретируются как команды, параметры или аргументы. Вызываемое приложение командной строки определяет, как маркеры после первого интерпретируются. В следующей таблице показано, как System.CommandLine интерпретирует предыдущий пример:

Маркер	Синтаксический анализ как
tool	Подкоманда
install	Подкоманда
dotnet-suggest	Аргумент для команды установки
--global	Параметр для команды установки
--verbosity	Параметр для команды установки
quiet	Аргумент для --verbosity параметра

Маркер может содержать пробелы, если он заключен в кавычки ("). Приведем пример:

dotnet tool search "ef migrations add"

Команды

Команда во входных данных командной строки — это маркер, указывающий действие или определяющий группу связанных действий. Например:

• В dotnet run— run это команда, указывающая действие.
• В dotnet tool install— install это команда, указывающая действие, и tool является командой, указывающей группу связанных команд. Существуют другие команды, связанные с инструментами, например tool uninstall, tool listи tool update.

Корневые команды

Корневая команда — это команда, указывающая имя исполняемого файла приложения. Например, dotnet команда задает исполняемый файл dotnet.exe .

Подкоманды

Большинство приложений командной строки поддерживают вложенные команды, также называемые командами. Например, команда dotnet имеет run подкоманда, который вызывается путем ввода dotnet run.

Подкомандам могут иметь собственные подкоманда. В dotnet tool install, install является подкоманда tool.

Параметры

Параметр — это именованный параметр, который можно передать команде. CLIs POSIX обычно префиксирует имя параметра с двумя дефисами (--). В следующем примере показаны два варианта:

dotnet tool update dotnet-suggest --verbosity quiet --global
                                  ^---------^       ^------^

Как показано в этом примере, значение параметра может быть явным (quiet для --verbosity) или неявным (ничего не следует --global). Параметры, не имеющие указанного значения, обычно являются логическими параметрами, которые по умолчанию указываются true в командной строке.

Для некоторых приложений командной строки Windows можно определить параметр с помощью начальной косой черты (/) с именем параметра. Например:

msbuild /version
        ^------^

System.CommandLine поддерживает соглашения о префиксе POSIX и Windows. При настройке параметра укажите имя параметра, включая префикс.

Аргументы

Аргумент — это значение, переданное параметру или команде. В следующих примерах показан аргумент параметра verbosity и аргумент для build команды.

dotnet tool update dotnet-suggest --verbosity quiet --global
                                              ^---^

dotnet build myapp.csproj
             ^----------^

Аргументы могут иметь значения по умолчанию, которые применяются, если аргумент явно не указан. Например, многие параметры являются неявно логическими параметрами с значением по умолчанию true , если имя параметра находится в командной строке. Ниже приведены примеры командной строки:

dotnet tool update dotnet-suggest --global
                                  ^------^

dotnet tool update dotnet-suggest --global true
                                  ^-----------^

Некоторые параметры имеют обязательные аргументы. Например, в .NET CLI --output требуется аргумент имени папки. Если аргумент не указан, команда завершается ошибкой.

Аргументы могут иметь ожидаемые типы и System.CommandLine отображать сообщение об ошибке, если аргумент не может быть проанализирован в ожидаемый тип. Например, следующие ошибки команды, так как "silent" не является одним из допустимых значений для --verbosity:

dotnet build --verbosity silent

Cannot parse argument 'silent' for option '-v' as expected type 'Microsoft.DotNet.Cli.VerbosityOptions'. Did you mean one of the following?
Detailed
Diagnostic
Minimal
Normal
Quiet

Аргументы также ожидают, сколько значений можно предоставить. Примеры приведены в разделе об arity аргумента.

Порядок параметров и аргументов

Вы можете указать параметры перед аргументами или аргументами перед параметрами в командной строке. Следующие команды эквивалентны:

dotnet add package System.CommandLine --prerelease
dotnet add package --prerelease System.CommandLine

Параметры можно указать в любом порядке. Следующие команды эквивалентны:

dotnet add package System.CommandLine --prerelease --no-restore --source https://api.nuget.org/v3/index.json
dotnet add package System.CommandLine --source https://api.nuget.org/v3/index.json --no-restore --prerelease

Если имеется несколько аргументов, порядок имеет значение. Следующие команды не обязательно эквивалентны:

myapp argument1 argument2
myapp argument2 argument1

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

Aliases

В POSIX и Windows обычно используются некоторые команды и параметры для псевдонимов. Обычно это короткие формы, которые проще вводить. Псевдонимы также можно использовать для других целей, таких как имитация нечувствительности регистра и поддержка альтернативных орфографии слова.

Короткие формы POSIX обычно имеют один ведущий дефис, за которым следует один символ. Следующие команды эквивалентны:

dotnet build --verbosity quiet
dotnet build -v quiet

Стандарт GNU рекомендует автоматические псевдонимы. То есть можно ввести любую часть команды длинной формы или имени параметра, и она будет принята. Это поведение приведет к эквиваленту следующих команд:

dotnet publish --output ./publish
dotnet publish --outpu ./publish
dotnet publish --outp ./publish
dotnet publish --out ./publish
dotnet publish --ou ./publish
dotnet publish --o ./publish

System.CommandLine не поддерживает автоматические псевдонимы.

Учет регистра

Имена команд и псевдонимов по умолчанию чувствительны к регистру в соответствии с соглашением POSIX и System.CommandLine соответствуют этому соглашению. Если вы хотите, чтобы интерфейс командной строки не учитывает регистр, определите псевдонимы для различных вариантов регистра. Например, --additional-probing-path может иметь псевдонимы --Additional-Probing-Path и --ADDITIONAL-PROBING-PATH.

В некоторых средствах командной строки разница в регистре определяет разницу в функции. Например, git clean -X поведение отличается от git clean -xповедения. Интерфейс командной строки .NET — это все строчные регистры.

Конфиденциальность регистра не применяется к значениям аргументов для параметров, основанных на перечислениях. Имена перечислений совпадают независимо от регистра.

Маркер --

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

Предположим , что myapp принимает message аргумент, и вы хотите, чтобы значение message было --interactive. Следующая командная строка может дать непредвиденные результаты.

myapp --interactive

Если myapp у него нет --interactive параметра, --interactive маркер интерпретируется как аргумент. Но если у приложения есть --interactive параметр, этот вход будет интерпретирован как ссылающийся на этот параметр.

В следующей командной строке используется маркер двойного дефиса для задания значения аргумента message "--interactive":

myapp -- --interactive
      ^^

System.CommandLine поддерживает эту функцию двойного дефиса.

Разделители аргументов option-argument

System.CommandLine позволяет использовать пробел, "=" или ":" в качестве разделителя между именем параметра и его аргументом. Например, следующие команды эквивалентны:

dotnet build -v quiet
dotnet build -v=quiet
dotnet build -v:quiet

Соглашение POSIX позволяет опустить разделитель при указании псевдонима однозначного параметра. Например, следующие команды эквивалентны:

myapp -vquiet
myapp -v quiet

System.CommandLine поддерживает этот синтаксис по умолчанию.

Arity аргумента

Arity аргумента параметра или команды — это количество значений, которые можно передать, если указан этот параметр или команда.

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

Min	Max	Пример допустимости	Пример
0	0	Действительны:	--Файл
		Недопустимое.	--file a.json
		Недопустимое.	--file a.json --file b.json
0	1	Действительны:	--Флаг
		Действительны:	--flag true
		Действительны:	--flag false
		Недопустимое.	--flag false --flag false --flag false
1	1	Действительны:	--file a.json
		Недопустимое.	--Файл
		Недопустимое.	--file a.json --file b.json
0	n	Действительны:	--Файл
		Действительны:	--file a.json
		Действительны:	--file a.json --file b.json
1	n	Действительны:	--file a.json
		Действительны:	--file a.json b.json
		Недопустимое.	--Файл

System.CommandLine имеет структуру ArgumentArity для определения arity со следующими значениями:

• Zero — значения не разрешены.
• ZeroOrOne — Может иметь одно значение, может не иметь значений.
• ExactlyOne — должно иметь одно значение.
• ZeroOrMore — может иметь одно значение, несколько значений или нет значений.
• OneOrMore — Может иметь несколько значений, должно иметь по крайней мере одно значение.

Arity часто можно вывести из типа. Например, параметр int имеет arity , и List<int> параметр имеет arity ExactlyOneOneOrMore.

Переопределения параметров

Если максимальное значение arity равно 1, System.CommandLine можно настроить для принятия нескольких экземпляров параметра. В этом случае последний экземпляр повторяющегося параметра перезаписывает все предыдущие экземпляры. В следующем примере значение 2 будет передано команде myapp .

myapp --delay 3 --message example --delay 2

Несколько аргументов

Если максимальное значение arity больше одного, System.CommandLine можно настроить для принятия нескольких аргументов для одного параметра без повторения имени параметра.

В следующем примере список, переданный команде myapp , будет содержать "a", "b", "c" и "d":

myapp --list a b c --list d

Объединение параметров

POSIX рекомендует поддерживать объединение однозначных параметров, также известных как стек. Пакетные параметры — это псевдонимы одного символа, указанные вместе после одного префикса дефиса. Только последний параметр может указать аргумент. Например, следующие командные строки эквивалентны:

git clean -f -d -x
git clean -fdx

Если аргумент предоставляется после пакета параметров, он применяется к последнему параметру в пакете. Следующие строки команды являются эквивалентными.

myapp -a -b -c arg
myapp -abc arg

В обоих вариантах в этом примере аргумент arg будет применяться только к параметру -c.

Логические параметры (флаги)

Если true или false передается для параметра с аргументом bool , он анализируется должным образом. Но параметр, тип bool аргумента которого обычно не требует указания аргумента. Логические параметры, иногда называемые "флагами", обычно имеют логическое значениеZeroOrOne. Наличие имени параметра в командной строке без аргументов, приводит к значению trueпо умолчанию. Отсутствие имени параметра во входных данных командной строки приводит к значению false. myapp Если команда выводит значение логического параметра с именем--interactive, то следующие входные данные создают следующие выходные данные:

myapp
myapp --interactive
myapp --interactive false
myapp --interactive true

False
True
False
True

Параметр --help

Приложения командной строки обычно предоставляют возможность отображения краткого описания доступных команд, параметров и аргументов. System.CommandLine автоматически создает выходные данные справки. Например:

dotnet list --help

Description:
  List references or packages of a .NET project.

Usage:
  dotnet [options] list [<PROJECT | SOLUTION>] [command]

Arguments:
  <PROJECT | SOLUTION>  The project or solution file to operate on. If a file is not specified, the command will search the current directory for one.

Options:
  -?, -h, --help  Show command line help.

Commands:
  package    List all package references of the project or solution.
  reference  List all project-to-project references of the project.

Пользователи приложений могут привыкнуть к различным способам запроса справки на разных платформах, поэтому приложения, созданные на System.CommandLine основе множества способов запроса справки. Следующие команды эквивалентны:

dotnet --help
dotnet -h
dotnet /h
dotnet -?
dotnet /?

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

Параметр --version

Приложения, созданные System.CommandLine на основе автоматического предоставления номера версии в ответ на --version параметр, используемый с корневой командой. Например:

dotnet --version

6.0.100

Файлы ответов

Файл ответа — это файл, содержащий набор маркеров для приложения командной строки. Файлы ответов — это функция System.CommandLine , которая полезна в двух сценариях:

• Чтобы вызвать приложение командной строки, указав входные данные, превышающие предел символа терминала.
• Для многократного вызова одной и той же команды без повторной повторной отправки всей строки.

Чтобы использовать файл ответа, введите имя файла, префиксированного @ знаком, где бы ни находилась строка, в которую нужно вставить команды, параметры и аргументы. Расширение RSP-файла является общим соглашением, но вы можете использовать любое расширение файла.

Следующие строки эквивалентны:

dotnet build --no-restore --output ./build-output/
dotnet @sample1.rsp
dotnet build @sample2.rsp --output ./build-output/

Содержимое примера1.rsp:

build
--no-restore 
--output
./build-output/

Содержимое примера2.rsp:

--no-restore

Ниже приведены правила синтаксиса, определяющие интерпретацию текста в файле ответа:

• Маркеры разделены пробелами. Строка, содержащая доброе утро! рассматривается как два маркера, Доброе и утро!.
• Несколько маркеров, заключенных в кавычки, интерпретируются как один маркер. Строка, содержащая "Доброе утро!" рассматривается как один маркер, Доброе утро!.
• Любой текст между символом # и концом строки рассматривается как комментарий и игнорируется.
• Маркеры, префиксированные с @ помощью дополнительных файлов ответов, могут ссылаться на дополнительные файлы ответа.
• Файл ответа может содержать несколько строк текста. Строки объединяются и интерпретируются как последовательность маркеров.

Директивы

System.CommandLineпредставляет синтаксический элемент, называемый директивой. Директива [parse] является примером. При включении [parse] после имени System.CommandLine приложения отображается схема результата синтаксического анализа вместо вызова приложения командной строки:

dotnet [parse] build --no-restore --output ./build-output/
       ^-----^

[ dotnet [ build [ --no-restore <True> ] [ --output <./build-output/> ] ] ]

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

Директива должна соответствовать следующим правилам синтаксиса:

• Это токен в командной строке, которая поступает после имени приложения, но до любых вложенных команд или параметров.
• Он заключен в квадратные скобки.
• Он не содержит пробелов.

Нераспознанная директива игнорируется без возникновения ошибки синтаксического анализа.

Директива может включать аргумент, разделенный именем директивы двоеточием.

Встроены следующие директивы:

• [parse]
• [suggest]

директиву [parse]

Пользователи и разработчики могут оказаться полезными для просмотра того, как приложение будет интерпретировать заданные входные данные. Одной из функций System.CommandLine по умолчанию приложения является [parse] директива, которая позволяет предварительно просмотреть результат анализа входных данных команды. Например:

myapp [parse] --delay not-an-int --interactive --file filename.txt extra

![ myapp [ --delay !<not-an-int> ] [ --interactive <True> ] [ --file <filename.txt> ] *[ --fgcolor <White> ] ]   ???--> extra

В предыдущем примере:

• Команда (myapp), ее дочерние параметры и аргументы для этих параметров группируются с помощью квадратных квадратных скобок.
• Для результата [ --delay !<not-an-int> ]! параметра указывает ошибку синтаксического анализа. Значение not-an-int параметра int невозможно проанализировать с ожидаемым типом. Ошибка также помечается ! перед командой, содержащей ошибку: ![ myapp...
• Для результата *[ --fgcolor <White> ]параметра параметр не был указан в командной строке, поэтому использовался настроенный по умолчанию параметр. White — это эффективное значение для этого параметра. Звездочка указывает, что значение по умолчанию.
• ???--> указывает на входные данные, которые не соответствовали ни одной из команд или параметров приложения.

директиву [suggest]

Директива [suggest] позволяет искать команды, если вы не знаете точной команды.

dotnet [suggest] buil

build
build-server
msbuild

Руководство по проектированию

В следующих разделах приведены рекомендации, которые рекомендуется следовать при разработке интерфейса командной строки. Думайте о том, что приложение ожидает в командной строке, как и то, что ожидает сервер REST API в URL-адресе. Согласованные правила rest API — это то, что делает их доступными для разработчиков клиентских приложений. Таким же образом пользователи приложений командной строки будут иметь лучший интерфейс, если дизайн ИНТЕРФЕЙСА командной строки соответствует общим шаблонам.

После создания интерфейса командной строки трудно измениться, особенно если пользователи использовали интерфейс командной строки в сценариях, которые они ожидают продолжать работать. Здесь были разработаны рекомендации после .NET CLI, и он не всегда следует этим рекомендациям. Мы обновляем интерфейс командной строки .NET, где это можно сделать, не внося критические изменения. Примером этой работы является новый дизайн dotnet new в .NET 7.

Команды и вложенные команды

Если команда имеет подкоманда, команда должна функционировать как область или идентификатор группировки для вложенных команд, а не указывать действие. При вызове приложения укажите команду группирования и одну из ее подкомандах. Например, попробуйте выполнить dotnet toolи вы получите сообщение об ошибке, так как tool команда определяет только группу вложенных команд, связанных с инструментом, например install и list. Вы можете запустить dotnet tool install, но dotnet tool само по себе будет неполным.

Одним из способов определения областей, помогающих пользователям, является организация выходных данных справки.

В интерфейсе командной строки часто существует неявная область. Например, в .NET CLI неявная область — это проект, а в интерфейсе командной строки Docker — образ. В результате можно использовать dotnet build без включения области. Рассмотрите, имеет ли интерфейс командной строки неявную область. Если это делается, рассмотрите, следует ли разрешить пользователю дополнительно включить или опустить его как в docker build и docker image build. Если вы при необходимости разрешаете вводить неявную область пользователем, вы также автоматически можете получить справку и завершение вкладок для этой группировки команд. Укажите необязательное использование неявной группы, определив две команды, которые выполняют одну и ту же операцию.

Параметры в качестве параметров

Параметры должны предоставлять параметры командам, а не указывать сами действия. Это рекомендуемый принцип проектирования, хотя он не всегда следует System.CommandLine (--help отображает сведения о справке).

Псевдонимы коротких форм

Как правило, рекомендуется свести к минимуму количество заданных псевдонимов параметра short-form.

В частности, избегайте использования любого из следующих псевдонимов, отличных от общего использования в .NET CLI и других приложениях командной строки .NET:

• -i для --interactive.

  Этот параметр сигнализирует пользователю о том, что им может быть предложено ввести входные данные на вопросы, необходимые команде. Например, запрос имени пользователя. Интерфейс командной строки может использоваться в сценариях, поэтому используйте осторожность при появлении запроса пользователей, которые не указали этот параметр.

• -o для --output.

  Некоторые команды создают файлы в результате их выполнения. Этот параметр следует использовать для определения расположения этих файлов. В случаях, когда создается один файл, этот параметр должен быть путь к файлу. В случаях, когда создается множество файлов, этот параметр должен быть путем к каталогу.

• -v для --verbosity.

  Команды часто предоставляют выходные данные пользователю в консоли; этот параметр используется для указания объема выходных данных, отправляемых пользователем. Дополнительные сведения см. в разделе "Вариант--verbosity" далее в этой статье.

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

• -c для --configuration

  Этот параметр часто ссылается на именованную конфигурацию сборки, например Debug или Release. Вы можете использовать любое имя, которое требуется для конфигурации, но большинство средств ожидают одно из них. Этот параметр часто используется для настройки других свойств таким образом, что имеет смысл для этой конфигурации, например при создании Debug конфигурации меньше кода. Рассмотрите этот параметр, если команда имеет разные режимы работы.

• -f для --framework

  Этот параметр используется для выбора одного моникера Целевой платформы (TFM), поэтому если приложение CLI имеет разное поведение в зависимости от выбранного TFM, следует поддерживать этот флаг.

• -p для --property

  Если приложение в конечном итоге вызывает MSBuild, пользователю часто потребуется настроить этот вызов каким-то образом. Этот параметр позволяет предоставлять свойства MSBuild в командной строке и передавать их в базовый вызов MSBuild. Если приложение не использует MSBuild, но требует набора пар "ключ-значение", рекомендуется использовать это же имя параметра, чтобы воспользоваться преимуществами ожиданий пользователей.

• -r для --runtime

  Если приложение может работать в разных средах выполнения или имеет логику, зависящей от среды выполнения, рассмотрите возможность поддержки этого параметра в качестве способа указания идентификатора среды выполнения. Если приложение поддерживает --runtime, рассмотрите возможность поддержки --os , а --arch также. Эти параметры позволяют указывать только части ОС или архитектуры RID, оставляя часть, не указанную на текущей платформе. Дополнительные сведения см. в разделе dotnet publish.

Краткие имена

Введите имена для команд, параметров и аргументов как можно короче и легко орфографировать. Например, если class достаточно ясно, не выполните команду classification.

Строчные имена

Определите имена только в нижнем регистре, кроме псевдонимов верхнего регистра, чтобы сделать команды или варианты нечувствительными.

Имена регистров Kebab

Используйте кебаб случай , чтобы различать слова. Например, --additional-probing-path.

Преобразование во множественную форму

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

Имена параметров	Согласованность
--additional-probing-paths и --sources.	✔️
--additional-probing-path и --source.	✔️
--additional-probing-paths и --source	❌
--additional-probing-path и --sources	❌

Глаголы и существительные

Используйте команды, а не существительные для команд, ссылающихся на действия (без вложенных команд), например: dotnet workload remove, а не dotnet workload removal. И используйте существительные, а не глаголы для параметров, например: --configuration, а не --configure.

Параметр --verbosity

System.CommandLine Приложения обычно предлагают параметр, указывающий --verbosity , сколько выходных данных отправляется в консоль. Ниже приведены стандартные пять параметров:

• Q[uiet]
• M[inimal]
• N[ormal]
• D[etailed]
• Diag[nostic]

Это стандартные имена, но существующие приложения иногда используются Silent вместо Quietи Trace, Debugили Verbose вместо Diagnosticних.

Каждое приложение определяет собственные критерии, определяющие, что отображается на каждом уровне. Как правило, приложению требуется только три уровня:

• Тихий NaN
• Обычная
• Диагностика

Если приложению не требуется пять разных уровней, параметр по-прежнему должен определять те же пять параметров. В этом случае Minimal и Normal будет производить те же выходные данные, а DiagnosticDetailed также будет таким же. Это позволяет пользователям просто вводить знакомые им сведения, и лучше всего использовать подходящие варианты.

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

• Отображение запросов на входные данные при --interactive указании, даже если --verbosity оно указано Quiet.
• Запретить использование --verbosity Quiet и --interactive вместе.

В противном случае приложение будет ожидать входных данных, не сообщая пользователю, что он ожидает. Появится, что приложение заморозится, и пользователь не будет иметь представления о том, что приложение ожидает входных данных.

Если вы определяете псевдонимы, используйте -v его --verbosity и не делаете -v без аргумента псевдонимом.--verbosity Diagnostic Используется -q для --verbosity Quiet.

Соглашения .NET CLI и POSIX

Интерфейс командной строки .NET не соответствует всем соглашениям POSIX.

Двойной дефис

Несколько команд в .NET CLI имеют специальную реализацию маркера двойного дефиса. В случае dotnet runс маркерами, dotnet watchdotnet tool runследующими--, передаются в приложение, которое выполняется командой. Например:

dotnet run --project ./myapp.csproj -- --message "Hello world!"
                                    ^^

В этом примере --project параметр передается dotnet run в команду, а --message параметр с его аргументом передается в качестве параметра командной строки в myapp при запуске.

Маркер -- не всегда требуется для передачи параметров в приложение, которое выполняется с помощью dotnet run. Без dotnet run двойного дефиса команда автоматически передается в приложение, выполняющее любые параметры, которые не распознаются как применение к dotnet run себе или к MSBuild. Поэтому следующие командные строки эквивалентны, так как dotnet run не распознает аргументы и параметры:

dotnet run -- quotes read --delay 0 --fg-color red
dotnet run quotes read --delay 0 --fg-color red

Пропуск разделителя параметра к аргументам

Интерфейс командной строки .NET не поддерживает соглашение POSIX, которое позволяет опустить разделитель при указании псевдонима однозначного параметра.

Несколько аргументов без повторения имени параметра

Интерфейс командной строки .NET не принимает несколько аргументов для одного параметра, не повторяя имя параметра.

Логические параметры

В .NET CLI некоторые логические параметры приводят к тому же поведению при передаче false , что и при передаче true. Это поведение приводит к тому, что код .NET CLI, реализующий параметр только проверка для наличия или отсутствия параметра, игнорируя значение. Примером является --no-restoredotnet build команда. Передача no-restore false и операция восстановления будет пропущена так же, как при указании no-restore true или no-restore.

Кебаб случай

В некоторых случаях интерфейс командной строки .NET не использует кебаб для имен команд, параметров или аргументов. Например, есть параметр .NET CLI, который называется --additionalprobingpath вместо --additional-probing-path.

См. также

• Руководство по проектированию интерфейса командной строки с открытым исходным кодом
• Стандарты GNU
• Обзор System.CommandLine
• Руководство. Начало работы с System.CommandLine