Översikt över kommandoradssyntax för System.CommandLine

Artikel
06/08/2023

Viktigt!

System.CommandLine är för närvarande i förhandsversion och den här dokumentationen är för version 2.0 beta 4. Viss information gäller förhandsversionsprodukt som kan ändras avsevärt innan den släpps. Microsoft lämnar inga garantier, uttryckliga eller underförstådda, avseende informationen som visas här.

I den här artikeln beskrivs den kommandoradssyntax som System.CommandLine identifierar. Informationen är användbar för både användare och utvecklare av .NET-kommandoradsappar, inklusive .NET CLI.

Token

System.CommandLine parsar kommandoradsindata i token, som är strängar avgränsade med blanksteg. Tänk till exempel på följande kommandorad:

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

Indata parsas av dotnet programmet i token , tool, installdotnet-suggest, --global, , --verbosityoch quiet.

Token tolkas som kommandon, alternativ eller argument. Kommandoradsappen som anropas avgör hur token efter den första tolkas. I följande tabell visas hur System.CommandLine du tolkar föregående exempel:

Token	Tolkad som
`tool`	Underkommando
`install`	Underkommando
`dotnet-suggest`	Argument för installationskommando
`--global`	Alternativ för installationskommando
`--verbosity`	Alternativ för installationskommando
`quiet`	Argument för `--verbosity` alternativ

En token kan innehålla blanksteg om den omges av citattecken ("). Här är ett exempel:

dotnet tool search "ef migrations add"

Kommandon

Ett kommando i kommandoradsindata är en token som anger en åtgärd eller definierar en grupp relaterade åtgärder. Till exempel:

run I dotnet runär ett kommando som anger en åtgärd.
install I dotnet tool installär ett kommando som anger en åtgärd och tool är ett kommando som anger en grupp relaterade kommandon. Det finns andra verktygsrelaterade kommandon, till exempel tool uninstall, tool listoch tool update.

Rotkommandon

Rotkommandot är det som anger namnet på appens körbara fil. Kommandot anger till exempel dotnet dotnet.exe körbar fil.

Underkommandon

De flesta kommandoradsappar stöder underkommandon, även kallade verb. Kommandot har till exempel dotnet en run underkommando som du anropar genom att ange dotnet run.

Underkommandon kan ha egna underkommandon. install I dotnet tool installär en underkommando för tool.

Alternativ

Ett alternativ är en namngiven parameter som kan skickas till ett kommando. POSIX-CLIs prefixar vanligtvis alternativnamnet med två bindestreck (--). I följande exempel visas två alternativ:

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

Som det här exemplet visar kan värdet för alternativet vara explicit (quiet för --verbosity) eller implicit (ingenting följer --global). Alternativ som inte har något angivet värde är vanligtvis booleska parametrar som standard om true alternativet anges på kommandoraden.

För vissa Windows-kommandoradsappar identifierar du ett alternativ med hjälp av ett inledande snedstreck (/) med alternativnamnet. Till exempel:

msbuild /version
        ^------^

System.CommandLine stöder både POSIX- och Windows-prefixkonventioner. När du konfigurerar ett alternativ anger du alternativnamnet inklusive prefixet.

Argument

Ett argument är ett värde som skickas till ett alternativ eller ett kommando. I följande exempel visas ett argument för verbosity alternativet och ett argument för build kommandot.

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

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

Argument kan ha standardvärden som gäller om inget argument uttryckligen anges. Många alternativ är till exempel implicit booleska parametrar med standardvärdet true när alternativnamnet finns på kommandoraden. Följande kommandoradsexempel är likvärdiga:

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

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

Vissa alternativ har obligatoriska argument. I .NET CLI --output kräver till exempel ett argument för mappnamn. Om argumentet inte anges misslyckas kommandot.

Argument kan ha förväntade typer och System.CommandLine visar ett felmeddelande om ett argument inte kan parsas till den förväntade typen. Följande kommandofel beror till exempel på att "tyst" inte är ett av de giltiga värdena för --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

Argument har också förväntningar på hur många värden som kan anges. Exempel finns i avsnittet om argumentaritet.

Ordning på alternativ och argument

Du kan ange alternativ före argument eller argument före alternativ på kommandoraden. Följande kommandon är likvärdiga:

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

Alternativ kan anges i valfri ordning. Följande kommandon är likvärdiga:

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

När det finns flera argument spelar ordningen roll. Följande kommandon är inte nödvändigtvis likvärdiga:

myapp argument1 argument2
myapp argument2 argument1

Dessa kommandon skickar en lista med samma värden till kommandohanterarkoden, men de skiljer sig åt i ordningen på värdena, vilket kan leda till olika resultat.

Alias

I både POSIX och Windows är det vanligt att vissa kommandon och alternativ har alias. Det här är vanligtvis korta formulär som är lättare att skriva. Alias kan också användas för andra ändamål, till exempel för att simulera skiftlägeskänslighet och för att stödja alternativa stavningar av ett ord.

POSIX korta formulär har vanligtvis ett enda inledande bindestreck följt av ett enda tecken. Följande kommandon är likvärdiga:

dotnet build --verbosity quiet
dotnet build -v quiet

GNU-standarden rekommenderar automatiska alias. Det innebär att du kan ange valfri del av ett långformulärskommando eller alternativnamn så godkänns det. Det här beteendet skulle göra följande kommandorader likvärdiga:

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 stöder inte automatiska alias.

Skiftlägeskänslig

Kommando- och alternativnamn och alias är skiftlägeskänsliga som standard enligt POSIX-konventionen och System.CommandLine följer den här konventionen. Om du vill att CLI ska vara skiftlägesokänsligt definierar du alias för de olika höljealternativen. Kan till exempel --additional-probing-path ha alias --Additional-Probing-Path och --ADDITIONAL-PROBING-PATH.

I vissa kommandoradsverktyg anger en skillnad i hölje en skillnad i funktion. Till exempel git clean -X beter sig annorlunda än git clean -x. .NET CLI är bara gemener.

Skiftlägeskänslighet gäller inte för argumentvärden för alternativ som baseras på uppräkningar. Uppräkningsnamn matchas oavsett hölje.

Token `--`

POSIX-konventionen tolkar dubbelstreckstoken (--) som en escape-mekanism. Allt som följer dubbelstreckstoken tolkas som argument för kommandot. Den här funktionen kan användas för att skicka argument som ser ut som alternativ, eftersom den förhindrar att de tolkas som alternativ.

Anta att myapp tar ett message argument, och du vill att värdet message för ska vara --interactive. Följande kommandorad kan ge oväntade resultat.

myapp --interactive

Om myapp inte har något --interactive alternativ --interactive tolkas token som ett argument. Men om appen har ett --interactive alternativ tolkas dessa indata som refererar till det alternativet.

Följande kommandorad använder dubbelstreckstoken för att ange värdet för message argumentet till "--interactive":

myapp -- --interactive
      ^^

System.CommandLine stöder den här dubbelstrecksfunktionen.

Avgränsare för alternativargument

System.CommandLine låter dig använda blanksteget "=" eller ":" som avgränsare mellan ett alternativnamn och dess argument. Följande kommandon är till exempel likvärdiga:

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

Med en POSIX-konvention kan du utelämna avgränsare när du anger ett alternativalias med ett tecken. Följande kommandon är till exempel likvärdiga:

myapp -vquiet
myapp -v quiet

System.CommandLine stöder den här syntaxen som standard.

Argumentaritet

Arity för ett alternativ eller kommandots argument är det antal värden som kan skickas om det alternativet eller kommandot har angetts.

Arity uttrycks med ett minimivärde och ett högsta värde, vilket visas i följande tabell:

Min	Max	Exempel på giltighet	Exempel
0	0	Giltig:	--Filen
		Ogiltig:	--file a.json
		Ogiltig:	--file a.json --file b.json
0	1	Giltig:	--Flagga
		Giltig:	--flagga sant
		Giltig:	--flagga falskt
		Ogiltig:	--flagga falskt --flagga falskt
1	1	Giltig:	--file a.json
		Ogiltig:	--Filen
		Ogiltig:	--file a.json --file b.json
0	N	Giltig:	--Filen
		Giltig:	--file a.json
		Giltig:	--file a.json --file b.json
1	N	Giltig:	--file a.json
		Giltig:	--file a.json b.json
		Ogiltig:	--Filen

System.CommandLine har en ArgumentArity struct för att definiera aritet, med följande värden:

Zero – Inga värden tillåts.
ZeroOrOne - Kan ha ett värde, kanske inte har några värden.
ExactlyOne - Måste ha ett värde.
ZeroOrMore – Kan ha ett värde, flera värden eller inga värden.
OneOrMore – Kan ha flera värden, måste ha minst ett värde.

Arity kan ofta härledas från typen. Ett alternativ har till exempel int aritet ExactlyOne, och ett List<int> alternativ har arity OneOrMore.

Åsidosättningar av alternativ

Om arity maximum är 1 kan System.CommandLine du fortfarande konfigureras för att acceptera flera instanser av ett alternativ. I så fall skriver den sista instansen av ett upprepat alternativ över alla tidigare instanser. I följande exempel skickas värdet 2 till myapp kommandot.

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

Flera argument

Om arity maximum är mer än ett kan System.CommandLine konfigureras för att acceptera flera argument för ett alternativ utan att upprepa alternativnamnet.

I följande exempel skulle listan som skickades till myapp kommandot innehålla "a", "b", "c" och "d":

myapp --list a b c --list d

Alternativbuntning

POSIX rekommenderar att du stöder paketering av alternativ med en tecken, även kallat stapling. Paketerade alternativ är alternativalias med en tecken som anges tillsammans efter ett enda bindestrecksprefix. Endast det sista alternativet kan ange ett argument. Följande kommandorader är till exempel likvärdiga:

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

Om ett argument anges efter ett alternativpaket gäller det för det sista alternativet i paketet. Följande kommandorader är likvärdiga:

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

I båda varianterna i det här exemplet skulle argumentet arg endast gälla för alternativet -c.

Booleska alternativ (flaggor)

Om true eller false skickas för ett alternativ med ett bool argument parsas det som förväntat. Men ett alternativ vars argumenttyp vanligtvis bool inte kräver att ett argument anges. Booleska alternativ, som ibland kallas "flaggor", har vanligtvis en aritet på ZeroOrOne. Förekomsten av alternativnamnet på kommandoraden, utan argument som följer, resulterar i ett standardvärde på true. Avsaknaden av alternativnamnet i kommandoradsindata resulterar i värdet false. myapp Om kommandot skriver ut värdet för ett booleskt alternativ med namnet --interactiveskapar följande indata följande utdata:

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

False
True
False
True

Alternativet --help

Kommandoradsappar ger vanligtvis ett alternativ för att visa en kort beskrivning av tillgängliga kommandon, alternativ och argument. System.CommandLine genererar automatiskt hjälputdata. Till exempel:

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.

Appanvändare kan vara vana vid olika sätt att begära hjälp på olika plattformar, så appar som bygger på svarar på System.CommandLine många sätt att begära hjälp. Följande kommandon är alla likvärdiga:

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

Hjälputdata visar inte nödvändigtvis alla tillgängliga kommandon, argument och alternativ. Vissa av dem kan vara dolda, vilket innebär att de inte visas i hjälputdata, men de kan anges på kommandoraden.

Alternativet --version

Appar som bygger på anger automatiskt versionsnumret som svar på System.CommandLine det --version alternativ som används med rotkommandot. Till exempel:

dotnet --version

6.0.100

Svarsfiler

En svarsfil är en fil som innehåller en uppsättning token för en kommandoradsapp. Svarsfiler är en funktion System.CommandLine som är användbar i två scenarier:

Så här anropar du en kommandoradsapp genom att ange indata som är längre än terminalens teckengräns.
Så här anropar du samma kommando upprepade gånger utan att skriva om hela raden.

Om du vill använda en svarsfil anger du filnamnet som föregås av ett @ tecken oavsett var på raden du vill infoga kommandon, alternativ och argument. Filnamnstillägget .rsp är en vanlig konvention, men du kan använda valfritt filnamnstillägg.

Följande rader är likvärdiga:

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

Innehållet i sample1.rsp:

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

Innehållet i sample2.rsp:

--no-restore

Här är syntaxregler som avgör hur texten i en svarsfil tolkas:

Token avgränsas av blanksteg. En rad som innehåller God morgon! behandlas som två token, God och morgon!.
Flera token som omges av citattecken tolkas som en enda token. En rad som innehåller "God morgon!" behandlas som en token, God morgon!.
All text mellan en # symbol och slutet av raden behandlas som en kommentar och ignoreras.
Token som är prefix med @ kan referera till ytterligare svarsfiler.
Svarsfilen kan ha flera textrader. Raderna sammanfogas och tolkas som en sekvens med token.

Direktiv

System.CommandLineintroducerar ett syntaktiskt element som kallas direktiv. Direktivet [parse] är ett exempel. När du inkluderar [parse] efter appens namn System.CommandLine visas ett diagram över parsningsresultatet i stället för att anropa kommandoradsappen:

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

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

Syftet med direktiven är att tillhandahålla övergripande funktioner som kan tillämpas i kommandoradsappar. Eftersom direktiven är syntaktiskt åtskilda från appens egen syntax kan de tillhandahålla funktioner som gäller för appar.

Ett direktiv måste följa följande syntaxregler:

Det är en token på kommandoraden som kommer efter appens namn men före eventuella underkommandon eller alternativ.
Den omges av hakparenteser.
Den innehåller inte blanksteg.

Ett okänt direktiv ignoreras utan att orsaka ett parsningsfel.

Ett direktiv kan innehålla ett argument, avgränsat från direktivnamnet med ett kolon.

Följande direktiv är inbyggda:

[parse]
[suggest]

Direktivet `[parse]`

Både användare och utvecklare kan ha nytta av att se hur en app tolkar en viss indata. En av standardfunktionerna i en System.CommandLine app är [parse] direktivet, som låter dig förhandsgranska resultatet av att parsa kommandoindata. Till exempel:

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

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

I exemplet ovan händer följande:

Kommandot (myapp), dess underordnade alternativ och argumenten till dessa alternativ grupperas med hakparenteser.
För alternativresultatet [ --delay !<not-an-int> ]! anger indikerar ett parsningsfel. Värdet not-an-int för ett int alternativ kan inte parsas till den förväntade typen. Felet flaggas också av ! framför kommandot som innehåller det felade alternativet: ![ myapp....
För alternativresultatet *[ --fgcolor <White> ]angavs inte alternativet på kommandoraden, så den konfigurerade standardinställningen användes. White är det effektiva värdet för det här alternativet. Asterisken anger att värdet är standardvärdet.
???--> pekar på indata som inte matchades med något av appens kommandon eller alternativ.

Direktivet `[suggest]`

Med [suggest] direktivet kan du söka efter kommandon när du inte känner till det exakta kommandot.

dotnet [suggest] buil

build
build-server
msbuild

Riktlinjer för design

Följande avsnitt innehåller vägledning som vi rekommenderar att du följer när du utformar ett CLI. Tänk på vad din app förväntar sig på kommandoraden som liknar vad en REST API-server förväntar sig i URL:en. Konsekventa regler för REST-API:er är det som gör dem lätt användbara för klientappsutvecklare. På samma sätt får användare av dina kommandoradsappar en bättre upplevelse om CLI-designen följer vanliga mönster.

När du har skapat en CLI är det svårt att ändra, särskilt om användarna har använt cli i skript som de förväntar sig att fortsätta köra. Riktlinjerna här utvecklades efter .NET CLI och följer inte alltid dessa riktlinjer. Vi uppdaterar .NET CLI där vi kan göra det utan att införa icke-bakåtkompatibla ändringar. Ett exempel på det här arbetet är den nya designen för dotnet new i .NET 7.

Kommandon och underkommandon

Om ett kommando har underkommandon ska kommandot fungera som ett område eller en grupperingsidentifierare för underkommandona i stället för att ange en åtgärd. När du anropar appen anger du grupperingskommandot och en av dess underkommandon. Försök till exempel att köra dotnet tooloch du får ett felmeddelande eftersom tool kommandot endast identifierar en grupp med verktygsrelaterade underkommandon, till exempel install och list. Du kan köra dotnet tool install, men dotnet tool i sig skulle vara ofullständig.

Ett sätt att definiera områden är att organisera hjälputdata.

Inom en CLI finns det ofta ett implicit område. I .NET CLI är till exempel det implicita området projektet och i Docker CLI är det avbildningen. Därför kan du använda dotnet build utan att inkludera ett område. Fundera på om ditt CLI har ett implicit område. Om det gör det bör du överväga om användaren ska kunna inkludera eller utelämna det som i docker build och docker image build. Om du vill tillåta att det implicita området skrivs av användaren får du även automatiskt hjälp och tabbavslut för den här gruppering av kommandon. Ange den valfria användningen av den implicita gruppen genom att definiera två kommandon som utför samma åtgärd.

Alternativ som parametrar

Alternativen bör ge parametrar till kommandon i stället för att ange själva åtgärderna. Detta är en rekommenderad designprincip även om den inte alltid följs av System.CommandLine (--help visar hjälpinformation).

Kortformatsalias

I allmänhet rekommenderar vi att du minimerar antalet kortformulärsalternativalias som du definierar.

Undvik särskilt att använda något av följande alias på ett annat sätt än deras vanliga användning i .NET CLI och andra .NET-kommandoradsappar:

-i för --interactive.

Det här alternativet signalerar till användaren att de kan uppmanas att ange indata till frågor som kommandot behöver besvaras. Till exempel att fråga efter ett användarnamn. Cli kan användas i skript, så var försiktig när du uppmanar användare som inte har angett den här växeln.
-o för --output.

Vissa kommandon skapar filer som ett resultat av körningen. Det här alternativet bör användas för att avgöra var filerna ska finnas. I de fall där en enskild fil skapas bör det här alternativet vara en filsökväg. I de fall där många filer skapas bör det här alternativet vara en katalogsökväg.
-v för --verbosity.

Kommandon ger ofta utdata till användaren i konsolen. Det här alternativet används för att ange mängden utdata som användaren begär. Mer information finns i Alternativet --verbosity senare i den här artikeln.

Det finns också vissa alias med vanlig användning begränsad till .NET CLI. Du kan använda dessa alias för andra alternativ i dina appar, men var medveten om risken för förvirring.

-c för --configuration

Det här alternativet refererar ofta till en med namnet Build Configuration, som Debug eller Release. Du kan använda valfritt namn för en konfiguration, men de flesta verktyg förväntar sig ett av dessa. Den här inställningen används ofta för att konfigurera andra egenskaper på ett sätt som passar för den konfigurationen, till exempel genom att göra mindre kodoptimering när du skapar konfigurationen Debug . Överväg det här alternativet om kommandot har olika driftlägen.
-f för --framework

Det här alternativet används för att välja en enda Target Framework Moniker (TFM) att köra för, så om ditt CLI-program har olika beteende baserat på vilken TFM som väljs bör du ha stöd för den här flaggan.
-p för --property

Om programmet så småningom anropar MSBuild måste användaren ofta anpassa det anropet på något sätt. Med det här alternativet kan MSBuild-egenskaper anges på kommandoraden och skickas vidare till det underliggande MSBuild-anropet. Om din app inte använder MSBuild men behöver en uppsättning nyckel/värde-par kan du överväga att använda samma alternativnamn för att dra nytta av användarnas förväntningar.
-r för --runtime

Om ditt program kan köras på olika körningar eller har körningsspecifik logik kan du överväga att stödja det här alternativet som ett sätt att ange en Körningsidentifierare. Om din app stöder --runtime bör du överväga att stödja --os och --arch även. Med de här alternativen kan du bara ange operativsystemet eller arkitekturdelarna i RID, så att delen inte har angetts för att bestämmas från den aktuella plattformen. Mer information finns i dotnet publish.

Korta namn

Gör namn för kommandon, alternativ och argument så korta och enkla att stava som möjligt. Om class är tillräckligt tydligt gör du till exempel inte kommandot classification.

Gemener

Definiera endast namn i gemener, förutom att du kan göra versaler alias för att göra kommandon eller alternativ skiftlägesokänsliga.

Namn på Kebab-skiftläge

Använd kebabfall för att särskilja ord. Exempel: --additional-probing-path

Pluralisering

I en app ska du vara konsekvent i pluralisering. Blanda till exempel inte plural- och singularnamn för alternativ som kan ha flera värden (maximal aritet större än en):

Alternativnamn	Konsekvens
`--additional-probing-paths` och `--sources`	✔️
`--additional-probing-path` och `--source`	✔️
`--additional-probing-paths` och `--source`	❌
`--additional-probing-path` och `--sources`	❌

Verb kontra substantiv

Använd verb i stället för substantiv för kommandon som refererar till åtgärder (de utan underkommandon under dem), till exempel: dotnet workload remove, inte dotnet workload removal. Och använd substantiv i stället för verb för alternativ, till exempel: --configuration, inte --configure.

Alternativet `--verbosity`

System.CommandLine program erbjuder vanligtvis ett --verbosity alternativ som anger hur mycket utdata som skickas till konsolen. Här är de fem standardinställningarna:

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

Det här är standardnamnen, men befintliga appar används Silent ibland i stället för Quiet, och Trace, Debugeller Verbose i stället för Diagnostic.

Varje app definierar sina egna kriterier som avgör vad som visas på varje nivå. Vanligtvis behöver en app bara tre nivåer:

Quiet
Normal
Diagnostik

Om en app inte behöver fem olika nivåer bör alternativet fortfarande definiera samma fem inställningar. I så fallMinimal, och Normal kommer att producera samma utdata, och DiagnosticDetailed kommer på samma sätt att vara samma. På så sätt kan användarna bara skriva det de är bekanta med, så används den bästa passformen.

Förväntningen Quiet är att inga utdata visas på konsolen. Men om en app erbjuder ett interaktivt läge bör appen göra något av följande alternativ:

Visa prompter för indata när --interactive anges, även om --verbosity är Quiet.
Tillåt inte användning av --verbosity Quiet och --interactive tillsammans.

Annars väntar appen på indata utan att tala om för användaren vad den väntar på. Det verkar som om programmet frös och att användaren inte har någon aning om att programmet väntar på indata.

Om du definierar alias använder -v du för --verbosity och gör -v utan ett argument ett alias för --verbosity Diagnostic. Använd -q för --verbosity Quiet.

.NET CLI- och POSIX-konventionerna

.NET CLI följer inte konsekvent alla POSIX-konventioner.

Dubbelstreck

Flera kommandon i .NET CLI har en särskild implementering av dubbelstreckstoken. När det gäller dotnet run, dotnet watchoch dotnet tool run, skickas token som följer -- till appen som körs av kommandot. Till exempel:

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

I det här exemplet --project skickas alternativet till dotnet run kommandot och --message alternativet med dess argument skickas som ett kommandoradsalternativ till myapp när det körs.

Token -- krävs inte alltid för att skicka alternativ till en app som du kör med hjälp dotnet runav . Utan dubbelstrecket dotnet run skickar kommandot automatiskt vidare till appen som kör alla alternativ som inte känns igen som att tillämpa på dotnet run sig själv eller på MSBuild. Följande kommandorader är därför likvärdiga eftersom dotnet run de inte känner igen argumenten och alternativen:

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

Utelämnande av avgränsare för alternativ till argument

.NET CLI stöder inte POSIX-konventionen som gör att du kan utelämna avgränsare när du anger ett alternativalias med ett enda tecken.

Flera argument utan att upprepa alternativnamnet

.NET CLI accepterar inte flera argument för ett alternativ utan att upprepa alternativnamnet.

Booleska alternativ

I .NET CLI resulterar vissa booleska alternativ i samma beteende när du skickar false som när du skickar true. Det här beteendet resulterar i att .NET CLI-kod som implementerar alternativet endast söker efter förekomsten eller frånvaron av alternativet och ignorerar värdet. Ett exempel är --no-restore för dotnet build kommandot. Skicka no-restore false och återställningsåtgärden hoppas över på samma sätt som när du anger no-restore true eller no-restore.

Kebabväska

I vissa fall använder .NET CLI inte kebabfall för kommando-, alternativ- eller argumentnamn. Det finns till exempel ett .NET CLI-alternativ som heter --additionalprobingpath i stället för --additional-probing-path.

Dela via