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

[Karl-WE]

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

[beviu]

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

[Karl-WE]

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]

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.

[Jaykul]

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.

[WSLUser]

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.

[DHowett-MSFT]

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

[Jaykul]

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.

[Karl-WE]

@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?

[zadjii-msft]

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!

[Karl-WE]

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

[zadjii-msft]

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!