-
Notifications
You must be signed in to change notification settings - Fork 8.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-standard command line parsing misinterprets semicolons inside arguments #13264
Comments
This seems very similar to #13255. We should consolidate them into one issue (prefer this one as it is more on-target.) |
I agree. Finding a way to split this up might be tricky.
|
In my personal opinion we should have as little surprising behavior as possible here. As such I'd say At this time I can think of two approaches:
|
Just so everyone is on the same boat - quotes are the thing that will make sure stuff will stay together in a single argv entry of application compiled with MSVC (compatible) compiler, on Windows - the compiler does the work of injecting parsing code that converts single-string windows commandline into an arg vector (aka. argv) for you.
edit;
This was mainly pointed at lheckers last paragraph.
I think zadjii-msft got it right; and brought an interesting question about `wt -p nt;nt` and `wt nt;nt;nt` - which is the core issue here actually; WT currently disrespects argument boundaries and treats `;` anywhere in the "positional args" as a special thing;
The only fix IMHO is to not do that, meaning that `wt nt;nt;nt` would try to start a process with command line `nt;nt;nt` (would work if there us such executable file)
|
I just I though about this again. I realized that forcing "windows standard CLI parsing" might actually not rly improve life of people who regulary invoke complicated bash CLIs through WT - the need to wrap the whole inner command line into However I can imagine that people like me (which struggles with this It would end-up having (maybe) 3 cli parsing modes ... there could be alternations to this; The thing is, I am not that familiar with WT's CLI switches; Must all switches (like |
Windows Terminal version
1.13.11431.0
Windows build number
10.0.19044.1706
Other Software
MSYS2 / Git for Windows bash (but really anything that regularly uses semicolons in their arguments, including filepaths)
Steps to reproduce
Relates to
#11314 (comment)
#11314 (comment)
I hope that given @lhecker already expressed his doubts about the current behaviour, there would be some motivation for a fix-by-breaking-change here.
Use your favorite way to create a process on windows, I used
start the following command line
wt.exe sh -c 'echo abcd\n && read -p prompt'
wt:
sh:
all works fine:
now change && for ; -> start:
wt sh -c 'echo abcd\n ; read -p prompt'
wt:
sh:
will fail
Now, I am able to take that somebody decided that semicolon
;
as an argument is a good tab splitting character, however obviously this is problematic in context of standard *nix shells.However, it is worse. WT ignores the "good citizens" rules about how command line is supposed to be parsed on windows (I really enjoyed reading this one again after long time).
https://daviddeley.com/autohotkey/parameters/parameters.htm
WT interprets semicolon
;
anywhere, in any argument, as command to spawn new tab, even if it is in a middle of "what should be parsed as a single argument" on windows!repro steps:
command line:
wt.exe sh -c "'echo abcd\n ; read -p prompt'"
wt:
the argument gets torn apart by the semicolon and the argument fails to start
there should be just one tab, and the command line to start
sh
should likesh -c "'echo abcd\n ; read -p prompt'"
(does not matter ifsh
can handle that well or not, see note bellow too)also:
command line:
wt.exe sh -c 'echo abcd\n; read -p prompt'
should work too, because the;
is not an isolated argument, but part of the argumentabcd\n;
So the command line passed used to start sh should be simplysh -c 'echo abcd\n; read -p prompt'
.note:
sh
is parsing the command line in a shell-way, that's why the argument with inner command line, passed after the-c
argument, can be enclosed in single quotes'
; However that is just a feature of this particular reproduction steps and does not affect the "core issue" in WT.Expected Behavior
WT does not treat
;
that are part of an command line argument (https://daviddeley.com/autohotkey/parameters/parameters.htm#WINCRULESCHANGE ,referencing MSDN docs) that contains other characters then the single;
(assuming spaces/tabs around arguments are trimmed by the command line argument parsing code) ascreate new tab
commands.Actual Behavior
WT treats all
;
in all arguments ascreate new tab
commands. As a consequence it is miss-interpreting arguments designed to reach "target CLI application".Such behaviour does not have any grounds in standard windows command line parsing procedures and leads to confusion and need for special workarounds, that would need to dynamically rewrite arguments being passed to WT.
The text was updated successfully, but these errors were encountered: