Home Dashboard Directory Help
Search

Native Application Command Line Parameters Parsing by ColinBowern


Status: 

Closed
 as Won't Fix Help for as Won't Fix


4
1
Sign in
to vote
Type: Suggestion
ID: 792571
Opened: 7/4/2013 7:28:52 AM
Access Restriction: Public
1
Workaround(s)
view

Description

I love PowerShell and am glad to see it has become the default in the Win+X menu. There are still scenarios, however, where PowerShell does not handle command line arguments correctly. Here is one of them:

BCDEdit /copy {default} /d "Hypervisor Disabled"

You can use the new PowerShell literal command line flag to make it work:

BCDEdit --% /copy {default} /d "Hypervisor Disabled"

But I'd argue that is not very intuitive. It also breaks down when you come across commands like this:

MSDeploy.exe -verb:delete -verbose -dest:contentPath='$SiteName/App_Offline.htm',computerName='$SiteManagementUrl'

Which break because the dest parameter gets double quotes around it which the app cannot interpret:

MSDeploy.exe -verb:delete -verbose "-dest:contentPath='Default WEb Site/App_Offline.htm',computerName='https://web:8172/msdeploy.axd?SiteName=Default+Web+Site'"

I'd like to see some more thought put into making the command line execution experience just work, or at minimum providing some guidance for these sorts of breaking scenarios.
Details
Sign in to post a comment.
Posted by ColinBowern on 7/26/2013 at 5:46 PM
It is disappointing that this won't be fixed given the emphasis in Windows 8.1 / Server 2012 R2 to use PSH as the default shell. The --% option doesn't address the scenario where you need to use variables to build the command line which is most of the time when doing system automation.
Posted by Microsoft on 7/26/2013 at 2:04 PM
bcdedit and msdeploy are the two native command-line tools that are still difficult to invoke from PowerShell given their unique syntax. We've added the stop-parsing symbol (--%) to help with these scenrios which works for bcdedit. For msdeploy, please see http://technet.microsoft.com/en-us/library/dd569106(v=WS.10).aspx. We are not investing in additional improvements to native argument parsing at this time.
Posted by vegitakicker on 7/21/2013 at 4:11 AM
I can confirm that this is an issue, and as it is to take over for powershell, it should be made compatible with the current CMD commands that we enjoy from time to time, without having to actually start the cmd itself.

I discovered that the DEP commands does not work:

bcdedit /set {current} nx AlwaysOff
bcdedit /set {current} nx AlwaysOn

If you desire to completely turn off DEP, this would be nice to work in powershell itself and not just cmd.
Sign in to post a workaround.
Posted by ColinBowern on 7/4/2013 at 7:34 AM
Only workaround I have found so far is spawning a native process or command shell. See http://huddledmasses.org/the-problem-with-calling-legacy-or-native-apps-from-powershell/ for an example. Not ideal because you need to capture and redisplay output or have the process spawn another window.