次の方法で共有

コマンド ライン構文の概要 System.CommandLine

  • [アーティクル]

重要

System.CommandLine は現在プレビュー段階であり、このドキュメントはバージョン 2.0 ベータ 4 用です。 一部の情報は、リリース前に大幅に変更される可能性があるプレリリース製品に関連しています。 Microsoft は、ここで提供される情報に関して明示的または黙示的な保証を行いません。

この記事では、 System.CommandLine 認識されるコマンド ライン構文について説明します。 この情報は、.NET CLI を含む .NET コマンド ライン アプリの開発者だけでなく、ユーザーにも役立ちます。

トークン

System.CommandLine は、コマンド ライン入力 をトークンに解析します。トークンは、スペースで区切られた文字列です。 たとえば、次のコマンド ラインを考えてみます。

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

この入力は、 dotnet アプリケーションによってトークン tool、 install、 dotnet-suggest、 --global、 --verbosity、および quietに解析されます。

トークンは、コマンド、オプション、または引数として解釈されます。 呼び出されるコマンド ライン アプリによって、最初のトークンの後のトークンの解釈方法が決まります。 次の表は、 System.CommandLine 前の例を解釈する方法を示しています。

トークン 解析結果
tool サブコマンド
install サブコマンド
dotnet-suggest install コマンドの引数
--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 コマンドには、dotnet runを入力して呼び出すrunサブコマンドがあります。

サブコマンドは、独自のサブコマンドを持つことができます。 dotnet tool installでは、installはtoolのサブコマンドです。

オプション

オプションは、コマンドに渡すことができる名前付きパラメーターです。 POSIX CLI は通常、オプション名の前に 2 つのハイフン (--) を付けます。 次の例は、2 つのオプションを示しています。

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

この例が示すように、オプションの値は明示的 (--verbosityの場合はquiet) または暗黙的 (--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の有効な値の 1 つではないので、次のコマンド エラーが発生します。

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

引数には、指定できる値の数に関する期待値もあります。 引数の アリティに関するセクションでは、例を示します。

オプションと引数の順序

コマンドラインでオプションの前に引数を、または引数の前にオプションを指定することができます。 次のコマンドは同等です。

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

これらのコマンドは、同じ値を持つリストをコマンド ハンドラー コードに渡しますが、値の順序が異なるため、結果が異なる可能性があります。

エイリアス

POSIX と Windows の両方で、一部のコマンドとオプションにエイリアスが含まれるのが一般的です。 これらは通常、簡単に入力できる短いフォームです。 エイリアスは、 大文字と小文字 の区別をシミュレートしたり、 単語の代替スペルをサポートしたりするために、他の目的にも使用できます。

POSIX の短い形式では、通常、先頭にハイフンが 1 つ続き、1 文字が続きます。 次のコマンドは同等です。

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 はこの規則に従います。 CLI で大文字と小文字を区別しないようにするには、さまざまな大文字と小文字を使用した代替のエイリアスを定義します。 たとえば、--additional-probing-path は --Additional-Probing-Path や --ADDITIONAL-PROBING-PATH というエイリアスを持つことができます。

一部のコマンド ライン ツールでは、大文字と小文字の違いによって機能の違いが指定されます。 たとえば、 git clean -X の動作は git clean -xとは異なります。 .NET CLI はすべて小文字です。

列挙型に基づくオプションの引数値には、大文字と小文字の区別は適用されません。 列挙型名は、大文字と小文字に関係なく照合されます。

-- トークン

POSIX 規則は、二重ダッシュ (--) トークンをエスケープ メカニズムとして解釈します。 二重ダッシュ トークンに続くすべてのものは、コマンドの引数として解釈されます。 この機能を使用すると、オプションとして解釈できなくなるため、オプションのような引数を送信できます。

myapp がmessage引数を受け取り、messageの値を--interactiveしたいとします。 次のコマンド ラインでは、予期しない結果が得られます。

myapp --interactive

myappに--interactiveオプションがない場合、--interactive トークンは引数として解釈されます。 ただし、アプリに --interactive オプションがある場合、この入力はそのオプションを参照していると解釈されます。

次のコマンド ラインでは、二重ダッシュ トークンを使用して、 message 引数の値を "--interactive" に設定します。

myapp -- --interactive
      ^^

System.CommandLine では、この二重ダッシュ機能がサポートされています。

オプション引数の区切り記号

System.CommandLine では、オプション名とその引数の間の区切り記号として、スペース '=' または ':' を使用できます。 たとえば、次のコマンドは同等です。

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

POSIX 規則を使用すると、1 文字のオプション エイリアスを指定するときに区切り記号を省略できます。 たとえば、次のコマンドは同等です。

myapp -vquiet
myapp -v quiet

System.CommandLine では、この構文が既定でサポートされています。

引数のアリティ

オプションまたはコマンドの引数の アリティ は、そのオプションまたはコマンドが指定されている場合に渡すことができる値の数です。

Arity は、次の表に示すように、最小値と最大値で表されます。

Min マックス 有効性の例 例
0 0 有効： --ファイル
無効です： --file a.json
無効です： --file a.json --file b.json
0 1 有効： --flag
有効： --flag true
有効： --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 構造体があり、次の値があります。

  • Zero - 値は許可されません。
  • ZeroOrOne - 1 つの値を持つ場合があり、値がない場合があります。
  • ExactlyOne - 1 つの値が必要です。
  • ZeroOrMore - 1 つの値、複数の値、または値がない場合があります。
  • OneOrMore - 複数の値を持つ場合があり、少なくとも 1 つの値が必要です。

アリティは、多くの場合、型から推論できます。 たとえば、 int オプションには ExactlyOneのアリティがあり、 List<int> オプションにはアリティ OneOrMoreがあります。

オプションのオーバーライド

アリティの最大値が 1 の場合でも、 System.CommandLine はオプションの複数のインスタンスを受け入れるように構成できます。 その場合、繰り返しオプションの最後のインスタンスは、以前のインスタンスを上書きします。 次の例では、値 2 が myapp コマンドに渡されます。

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

複数の引数

アリティ最大値が複数の場合、オプション名を繰り返さずに、1 つのオプションに対して複数の引数を受け入れるように System.CommandLine を構成できます。

次の例では、 myapp コマンドに渡されるリストに "a"、"b"、"c"、および "d" が含まれています。

myapp --list a b c --list d

オプションバンドル

POSIX では、スタックとも呼ばれる 1 文字のオプションのバンドルをサポートすることをお勧めします。 バンドルされたオプションは、1 つのハイフンプレフィックスの後に一緒に指定される 1 文字のオプションエイリアスです。 引数を指定できるのは最後のオプションだけです。 たとえば、次のコマンド ラインは同等です。

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

オプション バンドルの後に引数を指定すると、バンドル内の最後のオプションに適用されます。 次のコマンド ラインは同等です。

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

この例のどちらのバリアントでも、引数 arg はオプション -cにのみ適用されます。

ブール型のオプション (フラグ)

bool引数を持つオプションに対してtrueまたはfalseが渡された場合は、想定どおりに解析されます。 ただし、引数の型が bool オプションでは、通常、引数を指定する必要はありません。 ブール型のオプション ("flags" とも呼ばれます) には、通常、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上に構築されたアプリは、root コマンドで使用される --version オプションに応じて、バージョン番号を自動的に提供します。 例えば次が挙げられます。

dotnet --version

6.0.100

応答ファイル

応答ファイルは、コマンド ライン アプリの一連のトークンを含むファイルです。 応答ファイルは、次の 2 つのシナリオで役立つ System.CommandLine の機能です。

  • ターミナルの文字制限より長い入力を指定してコマンド ライン アプリを呼び出す。
  • 行全体を再入力せずに同じコマンドを繰り返し呼び出す。

応答ファイルを使用するには、コマンド、オプション、および引数を挿入する行の任意の場所に、 @ 記号が付いたファイル名を入力します。 rsp ファイル拡張子は一般的な規則ですが、任意のファイル拡張子を使用できます。

次の行は同等です。

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

sample1.rsp の内容:

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

sample2.rsp の内容:

--no-restore

応答ファイル内のテキストの解釈方法を決定する構文規則を次に示します。

  • トークンはスペースで区切られます。 おはよう! を含む行は、Good and morning! という 2 つのトークンとして扱われます。
  • 引用符で囲まれた複数のトークンは、1 つのトークンとして解釈されます。 "おはよう!" を含む行は、1 つのトークンとして扱われます。おはようございます!
  • #記号と行末の間のテキストはコメントとして扱われ、無視されます。
  • @プレフィックスが付いたトークンは、追加の応答ファイルを参照できます。
  • 応答ファイルには複数行のテキストを含めることができます。 行は連結され、トークンのシーケンスとして解釈されます。

指示事項

System.CommandLine では、ディレクティブと呼ばれる構文要素が導入 されています。 [parse] ディレクティブは一例です。 アプリの名前の後に [parse] を含めると、 System.CommandLine コマンド ライン アプリを呼び出す代わりに解析結果の図が表示されます。

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

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

ディレクティブの目的は、コマンドライン アプリ間で適用できるクロスカット機能を提供することです。 ディレクティブは構文的にアプリ独自の構文とは異なるため、アプリ間で適用される機能を提供できます。

ディレクティブは、次の構文規則に準拠している必要があります。

  • これは、コマンド ライン上のトークンであり、アプリの名前の後に、サブコマンドまたはオプションの前に置かれます。
  • 角かっこで囲む。
  • スペースを含まない。

認識できないディレクティブは、解析エラーを引き起こさずに無視されます。

ディレクティブには、ディレクティブ名からコロンで区切られた引数を含めることができます。

次のディレクティブが組み込まれています。

[parse] ディレクティブ

ユーザーと開発者の両方が、アプリが特定の入力をどのように解釈するかを確認すると便利な場合があります。 System.CommandLine アプリの既定の機能の 1 つは、コマンド入力の解析結果をプレビューできる[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> ]の場合、 ! は解析エラーを示します。 int オプションに対する値 not-an-int は、想定された型に解析できません。 エラーは、エラーが発生したオプションを含むコマンドの前に ! によってもフラグが設定されます: ![ myapp...。
  • オプションの結果 *[ --fgcolor <White> ]では、コマンド ラインでオプションが指定されていないため、構成済みの既定値が使用されました。 White は、このオプションの有効な値です。 アスタリスクは、値が既定値であることを示します。
  • ???--> は、アプリのコマンドまたはオプションのいずれにも一致しなかった入力を指します。

[suggest] ディレクティブ

[suggest] ディレクティブを使用すると、正確なコマンドがわからない場合にコマンドを検索できます。

dotnet [suggest] buil

build
build-server
msbuild

設計ガイダンス

次のセクションでは、CLI を設計する際に従うことをお勧めするガイダンスを提示します。 アプリがコマンド ラインで期待しているものは、REST API サーバーが URL で想定しているものと同じように考えてください。 REST API の一貫した規則によって、クライアント アプリ開発者が簡単に使用できるようになります。 同様に、CLI の設計が一般的なパターンに従っている場合、コマンド ライン アプリのユーザーのエクスペリエンスが向上します。

CLI を作成すると、特にユーザーが実行を続ける必要があるスクリプトで CLI を使用している場合は、変更が困難になります。 ここでのガイドラインは .NET CLI の後に開発されており、これらのガイドラインに必ずしも従っているわけではありません。 .NET CLI を更新しています。ここで、破壊的変更を導入せずに実行できます。 この作業の例として、.NET 7 の dotnet new の新しい設計があります。

コマンドとサブコマンド

コマンドにサブコマンドがある場合、コマンドは、アクションを指定するのではなく、エリアまたはサブコマンドのグループ化 ID として機能する必要があります。 アプリを呼び出すときは、グループ化コマンドとそのサブコマンドの 1 つを指定します。 たとえば、dotnet toolを実行しようとすると、installやlistなどのツール関連のサブコマンドのグループのみがtool コマンドによって識別されるため、エラー メッセージが表示されます。 dotnet tool installを実行できますが、単独でdotnet toolは不完全です。

領域を定義してユーザーを支援する方法の 1 つは、ヘルプ出力を整理することです。

CLI 内には、多くの場合、暗黙的な領域があります。 たとえば、.NET CLI では、暗黙的な領域はプロジェクトであり、Docker CLI ではイメージです。 その結果、領域を含めずに dotnet build を使用できます。 CLI に暗黙的な領域があるかどうかを検討します。 その場合は、 docker build と docker image buildのように、ユーザーが必要に応じて含めるか省略するかを検討します。 必要に応じて、ユーザーが暗黙的な領域を入力できるようにする場合は、このコマンドグループのヘルプとタブ補完も自動的に行われます。 同じ操作を実行する 2 つのコマンドを定義して、暗黙的なグループのオプションの使用を指定します。

パラメーターとしてのオプション

オプションでは、アクション自体を指定するのではなく、コマンドにパラメーターを指定する必要があります。 これは推奨される設計原則ですが、常に System.CommandLine が続くわけではありません (ヘルプ情報が表示--help )。

短い形式のエイリアス

一般に、定義する短い形式のオプションエイリアスの数は最小限にすることをお勧めします。

特に、.NET CLI やその他の .NET コマンド ライン アプリでの一般的な使用方法とは異なる方法で次のエイリアスを使用しないでください。

  • -i (--interactive)。

    このオプションは、コマンドが回答する必要がある質問への入力を求められる可能性があることをユーザーに通知します。 たとえば、ユーザー名の入力を求めるメッセージが表示されます。 CLI はスクリプトで使用される可能性があるため、このスイッチを指定していないユーザーにメッセージを表示する場合は注意が必要です。

  • -o (--output)。

    一部のコマンドでは、実行の結果としてファイルが生成されます。 このオプションは、これらのファイルが配置される場所を決定するために使用する必要があります。 1 つのファイルが作成される場合、このオプションはファイル パスにする必要があります。 多くのファイルが作成される場合、このオプションはディレクトリ パスにする必要があります。

  • -v (--verbosity)。

    多くの場合、コマンドはコンソールでユーザーに出力を提供します。このオプションは、ユーザーが要求する出力の量を指定するために使用されます。 詳細については、この記事で後述 する「 --verbosity オプション 」を参照してください。

.NET CLI に限定された一般的な使用方法を持つエイリアスもあります。 これらのエイリアスは、アプリ内の他のオプションに使用できますが、混乱の可能性に注意してください。

  • --configuration (-c)

    このオプションは、多くの場合、 Debug や Releaseなど、名前付きのビルド構成を参照します。 構成には任意の名前を使用できますが、ほとんどのツールではその 1 つが必要です。 この設定は、多くの場合、その構成に適した方法で他のプロパティを構成するために使用されます。たとえば、 Debug 構成を構築するときにコードの最適化を減らします。 コマンドの操作モードが異なる場合は、このオプションを検討してください。

  • --framework (-f)

    このオプションは、実行する 1 つの ターゲット フレームワーク モニカー (TFM) を選択するために使用されます。そのため、選択した TFM に基づいて CLI アプリケーションの動作が異なる場合は、このフラグをサポートする必要があります。

  • --property (-p)

    アプリケーションが最終的に MSBuild を呼び出す場合、多くの場合、ユーザーはその呼び出しを何らかの方法でカスタマイズする必要があります。 このオプションを使用すると、コマンド ラインで MSBuild プロパティを指定し、基になる MSBuild 呼び出しに渡すことができます。 アプリで MSBuild を使用せず、キーと値のペアのセットが必要な場合は、この同じオプション名を使用してユーザーの期待を活用することを検討してください。

  • --runtime (-r)

    アプリケーションが異なるランタイムで実行できる場合、またはランタイム固有のロジックがある場合は、 ランタイム識別子を指定する方法としてこのオプションをサポートすることを検討してください。 アプリで --runtime がサポートされている場合は、 --os と --arch もサポートすることを検討してください。 これらのオプションを使用すると、OS または RID のアーキテクチャ部分のみを指定でき、指定されていない部分は現在のプラットフォームから決定されます。 詳細については、「dotnet publish」を参照してください。

短い名前

コマンド、オプション、引数の名前をできるだけ短く簡単に入力します。 たとえば、 class が明確であれば、コマンドを classificationしません。

小文字の名前

名前は小文字のみで定義しますが、コマンドやオプションで大文字と小文字の区別をなくすために、大文字のエイリアスを作成することができます。

ケバブ ケースの名前

単語を区別するにはkebab ケースを使用します。 たとえば、--additional-probing-path のようにします。

複数化

アプリ内では、複数形化で一貫性を保つ。 たとえば、複数の値を持つオプション (最大アリティが 1 より大きい) には、複数形と単数形の名前を混在させないでください。

オプション名 一貫性
--additional-probing-paths と --sources ✔️
--additional-probing-path と --source ✔️
--additional-probing-paths と --source ❌
--additional-probing-path と --sources ❌

動詞と名詞

アクションを参照するコマンド (その下にサブコマンドがないコマンド) には、名詞ではなく動詞を使用します (たとえば、dotnet workload removalではなく、dotnet workload remove)。 オプションには動詞ではなく名詞を使用します。たとえば、--configureではなく--configurationします。

--verbosity オプション

System.CommandLine アプリケーションは、通常、コンソールに送信される出力量を指定する --verbosity オプションを提供します。 標準の 5 つの設定を次に示します。

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

これらは標準名ですが、既存のアプリでは、Quietの代わりにSilentを使用したり、Diagnosticの代わりにTrace、Debug、またはVerboseを使用したりする場合があります。

各アプリは、各レベルで表示される内容を決定する独自の条件を定義します。 通常、アプリには次の 3 つのレベルのみが必要です。

  • 静か
  • 正常
  • 診断

アプリに 5 つの異なるレベルが必要ない場合でも、このオプションでは同じ 5 つの設定を定義する必要があります。 その場合、 Minimal と Normal は同じ出力を生成し、 Detailed と Diagnostic も同様に同じになります。 これにより、ユーザーは慣れているものを入力するだけで、最適なものが使用されます。

Quietの期待は、コンソールに出力が表示されないということです。 ただし、アプリが対話型モードを提供する場合、アプリは次のいずれかの方法を実行する必要があります。

  • --verbosityがQuietされている場合でも、--interactiveが指定されている場合は、入力のプロンプトを表示します。
  • --verbosity Quietと--interactiveの併用を禁止します。

それ以外の場合、アプリはユーザーに何を待っているかを伝えずに入力を待機します。 アプリケーションがフリーズしているように見え、ユーザーはアプリケーションが入力を待機していることを知らなくなります。

エイリアスを定義する場合は、--verbosityに-vを使用し、引数を指定せずに-vを--verbosity Diagnosticのエイリアスにします。 --verbosity Quietには-qを使用します。

.NET CLI と POSIX の規則

.NET CLI は、すべての POSIX 規則に一貫して従うわけではありません。

二重ダッシュ

.NET CLI のいくつかのコマンドには、二重ダッシュ トークンの特別な実装があります。 dotnet run、dotnet watch、およびdotnet 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 CLI では、1 文字のオプション エイリアスを指定するときに区切り記号を省略できる POSIX 規則はサポートされていません。

オプション名を繰り返さない複数の引数

.NET CLI では、オプション名を繰り返さずに、1 つのオプションに対して複数の引数を受け入れることはできません。

ブール値のオプション

.NET CLI では、一部のブール型オプションは、trueを渡すときとfalseを渡すときと同じ動作になります。 この動作は、オプションを実装する .NET CLI コードがオプションの有無のみをチェックし、値を無視した場合に発生します。 たとえば、dotnet build コマンドの--no-restoreです。 no-restore false渡すと、復元操作は、no-restore trueまたはno-restoreを指定した場合と同じようにスキップされます。

ケバブ ケース

場合によっては、.NET CLI でコマンド名、オプション名、または引数名に kebab case が使用されない場合があります。 たとえば、--additional-probing-pathではなく、--additionalprobingpathという名前の .NET CLI オプションがあります。

こちらもご覧ください