GeezerVison is showing github.com — CLI: when installed as a .NET global tool (dotnet tool), argument parsing is broken · Issue #11747 · PowerShell/PowerShell
CLI: when installed as a .NET global tool (dotnet tool), argument parsing is broken #11747DescriptionNote:
Steps to reproduce
# NOTE:
# * Problem shows if `pwsh` was installed via `dotnet tool --global`
# * Run from *cmd.exe* or *bash*
pwsh -noprofile -c "write-output 1 \"2 3\"" Expected behavior
That is, the escaped embedded double quotes (\") should be honored, resulting in two outputs, 1, and '2 3'.
This is indeed what happens with a regularly installed version.
Actual behavior
This output suggests that the embedded escaped double quotes (\") were unexpectedly eaten.
Environment data
PowerShell Core 7.0 # as a global .NET tool, all platforms
Reacted by Bo Lingen, Gennadii Saltyshchak and Friedrich von Never Reacted by Bo Lingen Reacted by Bo Lingen Activitychanged the title [-]CLI: argument parsing when installed as a .NET global tool (dotnet tool) is broken[/-] [+]CLI: when installed as a .NET global tool (dotnet tool), argument parsing is broken[/+] on Jan 31, 2020gerardog commented on Feb 2, 2020 I think I have a clue about this one:
The Global Tool Shim is accepting the args[] as provided in the main function by .NET.
|
string argsString = args.Length > 0 ? string.Join(" ", args) : null; |
However, to keep the quotes correctly it should be using either Environment.CommandLine
or Win32Api:
[DllImport("kernel32.dll", CharSet = CharSet.Auto)]
public static extern System.IntPtr GetCommandLine();
Hope it helps.- Reacted by Michael Klement mklement0 commented on Feb 2, 2020 ContributorAuthor More actions Nice sleuthing, Gerardo Grignoli (@gerardog).
The simplest and robust solution is to copy the elements of args to a ProcessStartInfo instance's ArgumentList property (a new, collection-based alternative to the single-string .Arguments property), which on Windows performs proper re-quoting and escaping as necessary, and on Unix passes the already-parsed arguments through as an array:
// Use ProcessStartInfo.ArgumentList to robustly pass arguments through.
var psi = new ProcessStartInfo("dotnet");
psi.ArgumentList.Add(pwshPath);
foreach (var arg in args) { psi.ArgumentList.Add(arg); }
if (File.Exists(pwshPath))
{
var process = System.Diagnostics.Process.Start(psi);
process.WaitForExit();
return process.ExitCode;
}gerardog commented on Apr 22, 2022
which on Windows performs proper re-quoting and escaping as necessary
Does it?
A few edge cases:
- Arguments without spaces wrapped in single or double quotes, will be re-quoted?
- Arguments with spaces wrapped in single quotes, will be re-quoted in double quotes?
Thanks mklement0 commented on Apr 22, 2022 ContributorAuthor More actions
Does it?
Yes, assuming the target application uses the command-line parsing rules of C/C++/.NET applications, as described here.
That's the best that can be done - ultimately, any application is free to make up its own parsing rules.
As for the edge cases:
Arguments without spaces wrapped in single or double quotes, will be re-quoted?
No - if an argument contains no spaces, it is passed unquoted, irrespective of whether it was quoted or not on the original command line.
Arguments with spaces wrapped in single quotes, will be re-quoted in double quotes?
Yes. microsoft-github-policy-service commented on Nov 16, 2023 This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 16, 2023 This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 16, 2023 This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 23, 2023 This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.
Reacted by Gerardo Grignoli and Bo Lingen ForNeVeR commented on Mar 12, 2024 Folks, this problem keeps reappearing from time to time in different random places (see the linked issues). Perhaps the bot was too eager to close it? I believe it should be addressed, for PowerShell to be a more robust / reliable tool for all the use cases.
Currently, the argument/quotes parsing changes depending on the way you install PowerShell in your system. This can't be good, can it? Reacted by Gerardo Grignoli gerardog commented on Mar 13, 2024 Thanks Friedrich von Never (@ForNeVeR)! After so much time...
And yes, that bot is infuriating. I am very sorry to say this, but sometimes, negative feedback makes a difference, so here it goes: Steven Bucher (@StevenBucher98), when you activated the bot on Nov 16 2023 and gave just 6 days from warning to closure, you really messed up. This ticket is the proof of it. You should manually review all tickets closed on Nov 22, 2023 and evaluate if they need a second try.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|