Votes from Connect: 12

Original Date Submitted: 4/11/2013 6:35:26 AM

Description:
Contact Information
Handle: Keith Hill MVP
Site Name: PowerShell
Feedback ID: 783409

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
The output of Get-Command for exes is pretty much worthless:

PS> gcm mstest

CommandType Name ModuleName

Application MSTest.exe

I usually know it is an exe and I certainly know the name. What I want to know is the path for the exe. Don't make me go having to look for that when it's the most common thing folks want to know. And if there's room, the file version is often something folks want to know about an exe.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 783409 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=783409).

Repro Steps:
Execute Get-Command <exename>.
You get CommandType, Name and ModuleName which is always empty from what I can tell.

Expected Results:

What I expect to see is the path where the exe is found and maybe even its file version e.g.:

PS> gcm mstest

CommandType Name FileVersion Path

Application MSTest.exe 11.0.50727.1 C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\MSTest.exe

Internal BugId: 4176

Votes from Connect: 43

Original Date Submitted: 3/26/2013 1:25:17 AM

Description:
Contact Information
Handle: Trevor Sullivan
Site Name: PowerShell
Feedback ID: 782064

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
When using the Get-WmiObject cmdlet, lots of WMI metadata is included with the resulting objects including:

1. WMI qualifier names/values (and qualifier metadata: IsAmended, IsLocal, PropagatesToInstance, PropagatesToSubclass, IsOverriable)


2. System properties


3. WMI class path (eg. \servername\root\cimv2:Win32_ComputerSystem.Name="servername")


4. WMI instance path (eg. \servername\root\cimv2:Win32_ComputerSystem)


5. ManagementScope options via "Scope" property


6. WMI class-level information: DERIVATION, DYNASTY, SUPERCLASS, _SERVER, NAMESPACE, PATH, GENUS, __RELPATH, et al.


7. ... and probably others I'm missing

This information is absolutely vital to effectively developing automation scripts leveraging the Windows Management Instrumentation (WMI) service.

Unfortunately, the CIM cmdlets module does not return the same information as Get-WmiObject does. Please modify the CIM cmdlets to include this vital WMI metadata. In some cases, the data format may differ somewhat: eg. WMI object paths may be express using WS-Management lingo, instead of WMI monikers.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 782064 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=782064).

Repro Steps:
1. Launch PowerShell
2. Use CIM cmdlets (eg. Get-CimInstance -Class Win32_ComputerSystem)
3. Notice the lack of WMI metadata described

Expected Results:
The appropriate WMI metadata should be returned from CIM cmdlets in the PowerShell 3.0 CIMcmdlets module.

Internal BugId: 4158

Votes from Connect: 12

Original Date Submitted: 3/5/2013 8:42:45 AM

Description:
Contact Information
Handle: Matthew Reynolds [MSFT]
Site Name: PowerShell
Feedback ID: 780634

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
The utility of Show-Command as a GUI front end enabling less skilled users to execute a task oriented script/function is impaired by the fact that default values cannot be shown.
Having the ability to display default values has two usability benefits:
1) It gives the user an idea of what they really need to configure and what they can leave alone
2) It gives the user a pattern to follow even if they are changing values ("oh, I can put a comma separated list of computer names in that field")

Product Studio item created by Connect Synchronizer due to creation of feedback ID 780634 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=780634).

Repro Steps:
function Test-ShowCommand {
param(
$SomeArcaneSetting = 7
)

}

Show-Command Test-ShowCommand

Expected Results:
Should show (at least optionally) 7 as a replaceable default value for SomeArcaneSetting. Does not.

Internal BugId: 4140

Votes from Connect: 11

Original Date Submitted: 2/27/2013 4:19:23 PM

Description:
Contact Information
Handle: Anders P
Site Name: PowerShell
Feedback ID: 780084

Frequency: Sometimes Happens
Regression: Yes, this happens in all previous versions

Problem Description:
Functionality could be build into CMDlets could be Remove-Item, Copy-Item, Move-Item via the -force parameter, or if thats too risky, new CMDlets could be invented like Get-Owner or Set-Owner.

I would really enjoy to see the integration of TakeOwn.exe, SubInACL.exe and iCacls.exe functionality into CMDlets

Windows transform so many windows-executables with different syntax into CMDlets, and that makes life as an admin so much easier and enjoyable.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 780084 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=780084).

Repro Steps:
N/A

Expected Results:
N/A

Internal BugId: 4136

Votes from Connect: 16

Original Date Submitted: 1/21/2013 3:51:42 AM

Description:
Contact Information
Handle: Rohn Edwards
Site Name: PowerShell
Feedback ID: 777012

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
When running Update-Help using the -SourcePath parameter on a machine without an internet connection that has had the help updated already, the command fails with "Unable to connect to Help content. Make sure the server is available and then try the command again." The Save-Help and Update-Help combination works perfectly when updating the help on a system with no help installed. I've seen this on Windows 7 and 8 (both 64-bit).

Deleting helpinfo.xml files from the PowerShell folder ('dir $PSHome -filter helpinfo.xml -recurse | Remove-Item -Confirm') seems to be a workaround for the issue.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 777012 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=777012).

Repro Steps:
1. Call Save-Help to save the help files
2. Disable the network adapters on the computer
3. Call Update-Help with the -SourcePath parameter pointing to the saved help files

If step #3 is successful, repeat it since it works if no help has been installed.

Expected Results:
Successful call to Update-Help without removing helpinfo.xml files so that computers that are on networks not connected to the internet can be updated on a semi-regular basis.

Internal BugId: 4089

Votes from Connect: 11

Original Date Submitted: 11/5/2012 5:15:07 AM

Description:
Contact Information
Handle: Sean Kearney
Site Name: PowerShell
Feedback ID: 770035

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
When Executing a PS-Remoting Session from a Microsoft Surface Device with Windows RT using Powershell 3.0 to Powershell 2.0 on a remote server (with defined trusts in WinRM) Implicit remoting fails

An interactive session on the x64 Remote server works fine, but using an IMPORT-PSSESSION with -prefix parameter fails to produce any available cmdlets.

EXPORT-PSSESSION will produce a module on the local Windows RT device but the module will not load and execute

Product Studio item created by Connect Synchronizer due to creation of feedback ID 770035 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=770035).

Repro Steps:
Add Client system as "Trusted" I WinRM on remote host
Add remote Host as "Trusted" on WinRM in Windows RT device

execute
$s=NEW-PSSESSION -computer Netbios1 -credential (GET-CREDENTIAL)
(enter credentials for WinRM remoting on Remote system Netbios1)
IMPORT-PSSESSION $S -prefix XX
(To produce new verbs with an "XX" prefix from the remote system)

Expected Results:
If you would like to run something like GET-CHILDITEM C:\THISFOLDER (as an example on the remote system) and store the results in $X

$X=GET-XXCHILDITEM C:\THISFOLDER

It should execute "GET-CHILDITEM C:\THISFOLDER" on remote System NETBIOS1

It fails as the cmdlets do not appear as available cmdlets on the local system

BUT

ENTER-PSSESSION $S
GET-CHILDITEM C:\THISFOLDER

Works fine

Internal BugId: 3937

Votes from Connect: 25

Original Date Submitted: 10/4/2012 10:09:17 PM

Description:
Contact Information
Handle: Kirk Munro
Site Name: PowerShell
Feedback ID: 766100

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
When you invoke Get-ChildItem in PowerShell 3.0 with a path that does not exist, it searches for all files instead (wtf?). If you combine that with -Recurse and -ErrorAction SilentlyContinue in a script, you're facing a huge performance degradation that won't be easy to spot. Consider the two transcripts below. They show that a single Get-ChildItem call using a path that does not exist on my system takes 1302 times longer on v3 than it does on v2! I intentionally left -ErrorAction off of the command so that errors showing the scope of the search actually being performed by Get-ChildItem could be seen by the errors that identify the paths it is hitting when the command is run.

PowerShell 2 Transcript:

PS C:&gt; Measure-Command {gci -li C:\MyFolder -Recurse -Force}
gci : Cannot find path 'C:\MyFolder' because it does not exist.
At line:1 char:21
+ Measure-Command {gci <<<< -li C:\MyFolder -Recurse -Force}

+ CategoryInfo          : ObjectNotFound: (C:\MyFolder:String) [Get-ChildItem], ItemNotFoundException

+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : 29
Ticks : 292580
TotalDays : 3.38634259259259E-07
TotalHours : 8.12722222222222E-06
TotalMinutes : 0.000487633333333333
TotalSeconds : 0.029258
TotalMilliseconds : 29.258

PowerShell 3 Transcript:

PS C:&gt; Measure-Command {gci -li C:\MyFolder -Recurse -Force}
gci : Access to the path 'C:\Documents and Settings' is denied.
At line:1 char:18
+ Measure-Command {gci -li C:\MyFolder -Recurse -Force}
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : PermissionDenied: (C:\Documents and Settings:String) [Get-ChildItem], UnauthorizedAccess

Exception

+ FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand

<snip>

gci : Access to the path 'C:\Users\Public\Documents\My Videos' is denied.
At line:1 char:18
+ Measure-Command {gci -li C:\MyFolder -Recurse -Force}
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : PermissionDenied: (C:\Users\Public\Documents\My Videos:String) [Get-ChildItem], Unauthor

izedAccessException

+ FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand

gci : Access to the path 'C:\Windows\System32\LogFiles\WMI\RtBackup' is denied.
At line:1 char:18
+ Measure-Command {gci -li C:\MyFolder -Recurse -Force}
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : PermissionDenied: (C:\Windows\Syst...es\WMI\RtBackup:String) [Get-ChildItem], Unauthoriz

edAccessException

+ FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand

Days : 0
Hours : 0
Minutes : 0
Seconds : 38
Milliseconds : 109
Ticks : 381091208
TotalDays : 0.000441077787037037
TotalHours : 0.0105858668888889
TotalMinutes : 0.635152013333333
TotalSeconds : 38.1091208
TotalMilliseconds : 38109.1208

Product Studio item created by Connect Synchronizer due to creation of feedback ID 766100 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=766100).

Repro Steps:
gci -li C:\DoesNotExist -Recurse

Expected Results:
This should return immediately with an error indicating that C:\DoesNotExist does not exist, just like it did in PowerShell 2.0.

Internal BugId: 3858

Votes from Connect: 12

Original Date Submitted: 9/19/2012 5:52:24 AM

Description:
Contact Information
Handle: TobiasWeltner
Site Name: PowerShell
Feedback ID: 763406

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
when you press F1 in ISE 3.0, the word the cursor is in is used as a keyword, and ISE executes this code:

Get-Help "keyword" -ShowWindow

The problem here are the double-quotes. The keyword should be placed into single quotes. With double quotes, unexpected behavior and accidental code execution is possible.

See details section below for steps to repro.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 763406 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=763406).

Repro Steps:
Run this code in ISE:
$test = 'Get-Service'

Place the cursor anywhere into $test and press F1.
Help for Get-Service opens. There should have been help for variables instead or no help at all BUT NOT help based on the content of the variable.

Type this into ISE:
$test = '$(Restart-Computer -whatif)'
Select the text inside the quotes and press F1.
Help opens, and at the same time the selected code executes.

Expected Results:
ISE should place the keyword into single quotes to ensure that it is taken literally and not converted or invoking code execution.

Internal BugId: 3828

Votes from Connect: 78

Original Date Submitted: 9/18/2012 6:29:36 PM

Description:
Contact Information
Handle: Peter Kriegel
Site Name: PowerShell
Feedback ID: 763246

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
In PowerShell 3.0 there are no help files available in German language. But I would consider missing help as top priority here. Most of the the east German peoples are never learned English (they learned Russia). Even for Peoples who can read English, there is a big danger to misunderstood something. Reading documentation in a foreign language can be very challenging.

Calling the -online Help every time, i need verbose English Help, is no solution. Because i am sitting in a corporate Network with Proxy and no Internet Access!

I have downloaded the English verbose HelpFiles with Save-Help -UICulture 'en-US' but i cant acces this Helpfiles. Because the Help depends on the UI Culture of my current Windows setting.
I cant display them without changind my UI Culture in Windows!
Should i switch my Windows setting allways if i need verbose English help?

I Like to display choose the German AND EVEN the English help without changing my UI Culture in Windows or PowerShell!

Get-Help Get-Comand -Culture "en-US" -Full # should display the Englisch verbose Help
Get-Help Get-Comand -Culture "de-DE" -Full # should display the German verbose Help

Product Studio item created by Connect Synchronizer due to creation of feedback ID 763246 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=763246).

Repro Steps:
Get-Help = consise crippeld German help

Expected Results:
Get-Help = Verbose (-full) German help OR verbose (-full) English Help without dependency of the UI Culture!

Internal BugId: 3818

Votes from Connect: 23

Original Date Submitted: 9/18/2012 3:37:35 AM

Description:
Contact Information
Handle: Bartek Bielawski
Site Name: PowerShell
Feedback ID: 763122

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
There is no help available in Polish both in previous versions and in current version of PowerShell. Actually - nothing is really localized to Polish (including menus in ISE, most of error messages). But I would consider missing help as top priority here: it's not big issue for people who are fluent in English, but reading documentation in foreign language can be challenging.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 763122 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=763122).

Repro Steps:
Just run Get-Help on pl-PL machine and watch English text showing up. If you prefer other language than English - you may try to use Update-Help -UICulture <other-supported-culture>, but pl-PL is not supported at all...

Expected Results:
At least some documents (about_* topics for starter) could be localized to help administrators in Poland understand major PowerShell concepts, even if they are not fluent in English (most of them are, but that's not the point).

Internal BugId: 3816

Votes from Connect: 11

Original Date Submitted: 7/13/2012 3:45:58 AM

Description:
Contact Information
Handle: RichardMcKenzie
Site Name: PowerShell
Feedback ID: 753494

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
A new bug has been introduced in powershell v3.0 - RC that does not exist in v3.0 CTP2.

It appears that .ps1 scripts fail to execute and throw the runtime error "Executable script code found in signature block" if the following line appears in the script:

organizational unit filter

Product Studio item created by Connect Synchronizer due to creation of feedback ID 753494 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=753494).

Repro Steps:
enter the following line into any powershell v3.0-RC script and it will fail

organizational unit filter

ISE will highlight all subsequent code with red underline and show the mouse-hover message "Executable script code found in signature block" and attempts to execute the script will fail with the same runtime exception.

I have tried a few variations, and it appears that only that very specific string causes a failure ... adding any other non-whitespace character to that string removes the error.

What are the chances anyone else would come across that obscure bug ??? heh heh ... oh well ... keep up the good work - loving powershell

Richard McKenzie
richard@rmck.com

Notes:
- execution policy is set to bypass
- works from v3 CTP2 machine on same network & domain, running same OS

Richard McKenzie

Expected Results:

Internal BugId: 3709

Votes from Connect: 10

Original Date Submitted: 7/12/2012 9:58:36 PM

Description:
Contact Information
Handle: sba
Site Name: PowerShell
Feedback ID: 753454

Frequency: Always Happens
Regression: Yes, this happens in previous beta versions

Problem Description:
Given that PS3 will not be available for legacy operating systems, and that PS3 will not be deployed everywhere overnight, it is currently required to write scripts that are backwards-compatible with PS2.

This can be achieved by:
- using 'Set-StrictMode-version 2.0'
- testing in a host created by running 'powershell -version 2.0'

But it's not possible to develop using the ISE in PS2 mode.

IMVHO this makes migration to PS3 more difficult and time-consuming than it has to be.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 753454 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=753454).

Repro Steps:
powershell_ise -version 2.0

fails

Expected Results:
This should start an ISE that uses version 2 of the language

Internal BugId: 3706

Votes from Connect: 18

Original Date Submitted: 6/28/2012 2:16:48 AM

Description:

Contact Information
Handle: Trevor Sullivan
Site Name: PowerShell
Feedback ID: 751184

Frequency: Always Happens
Regression: I don't know if this issue existed previously

Problem Description:
The PowerShell ISE v3 Release Preview does not show the parameter name in the Intellisense window, for a parameter that already has a value define (based on its position).

Product Studio item created by Connect Synchronizer due to creation of feedback ID 751184 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=751184).

Repro Steps:
1. Open ISE v3 Release Preview
2. In a new script window, type a cmdlet and a value for its first positional parameter (eg. gci *.txt)
3. Place cursor directly after cmdlet name
4. Type [Space] + '-' to invoke Intellisense for parameter names
5. Notice that the parameter at position 0 is not listed

Expected Results:
The parameter name should be listed in Intellisense, if it has not already been explicitly used elsewhere in the command.

Internal BugId: 3676

Votes from Connect: 56

Original Date Submitted: 1/13/2011 12:03:33 AM

Description:
Contact Information
Handle: Oisin Grehan
Site Name: PowerShell
Feedback ID: 635713

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
From Vista onwards, Windows supports both a transacted registry (TxR) and transacted filesystem (TxF). With powershell v2, we got TxR support. For v3 or beyond, it would be great to have TxF support. A good example taking Pscx's archive cmdlets into account would be the following pipeline:

PS> dir c:\logs\ -rec -inc *.log -usetx | write-zip -removeoriginal -usetx | move-item c:\archived_logs\ -usetx

This will recursively search C:\logs for *.log files, compress them with maximum compression, move them to c:\archived_logs and then delete the original. Transaction support ensures that a failed zip operation (or some other unknown/expected failure) will not result in one of the source files being removed with a corresponding zip backup.

Yes, it's possible to write careful code that will verify written zips etc but even that code may fail in certain circumstances. Tx support keeps it clean and reliable.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 635713 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=635713).

Repro Steps:
n/a

Expected Results:
n/a

Internal BugId: 2784

Votes from Connect: 21

Original Date Submitted: 10/8/2010 4:46:21 PM

Description:
Contact Information
Handle: TobiasWeltner
Site Name: PowerShell
Feedback ID: 611703

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
Start-Transcript logs input and output. This creates huge log files.
There should be a switch that enables Start-Transcript to only log the inputs and omit the outputs. Optionally, there could be an indicator whether a command completed successfully, was aborted or raised an exception.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 611703 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=611703).

Repro Steps:
currently default behavior

Expected Results:
new switch like -small that omits transcribing command results

Internal BugId: 2710

Votes from Connect: 16

Original Date Submitted: 8/9/2010 1:34:16 AM

Description:
Contact Information
Handle: Aleksandar Nikolic
Site Name: PowerShell
Feedback ID: 584518

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
I would like that Get-Member cmdlet supports Online parameter in V3 (similar to Get-Help in V2):

Get-Process | Get-Member -Online

That command would open the .NET Framework page in MSDN (http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx).

dir | Get-Member -Online

That command would open the .NET Framework pages in MSDN (http://msdn.microsoft.com/en-us/library/system.io.fileinfo.aspx and http://msdn.microsoft.com/en-us/library/system.io.directoryinfo.aspx).

Product Studio item created by Connect Synchronizer due to creation of feedback ID 584518 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=584518).

Repro Steps:
Expected Results:

Internal BugId: 2649

Votes from Connect: 15

Original Date Submitted: 7/21/2010 11:36:19 AM

Description:
Contact Information
Handle: bigjimslade80465
Site Name: PowerShell
Feedback ID: 576911

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
Currently, I need to do this:

if(! ($bar)) { & foo}

I would like to be able to do this:

unless($bar) { & foo}

Product Studio item created by Connect Synchronizer due to creation of feedback ID 576911 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=576911).

Repro Steps:
Currently, I need to do this:

if(! ($bar)) { & foo}

I would like to be able to do this:

unless($bar) { & foo}

Expected Results:

Internal BugId: 2618

Votes from Connect: 15

Original Date Submitted: 5/29/2010 12:09:48 AM

Description:
Contact Information
Handle: Clint B.
Site Name: PowerShell
Feedback ID: 563695

Frequency: Always Happens
Regression: I don't know if this issue existed previously

Problem Description:
The -ArgumentList parameter is described as passing arguments 'for the script that is specified by the FilePath parameter', which is true. But it also specifies the arguments to a scriptblock specified by the ScriptBlock parameter.

Additionally the help says that "Because all of the values that follow the ArgumentList parameter name are interpreted as being values of ArgumentList, the ArgumentList parameter should be the last parameter in the command.", which doesn't appear to be true at all. For example:

PS $ start-job -ArgumentList "one","two" -ScriptBlock { write-host $args }
PS $ receive-job 2
one two

PS $ start-job -ArgumentList "one","two" -FilePath C:\temp\Test.ps1
PS $ receive-job 4
one two

Product Studio item created by Connect Synchronizer due to creation of feedback ID 563695 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=563695).

Repro Steps:
PS $ gh start-job -parameter argumentlist

-ArgumentList <Object[]>

Specifies the arguments (parameter values) for the script that is specified by the FilePath parameter. 


Because all of the values that follow the ArgumentList parameter name are interpreted as being values of ArgumentList, the ArgumentList parameter should be the last parameter in the command.

Required?                    false

Position?                    named

Default value                

Accept pipeline input?       false

Accept wildcard characters?  false

Expected Results:

Internal BugId: 2556

Votes from Connect: 10

Original Date Submitted: 5/22/2010 3:29:42 AM

Description:
Contact Information
Handle: x0n
Site Name: PowerShell
Feedback ID: 560761

Frequency: Always Happens
Regression: I don't know if this issue existed previously

Problem Description:
Calling test-path " " returns $true. I would expect $false unless a file named " " really did exist.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 560761 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=560761).

Repro Steps:
given there is no file or folder named " " in the root of C:\

ps c:&gt; test-path " "
True

Expected Results:
ps> test-path " "
False

Internal BugId: 2549