starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-25 08:24:54 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Discussion: commandline arguments in v0.9 are not user-friendly or readable? #6461

New Issue
Closed
opened 2026-01-31 00:39:21 +00:00 by claunia · 11 comments
claunia commented 2026-01-31 00:39:21 +00:00
Owner
Copy Link

Originally created by @Karl-WE on GitHub (Feb 15, 2020).

Make arguments user-friendly and type friendly

With ver 0.9 arguments to launch WT has been introduced. This is really a good feature addition.
However I find that the arguments are very linux like and unfriendly to new users:

please refer Ned Pyle:
https://twitter.com/NerdPyle/status/1227757778732601344

and Cinnamon examples:
wt -p "Windows PowerShell" -d . ; split-pane -V wsl.exe

wt -d C:\Users\cinnamon\GitHub\WindowsTerminal ; split-pane -p "Command Prompt" ; split-pane -p "Ubuntu" -d \wsl$\Ubuntu\home\cinnak -H

I do not feel this is userfriendly. Not everyone that want to replace cmd and powershell with a modern terminal is a dev

implement arguments that allow both written and readable and shortened args example, which exlcude using ambigous args

examples
-r or -run
-l or -list

Originally created by @Karl-WE on GitHub (Feb 15, 2020). <!-- --> # Make arguments user-friendly and type friendly With ver 0.9 arguments to launch WT has been introduced. This is really a good feature addition. However I find that the arguments are very linux like and unfriendly to new users: please refer Ned Pyle: https://twitter.com/NerdPyle/status/1227757778732601344 and Cinnamon examples: wt **-p** "Windows PowerShell" -d . ; split-pane **-V** wsl.exe wt -d C:\Users\cinnamon\GitHub\WindowsTerminal ; _split-pane_ -p "Command Prompt" ; split-pane -p "Ubuntu" **-d** \\wsl$\Ubuntu\home\cinnak **-H** I do not feel this is userfriendly. Not everyone that want to replace cmd and powershell with a modern terminal is a dev # implement arguments that allow both written and readable and shortened args example, which exlcude using ambigous args examples -r or -run -l or -list
claunia commented 2026-01-31 00:39:22 +00:00
Author
Owner
Copy Link

@beviu commented on GitHub (Feb 15, 2020):

I have not tested it but I think that should work:

wt --profile "Windows PowerShell" --startingDirectory . ; split-pane -V wsl.exe`
wt --startingDirectory C:\Users\cinnamon\GitHub\WindowsTerminal ; split-pane --profile "Command Prompt" ; split-pane --profile "Ubuntu" --startingDirectory \wsl$\Ubuntu\home\cinnak -H

You can read the doc here: https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingCommandlineArguments.md

@beviu commented on GitHub (Feb 15, 2020): I have not tested it but I think that should work: ```sh wt --profile "Windows PowerShell" --startingDirectory . ; split-pane -V wsl.exe` wt --startingDirectory C:\Users\cinnamon\GitHub\WindowsTerminal ; split-pane --profile "Command Prompt" ; split-pane --profile "Ubuntu" --startingDirectory \wsl$\Ubuntu\home\cinnak -H ``` You can read the doc here: https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingCommandlineArguments.md
claunia commented 2026-01-31 00:39:22 +00:00
Author
Owner
Copy Link

@Karl-WE commented on GitHub (Feb 15, 2020):

Yes majorly this is ok
as you stated in your link / command line reference.

for some reason it uses -- instead of - which is uncommon to Windows
at a glance -V and -H are missing readable -- args

given my suggestion it should be more understood like autocomplete or readable args

let's compare with diskpart where you can say

lis dis
or list disk

so for terminal this should be -p or -profile not only --profile to make it easier to distinguish.
as long commands are not ambigous this will work fine.
then I would refrain from using lower and uppercase args if this is not really neccessary

so either
-v or -vertical instead of -V --vertical

as we are still in the beginning of args in WT I hope design decisions can still be made and yet we are in a beta, no one can complain about more drastical changes here (there should be few productive scripts)

@Karl-WE commented on GitHub (Feb 15, 2020): Yes _**majorly**_ this is ok as you stated in your link / command line reference. for some reason it uses -- instead of - which is uncommon to Windows at a glance -V and -H are missing readable -- args given my suggestion it should be more understood like autocomplete or readable args let's compare with diskpart where you can say lis dis or list disk so for terminal this should be -p or -profile **not only** --profile to make it easier to distinguish. as long commands are not ambigous this will work fine. then I would refrain from using lower and uppercase args if this is not really neccessary so either -v or -vertical instead of -V --vertical as we are still in the beginning of args in WT I hope design decisions can still be made and yet we are in a beta, no one can complain about more drastical changes here (there should be few productive scripts)
claunia commented 2026-01-31 00:39:22 +00:00
Author
Owner
Copy Link

@Karl-WE commented on GitHub (Feb 15, 2020):

another addition about consistency:
help feature allows familiar commands as /? -help and also --help

If we want to keep -- args for linux friendlyness, please allow to additionally use all args with just one - for Windows / Powershellists

This might please all usergroups which are used to - or -- arguments.

@Karl-WE commented on GitHub (Feb 15, 2020): another addition about consistency: help feature allows familiar commands as /? -help and also --help If we want to keep -- args for linux friendlyness, please allow to _additionally_ use all args with just one - for Windows / Powershellists This might please all usergroups which are used to - or -- arguments.
claunia commented 2026-01-31 00:39:23 +00:00
Author
Owner
Copy Link

@Jaykul commented on GitHub (Feb 17, 2020):

Well, I don't think Windows-native command-line apps have ever had a consistent (or readable) parameter experience, outside of PowerShell 😉

But why are we using linux syntax --longWords and Case Sensitive -Hp initials-stuck-together syntax on a Windows app? This syntax is not at all native or intuitive on this platform.

Before PowerShell, Windows apps did not use dashes at all, never mind double-dashes. We used /profile or /p and we didn't allow combining short forms.

In PowerShell, parameters are not case sensitive, and we still don't support the concept of combining short-form parameters.

The syntax split-pane -Hp "Windows PowerShell" just isn't normal in Windows.

@Jaykul commented on GitHub (Feb 17, 2020): Well, I don't think Windows-native command-line apps have ever had a consistent (or readable) parameter experience, outside of PowerShell 😉 But why are we using linux syntax `--longWords` and **Case Sensitive** `-Hp` initials-stuck-together syntax on a Windows app? This syntax is not at all native or intuitive on this platform. Before PowerShell, Windows apps did not use dashes at all, never mind double-dashes. We used `/profile` or `/p` and we didn't allow combining short forms. In PowerShell, parameters are not case sensitive, and we still don't support the concept of combining short-form parameters. The syntax `split-pane -Hp "Windows PowerShell"` just isn't normal in Windows.
claunia commented 2026-01-31 00:39:23 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Feb 18, 2020):

But why are we using linux syntax --longWords and Case Sensitive -Hp initials-stuck-together syntax on a Windows app? This syntax is not at all native or intuitive on this platform.

Perhaps it could be made better but you are forgetting the primary users of Terminal are also using WSL. It is extremely likely that compatibility will be broken if that syntax isn't used.

@WSLUser commented on GitHub (Feb 18, 2020): > But why are we using linux syntax --longWords and Case Sensitive -Hp initials-stuck-together syntax on a Windows app? This syntax is not at all native or intuitive on this platform. Perhaps it could be made better but you are forgetting the primary users of Terminal are also using WSL. It is extremely likely that compatibility will be broken if that syntax isn't used.
claunia commented 2026-01-31 00:39:24 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Feb 21, 2020):

I'm marking this as the discussion area for commandline arguments.

@DHowett-MSFT commented on GitHub (Feb 21, 2020): I'm marking this as the discussion area for commandline arguments.
claunia commented 2026-01-31 00:39:24 +00:00
Author
Owner
Copy Link

@Jaykul commented on GitHub (Feb 22, 2020):

the primary users of Terminal are also using WSL

I don't know what makes those of us using WSL the "primary" users. Every user of Terminal is also using Windows. WSL is a Windows app (which is why it has awful pop-up help behavior).

likely that compatibility will be broken if that syntax isn't used.

I'm sorry, but that's hogwash. Show me how using -parameter instead of --parameter "breaks" anything other than the expectations of posix users.

The idea that we should use posix-normal parameter syntax in a Windows app that pops up dialogs to show help is really just guaranteeing confusion. WSL users will use a lot of windows apps, both CLI and Windowed. None of those apps will use this syntax.

@Jaykul commented on GitHub (Feb 22, 2020): > the primary users of Terminal are also using WSL I don't know what makes those of us using WSL the "primary" users. **Every** user of Terminal is also using Windows. WSL is a Windows app (which is why it has awful pop-up help behavior). > likely that compatibility will be broken if that syntax isn't used. I'm sorry, but that's hogwash. Show me how using `-parameter` instead of `--parameter` "breaks" anything other than the expectations of posix users. The idea that we _should_ use posix-normal parameter syntax in a Windows app that pops up dialogs to show help is really just guaranteeing confusion. WSL users will use a lot of windows apps, both CLI and Windowed. **None of those apps will use this syntax**.
claunia commented 2026-01-31 00:39:24 +00:00
Author
Owner
Copy Link

@Karl-WE commented on GitHub (Feb 23, 2020):

@DHowett-MSFT the original intention is a feature request. I am unsure if "discussions" will change anything in the product. Can you outline how this discussion will be handled by PM and designers?

@Karl-WE commented on GitHub (Feb 23, 2020): @DHowett-MSFT the original intention is a feature request. I am unsure if "discussions" will change anything in the product. Can you outline how this discussion will be handled by PM and designers?
claunia commented 2026-01-31 00:39:24 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 25, 2020):

Okay so that's on me for not adding the long form of those args. I kinda threw the whole split-pane command into that PR, I definitely should have had long forms for those 😅

In general, we'll be having both long and short forms for the args we add to commands. Everything else in that spec has them, but sometimes when writing/reviewing a 700 line spec, you miss some of the details 😜

Just now, I actually discovered that CLI11 (which we're using for parsing the args) actually also implicitly supports the /d, /startingDirectory format for args as well. So as it turns out, wt supports both --unixStyleArgs and /windowsStyleArgs. Not only that, but the short windows forms actually doesn't support combining either (eg wt split-pane /Hp "Windows Powershell" doesn't work) . How neat!

@zadjii-msft commented on GitHub (Feb 25, 2020): Okay so that's on me for not adding the long form of those args. I kinda threw the whole `split-pane` command into that PR, I definitely should have had long forms for those 😅 In general, we'll be having both long and short forms for the args we add to commands. Everything else in that spec has them, but sometimes when writing/reviewing a 700 line spec, you miss some of the details 😜 Just now, I actually discovered that CLI11 (which we're using for parsing the args) actually also implicitly supports the `/d, /startingDirectory` format for args as well. So as it turns out, `wt` supports both `--unixStyleArgs` and `/windowsStyleArgs`. Not only that, but the short windows forms actually **doesn't** support combining either (eg `wt split-pane /Hp "Windows Powershell"` doesn't work) . How neat!
claunia commented 2026-01-31 00:39:24 +00:00
Author
Owner
Copy Link

@Karl-WE commented on GitHub (Mar 1, 2020):

I am looking forward how this will turn out in the future.

@Karl-WE commented on GitHub (Mar 1, 2020): I am looking forward how this will turn out in the future.
claunia commented 2026-01-31 00:39:25 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 15, 2020):

Hey so this discussion seems to have run it's course. Since we're getting imminently close to 1.0 at this point, and it doesn't seem like we're about to dramatically change the surface of the commandline args, I'm going to close this discussion. I think we've addressed most of the complaints in the OP about not having --longForm versions of most parameters at this point, and the documentation is updated to reflect that.

Thanks for the feedback everyone!

@zadjii-msft commented on GitHub (Apr 15, 2020): Hey so this discussion seems to have run it's course. Since we're getting imminently close to 1.0 at this point, and it doesn't seem like we're about to dramatically change the surface of the commandline args, I'm going to close this discussion. I think we've addressed most of the complaints in the OP about not having `--longForm` versions of most parameters at this point, and the documentation is updated to reflect that. Thanks for the feedback everyone!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Commandline Issue-Question Product-Terminal Resolution-Answered
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#6461
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?