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
Do not error on native binary that handles @ to expand response file contents as args #12491
Comments
@rkeithhill I assume quoting the argument is all that's needed to make it work - correct? We could update the error message to say that "blah, blah ... quote arguments starting with '@' blah blah ...". As far as "fixing" this, I just worry that, given how complex parameter binding already is, adding more special cases could ultimately make things worse, not better. How much of an issue do think this is? |
That is correct. It is a fair point to ask if the increased parameter binding complexity is worth it. As for the question of how much of an issue this is ... that is hard to say but I expect it is more of an issue now that new (Linux/macOS) users are kicking the tires on PowerShell. The problem is sort of a "first impression" issue. For most folks, their first impression is how well PowerShell does at executing commands from the console. The command line I listed above was from a training class on Conan. The first attempt in PowerShell was a failure - not a good first impression. That said, there are so many of these issues - |
And all will be a huge breaking change. Do we really want this if |
Adding some "mitigation tips" to error messages wouldn't be breaking. Right now we leave new folks with nothing really to go on. Look at the original post's error message. That error message IN NO WAY helps the user in this case. I think we could be smarter about parameter errors when they are for native applications and provide some tips in the error message like using |
Another thought is that if we say about interactive user session we could introduce "native command mode" - in the mode first execute input string "as-is" without parsing arguments and use "&" to force parsing. |
If we could do that in a non-breaking way that would be cool. That might also be able to address another issue where you'd like to invoke a native app and bypass any aliases or functions that happen to have the same name. I remember this issue was discussed quite a while back but nothing ever came of it. Well, except that certain aliases like |
It is a breaking change I think. I like it. PS >& <Enter> # We could use '&' to switch mode
PS &> # Now we are in native command mode
PS &>& <enter> # Switch back in PowerShell command mode
PS > # Now we are in PowerShell command mode Perhaps @JamesWTruher @daxian-dbw and @TylerLeonhardt could share thoughts. |
For the splatting sigil, we could always treat that as literal for native commands since you can't splat to native commands. However, the other characters that match to pwsh syntax is problematic. One possible solution is to have a suggestion based on a non-zero exit code that could check if any of those characters were used and suggest quoting them or using `--%' (which makes that switch more discoverable as I'm sure most users aren't familiar with it) |
Native commands can have arrays splatted to them, so we can't assume $params = @(
'/c'
'ping 1.1.1.1'
)
cmd @params Also, to provide such a suggestion... we should probably fix up the suggestions feature first, so that we don't end up increasing the necessary work for that in future (assuming that's still something we want to do sooner or later). |
@vexx32 yeah, forgot about that was only thinking about hashtables. Agree we need to fix up the suggestion feature first for other reasons :) |
Me like. :-) |
Food for thought - maybe it's possible to work like people expect most of the time.
|
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. |
2 similar comments
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. |
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. |
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes. |
Summary of the new feature/enhancement
This might be a stretch but this is another one of those unfortunate gotchas when a dev is trying to use PowerShell to invoke commands that have been documented. Here's the problem:
In this case,
conanbuildinfo.args
is a file, specifically a response file that contains a bunch of arguments tog++
. It is not that uncommon for exes to use a response file specified with@response_filename
.Proposed technical implementation details (optional)
I'm not entirely sure what the solution is but maybe in this case before erroring when the variable is not found (
conanbuildinfo
in the example above), consider passing the arg as-is to the native binary assuming it will handle the@
. This might be worth emitting a warning. Something like:Could not find splatted variable 'conanbuildinfo', passing argument as-is to the application. To avoid this warning, put single quotes around the argument.
. Also, if strict mode is set, maybe this should go ahead and error?The text was updated successfully, but these errors were encountered: