Votes from Connect: 4

Original Date Submitted: 8/24/2015 10:15:01 PM

Description:
Contact Information
Handle: herzbube
Site Name: PowerShell
Feedback ID: 1707779

Frequency: PowerShell
Regression: 1. Create a folder C:[foo]
2. Add a file "bar" to the folder
3. Run the following commands in PowerShell:

$path = 'C:\[foo]'

get-childitem -literalpath $path -recurse

Problem Description:
Let's say I have this file:

C:\[foo]\bar

I then run these PowerShell commands:

$path = 'C:\[foo]'

get-childitem -literalpath $path

Everything works fine, get-childitem shows me the file bar, then returns immediately.

Now I add the -recurse option:

$path = 'C:\[foo]'

get-childitem -literalpath $path -recurse

get-childitem no longer displays the file bar. In addition, the cmdlet runs a long time and displays various "permission denied" error messages for folders underneath C:\Windows, apparently because it scans the entire C: drive.

The problem is tied to the fact that the folder [bar] has brackets in the name. If I rename the folder to bar, i.e. without brackets, the result with recursion works as expected.

Environment: Windows 8.1, PowerShell 4.0.

Additional notes:

• I verified that in PowerShell 2.0 (on a Windows 7 machine) get-childitem returns the same result with or without -recurse. It appears that the behaviour has changed either in version 3.0 or 4.0.


• This post on technet.microsoft.com seems to describe the same problem. The poster uses PowerShell 3.0, so it would seem that the behaviour changed between versions 2.0 and 3.0: https://social.technet.microsoft.com/Forums/windowsserver/en-US/0fa34fab-cb35-4369-baad-a320ca610e24/getchilditem-file-recurse-literalpath-ctest-1-does-not-return-any-information?forum=winserverpowershell
  


• The post above also has a workaround: Use -path instead of -literalpath, then escape the square bracket characters.

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

Repro Steps:
1. Create a folder C:[foo]
2. Add a file "bar" to the folder
3. Run the following commands in PowerShell:

$path = 'C:\[foo]'

get-childitem -literalpath $path -recurse

Expected Results:
get-childitem displays the file "bar" and returns immediately.

Internal BugId: 15754

Votes from Connect: 8

Original Date Submitted: 7/28/2015 10:16:32 AM

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

Frequency: PowerShell
Regression: Run this script:

function Get-DummyData() {

for ($i = 0; $i -lt 10000000; $i++) {

    "This is freaking huge!! I'm a ninja! More words, yay!" 

} 

}
Get-DummyData | Out-Null

BTW here's another example:

1..1000000 | foreach {if ($ % 100000 -eq 0) {[GC]::Collect(2,'Forced',$true); $}}

Problem Description:
It appears that for every pipeline object, bound to a pipeline parameter, a string like this is stuffed into a collection - where it waits to be written to the event log:

ParameterBinding(Out-Null): name = \”InputObject\”; value = \“This is freaking huge!! I'm a ninja! More words, yay! \”

Specifically I see these objects being held onto by a field in the internal PipelineProcessor class called eventLogBuffer. A couple of examples show that the eventLogBuffer holds onto all of this information until the pipeline is finished. In some examples, this can cause what appears to be a memory hoard and possibly OutOfMemory exceptions.

It would perhaps be better if PowerShell could monitor memory pressure during pipeline execution and periodically flush this data to the eventlog, allowing a subsequent GC to reclaim memory taken by that data.

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

Repro Steps:
Run this script:

function Get-DummyData() {

for ($i = 0; $i -lt 10000000; $i++) {

    "This is freaking huge!! I'm a ninja! More words, yay!" 

} 

}
Get-DummyData | Out-Null

BTW here's another example:

1..1000000 | foreach {if ($ % 100000 -eq 0) {[GC]::Collect(2,'Forced',$true); $}}

Expected Results:
Ideally, I'd expect the memory (PM) usage of the app to rise minimally above the baseline PM level considering we send one small string down the pipeline at a time. At the very least, the first script shouldn't need to top 2 GBs of PM to complete. I guess though you need to balance the perf issues of lots of GCs and potentially running of memory with the perf issue of writing to the event log.

Internal BugId: 15687

Votes from Connect: 3

Original Date Submitted: 7/10/2015 6:50:26 PM

Description:
Contact Information
Handle: Dimitar Milov
Site Name: PowerShell
Feedback ID: 1529031

Frequency: PowerShell
Regression:

Problem Description:
The issue seems to be OS specific and only reproduces on Windows 8/8.1 and Windows 10. When a .NET object instance is passed to a function as an argument the function calls the object's ToString method.

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

Repro Steps:
Expected Results:
$Source = @"
using System;

namespace Test
{

public class TestClass

{

private bool _ts;
public bool ToStringCalled {
get {

return _ts;

}
}

public override string ToString() {
_ts = true;
return "test";
}

}

}
"@

Add-Type -TypeDefinition $Source -Language CSharp

$obj = new-object "Test.TestClass"

function test($o) {}

test $obj

$obj.ToStringCalled

> True

Internal BugId: 15638

Votes from Connect: 5

Original Date Submitted: 7/7/2015 4:53:38 AM

Description:
Contact Information
Handle: June Blender
Site Name: PowerShell
Feedback ID: 1515009

Frequency: PowerShell
Regression: PS C:\ps-test> Get-Help Get-Command -Parameter PipelineVariable
Get-Help : No parameter matches criteria PipelineVariable.
At line:1 char:1
+ Get-Help Get-Command -Parameter PipelineVariable
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidArgument: (System.Manageme...CommandHelpInfo:ProviderCommandHelpInfo) [Get-Help], PSArgumen

tException

+ FullyQualifiedErrorId : NoParmsFound,Microsoft.PowerShell.Commands.GetHelpCommand

PS C:\ps-test> Get-Command Get-Command -ParameterName PipelineVariable

CommandType Name ModuleName

Cmdlet Get-Command Microsoft.PowerShell.Core

Problem Description:
Commands in this format:

Get-Help <commandName> -Parameter <any_common_parameter>

return a PSArgumentException error, even when the command has the common parameter.

Get-Help Parameter parameter code needs a branch that gets the description from or displays a link to about_CommonParameters. The error implies that the parameter isn't valid for the command, which is confusing, especially for beginning users.

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

Repro Steps:
PS C:\ps-test> Get-Help Get-Command -Parameter PipelineVariable
Get-Help : No parameter matches criteria PipelineVariable.
At line:1 char:1
+ Get-Help Get-Command -Parameter PipelineVariable
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidArgument: (System.Manageme...CommandHelpInfo:ProviderCommandHelpInfo) [Get-Help], PSArgumen

tException

+ FullyQualifiedErrorId : NoParmsFound,Microsoft.PowerShell.Commands.GetHelpCommand

PS C:\ps-test> Get-Command Get-Command -ParameterName PipelineVariable

CommandType Name ModuleName

Cmdlet Get-Command Microsoft.PowerShell.Core

Expected Results:
PS C:\ps-test> Get-Help Get-Command -Parameter PipelineVariable

-PipelineVariable <String>

    PipelineVariable stores the value of the current pipeline element

    as a variable, for any named command as it flows through the pipeline.


    Valid values are strings, the same as for any variable names.

    ...

Required? false
Position? named
Default value None
Accept pipeline input? True (ByPropertyName)
Accept wildcard characters? false

Internal BugId: 15626

Votes from Connect: 4

Original Date Submitted: 6/17/2015 8:18:36 AM

Description:
Contact Information
Handle: Tom Nolan [MSFT]
Site Name: PowerShell
Feedback ID: 1441324

Frequency: PowerShell
Regression: function Test-MyDebug
{

[cmdletbinding()]

param

(

    [parameter(ValueFromPipeline=$true)]

    $InputObject

)

process

{

    write-host "Value: $_" -ForegroundColor Green


    Write-Debug "Write-debug gets its own 'scope' for the last continue status of the debug preference"

    Write-Debug "If you select 'Yes To All' on after any of these statements"

    Write-Debug "It will have no effect, and you will continue to be prompted"

}

}

1,2,3 | Test-MyDebug -Debug

Problem Description:
When using the -Debug parameter with [cmdletbinding()] inside a script or function, this is known to set the $DebugPreference = "Inquire" for the scope of that script. When using Write-Debug within that script, you will be prompted as expected due to the inquire preference. However, if you select "Yes To All" on the prompt and have additional Write-Debug statements, they will still prompt you, even though you have specifically requested that it not prompt you.

I'm not sure if this behavior is truly by design or a side effect of the pipeline model and something that was overlooked when -Debug was implemented. Looking at decompiled code of System.Management.Automation.MshCommandRuntime, I can see that the "Yes To All" is actually being stored (internal ContinueStatus lastDebugContinueStatus) when the WriteDebug method calls the WriteHelper method.

However, due to the way the pipeline functions, Write-Debug is executing under a different context than the PSCmdlet script, and therefore the lastDebugContinueStatus is not updated when I select "Yes To All" after a Write-Debug statement.

This bug appears to be present in PowerShell 2.0 through the 5.0 pre-release

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

Repro Steps:
function Test-MyDebug
{

[cmdletbinding()]

param

(

    [parameter(ValueFromPipeline=$true)]

    $InputObject

)

process

{

    write-host "Value: $_" -ForegroundColor Green


    Write-Debug "Write-debug gets its own 'scope' for the last continue status of the debug preference"

    Write-Debug "If you select 'Yes To All' on after any of these statements"

    Write-Debug "It will have no effect, and you will continue to be prompted"

}

}

1,2,3 | Test-MyDebug -Debug

Expected Results:
I would expect the lastDebugContinueStatus inside the Write-Debug context to apply back to the PScmdlet that is executing the Write-Debug cmdlet so that clicking "Yes To All" after using Write-Debug, will update the $DebugPreference to "Continue" rather than staying "Inquire"

Internal BugId: 15576

Votes from Connect: 5

Original Date Submitted: 6/2/2015 10:28:19 PM

Description:
Contact Information
Handle: uniquedisplaynameformypublicprofile
Site Name: PowerShell
Feedback ID: 1392738

Frequency: PowerShell
Regression: Create the function:
function Foo {

param([Parameter(mandatory)][int]$Bar)

"OK - $Bar"

}

This works:
Foo -Bar 1KB
(prints: OK - 1024)
Foo -Bar 1L
(prints: OK - 1)

But this fails:
Foo
cmdlet Foo at command pipeline position 1
Supply values for the following parameters:
Bar: 1KB
(prints: Cannot recognize "1KB" as a System.Int32 due to a format error.)
Bar: 1D
(prints: Cannot recognize "1L" as a System.Int32 due to a format error.)

Problem Description:
PowerShell does not accepts all integer literals (as defined by Windows PowerShell Language Specification Version 3.0) when accepting parameters interactively. Specifically, it does not accept valid numeric multipliers, nor valid numeric type suffixes.

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

Repro Steps:
Create the function:
function Foo {

param([Parameter(mandatory)][int]$Bar)

"OK - $Bar"

}

This works:
Foo -Bar 1KB
(prints: OK - 1024)
Foo -Bar 1L
(prints: OK - 1)

But this fails:
Foo
cmdlet Foo at command pipeline position 1
Supply values for the following parameters:
Bar: 1KB
(prints: Cannot recognize "1KB" as a System.Int32 due to a format error.)
Bar: 1D
(prints: Cannot recognize "1L" as a System.Int32 due to a format error.)

Expected Results:
I can use the same valid PowerShell integer literals when specifying parameters either interactively or inline.

Internal BugId: 14538

Votes from Connect: 4

Original Date Submitted: 5/29/2015 3:12:46 AM

Description:
Contact Information
Handle: azhskr
Site Name: PowerShell
Feedback ID: 1377521

Frequency: PowerShell
Regression: Find-Module -Tag DSC | Install-Module -> Hangs with no errors
Find-Module -Name xActiveDirectory | Install-Module -> Works

Problem Description:
Find-Module -Tag DSC | Install-Module just hangs in the PowerShell Console. There is no error displayed and I have let it sit for 20 minutes before I finally had to close the console and reopen it. If I run the command Find-Module -Name xActiveDirectory | Install-Module it works as expected.

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

Repro Steps:
Find-Module -Tag DSC | Install-Module -> Hangs with no errors
Find-Module -Name xActiveDirectory | Install-Module -> Works

Expected Results:
Find-Module -Tag DSC | Install-Module should install all modules that are tagged with 'DSC'. It worked this way in previous Windows 10 Preview Builds.

Internal BugId: 14524

Votes from Connect: 3

Original Date Submitted: 5/27/2015 9:24:37 PM

Description:

Contact Information
Handle: _TimPringle
Site Name: PowerShell
Feedback ID: 1373413

Frequency: PowerShell

Regression: Reproduction Steps Example 1

1) Start PowerShell (either as normal or run as administrator)
2) Type Start-Job -VMName, and use tab to parse through other parameters. These are only the common parameters.

Reproduction Steps Example 2

1) Start PowerShell (either as normal or run as administrator)
2) Type get-command start-job -Syntax
3) The output should be similar to below, but the last four lines, which detail the use with the VM parameters, only indicate that the VMName/VMGUID can be used.

Start-Job [-ScriptBlock] <scriptblock> [[-InitializationScript] <scriptblock>] [-Name <string>] [-Credential <pscredential>] [-Authentication <AuthenticationMechanism>] [-RunAs32] [-PSVersion <version>] [-InputObject <psobject>] [-
ArgumentList <Object[]>] [<CommonParameters>]

Start-Job [-DefinitionName] <string> [[-DefinitionPath] <string>] [[-Type] <string>] [<CommonParameters>]

Start-Job [[-InitializationScript] <scriptblock>] -LiteralPath <string> [-Name <string>] [-Credential <pscredential>] [-Authentication <AuthenticationMechanism>] [-RunAs32] [-PSVersion <version>] [-InputObject <psobject>] [-Argumen
tList <Object[]>] [<CommonParameters>]

Start-Job [-FilePath] <string> [[-InitializationScript] <scriptblock>] [-Name <string>] [-Credential <pscredential>] [-Authentication <AuthenticationMechanism>] [-RunAs32] [-PSVersion <version>] [-InputObject <psobject>] [-Argument
List <Object[]>] [<CommonParameters>]

Start-Job [-VMGuid] <guid[]> [<CommonParameters>]

Start-Job [-VMGuid] <guid[]> [<CommonParameters>]

Start-Job -VMName <string[]> [<CommonParameters>]

Start-Job -VMName <string[]> [<CommonParameters>]

Problem Description:
The Start-Job cmdlet when used with either VMName or VMGUID does not work successfully. It only allows you to specify the VMname/VMGUID, but nothing (other than common parameters) after this. A check of the syntax confirms that this is the case.

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

Repro Steps:

Reproduction Steps Example 1

1) Start PowerShell (either as normal or run as administrator)
2) Type Start-Job -VMName, and use tab to parse through other parameters. These are only the common parameters.

Reproduction Steps Example 2

1) Start PowerShell (either as normal or run as administrator)
2) Type get-command start-job -Syntax
3) The output should be similar to below, but the last four lines, which detail the use with the VM parameters, only indicate that the VMName/VMGUID can be used.

Start-Job [-ScriptBlock] <scriptblock> [[-InitializationScript] <scriptblock>] [-Name <string>] [-Credential <pscredential>] [-Authentication <AuthenticationMechanism>] [-RunAs32] [-PSVersion <version>] [-InputObject <psobject>] [-
ArgumentList <Object[]>] [<CommonParameters>]

Start-Job [-DefinitionName] <string> [[-DefinitionPath] <string>] [[-Type] <string>] [<CommonParameters>]

Start-Job [[-InitializationScript] <scriptblock>] -LiteralPath <string> [-Name <string>] [-Credential <pscredential>] [-Authentication <AuthenticationMechanism>] [-RunAs32] [-PSVersion <version>] [-InputObject <psobject>] [-Argumen
tList <Object[]>] [<CommonParameters>]

Start-Job [-FilePath] <string> [[-InitializationScript] <scriptblock>] [-Name <string>] [-Credential <pscredential>] [-Authentication <AuthenticationMechanism>] [-RunAs32] [-PSVersion <version>] [-InputObject <psobject>] [-Argument
List <Object[]>] [<CommonParameters>]

Start-Job [-VMGuid] <guid[]> [<CommonParameters>]

Start-Job [-VMGuid] <guid[]> [<CommonParameters>]

Start-Job -VMName <string[]> [<CommonParameters>]

Start-Job -VMName <string[]> [<CommonParameters>]

Expected Results:
Would expect similar parameters as the other parameter sets, such as Credential, File, ScriptBlock.
At present the vm options for start-job cannot do anything.

Internal BugId: 14518

Votes from Connect: 66

Original Date Submitted: 5/27/2015 8:46:16 AM

Description:
Contact Information
Handle: Frank E Lesniak
Site Name: PowerShell
Feedback ID: 1371736

Frequency: PowerShell
Regression: 1. Visit: https://gist.github.com/anonymous/572f42ba0ea7eec4f721#file-psclassreproreduced11-ps1
2. Click the "Raw" button. Copy the code to the clipboard
3. Open Notepad and paste the code from the clipboard. Save the file somewhere with file name: animal.ps1
(don't forget to change the file type to "All Files")
4. Execute the script using PowerShell.

Problem Description:
I have a stock PowerShell template that I use as a starting point for many scripts; its code is used throughout my organization. After patching a number of systems, I discovered that this known-good code has stopped working. A script that would normally take a brief moment to execute now hangs / freezes the PowerShell window with high CPU utilization.

After doing extensive testing, I have determined that installing KB3000850 consistently causes this bug to appear in Windows 8.1 or Windows Server 2012 R2.

I have taken the time to reduce the thousands of lines of template code down to simple code to reproduce the problem. The code to reproduce is still ~50 lines, but cutting out any additional code seems to break the ability to reproduce the problem.

Repro code:
https://gist.github.com/anonymous/572f42ba0ea7eec4f721#file-psclassreproreduced11-ps1

Impact of this is high; our automation is essentially dead in the water.

FYI: this issue is also occurring on Windows 10. See privately submitted Connect bug with ID 1122637.

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

Repro Steps:
1. Visit: https://gist.github.com/anonymous/572f42ba0ea7eec4f721#file-psclassreproreduced11-ps1
2. Click the "Raw" button. Copy the code to the clipboard
3. Open Notepad and paste the code from the clipboard. Save the file somewhere with file name: animal.ps1
(don't forget to change the file type to "All Files")
4. Execute the script using PowerShell.

Expected Results:
The script should complete instantly with no output

Internal BugId: 14516

Votes from Connect: 4

Original Date Submitted: 5/21/2015 8:59:29 PM

Description:
Contact Information
Handle: Thomas Lee
Site Name: PowerShell
Feedback ID: 1353410

Problem Description:
-? is a great parameter for all cmdlets as it does a basic get-help. That's fine, but it would be nice to extend it as follows:

Switch What it does
-?F Equivalent of Get-Help -FULL
-?D Equivalent of Get-Help -Detailed
-?E Equivalent of Get-Help -Example
-?o Equivalent of Get-Help -Online

The idea is to make it simlpler to get help for a cmdlet/function.

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

Repro Steps:

Internal BugId: 14503

Votes from Connect: 9

Original Date Submitted: 5/20/2015 3:14:12 PM

Description:
Contact Information
Handle: Joachim Meyer
Site Name: PowerShell
Feedback ID: 1349420

Frequency: PowerShell
Regression:

Problem Description:
I guess that classifies more as a design flaw than a bug. Netstat.exe has the option -o that displays the owning Process ID for each connection. Get-NetTCPConnection should also add a property for the Process ID. Without the Process ID the Cmdlet is pretty useless (at least for me) and does not replace netstat.exe. (The underlying WMI class MSFT_NetTCPConnection does not include that property, too, so in this case additional code and a synthetic property probably needs to be added.)

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

Repro Steps:
Expected Results:

Internal BugId: 14496

Votes from Connect: 7

Original Date Submitted: 5/19/2015 2:43:00 AM

Description:
Contact Information
Handle: Trevor Sullivan [MVP]
Site Name: PowerShell
Feedback ID: 1345058

Frequency: PowerShell
Regression: class BaconStrip {

[string] $Length;

[string] $Width;


[ValidateSet('Cooked', 'Raw')]

[string] $Status;

[ValidateSet('Regular', 'Applewood', 'Smoked')]

[string] $Type;

BaconStrip([string] $Type) {

    $this.Type = $Type;

}

[void] Cook() {

    $this.Status = 'Cooked';

}

}

Create a new BaconStrip instance with an invalid type

$MyBaconStrip = [BaconStrip]::new('Regular2');

This variable should be $null if an exception is thrown in the constructor

$MyBaconStrip;

Problem Description:
In April 2015 Preview of WMF 5.0 (version: 5.0.10105.0), when you construct a PowerShell class, and attempt to instantiate it using the New() constructor method, if an exception is thrown, the object is returned in an inconsistent state.

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

Repro Steps:
class BaconStrip {

[string] $Length;

[string] $Width;


[ValidateSet('Cooked', 'Raw')]

[string] $Status;

[ValidateSet('Regular', 'Applewood', 'Smoked')]

[string] $Type;

BaconStrip([string] $Type) {

    $this.Type = $Type;

}

[void] Cook() {

    $this.Status = 'Cooked';

}

}

Create a new BaconStrip instance with an invalid type

$MyBaconStrip = [BaconStrip]::new('Regular2');

This variable should be $null if an exception is thrown in the constructor

$MyBaconStrip;

Expected Results:
If an exception is thrown in a PowerShell class constructor, the object should not be instantiated.

Internal BugId: 14483

Votes from Connect: 3

Original Date Submitted: 5/18/2015 2:02:46 AM

Description:
Contact Information
Handle: Sergey Teplyakov
Site Name: PowerShell
Feedback ID: 1341920

Frequency: PowerShell
Regression:

Problem Description:
PowerShell uses copy-on-write semantic for inner scopes.

This means that if you'll change outer variable in the inner scope then inner scope would deal with it's own copy. Here is an example:

$list = @(1, 2)

Function Foo
{
"Foo: initial value - $list"
$list = $list + 3
"Foo: $list: $list,$global:list: $global:list"

}
The output would be:

Foo: initial value - 1 2
Foo: $list: 1 2 3, $global:list: 1 2
Ok, this behavior is by design. But lets change Foo function a bit:

Function Foo
{
"Foo: initial value - $list"
$list += 3
"Foo: $list: $list,$global:list: $global:list"

}
The output would be:

Foo: initial value - 1 2
Foo: $list: 3, $global:list: 1 2

Hm... I can assume that x += y operator is not exactly the same that x = x + y. But that is not exacted. Let's change the code once more:

Function Foo
{
New-Variable -Name z -Value 42
"Foo: initial value - $list"
$list += 3
"Foo: $list: $list,$global:list: $global:list"

}

And now the output would be:

Foo: initial value - 1 2
Foo: $list: 1 2 3, $global:list: 1 2

It seems like a bug. The only question is where exactly? I assume behavior of += in second case is incorrect. But maybe I missing something...

Link to stackoverflow post: http://stackoverflow.com/questions/30290555/powershell-copy-on-write-behavior-depends-on-operator-type

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

Repro Steps:
Expected Results:

Internal BugId: 14479

Votes from Connect: 3

Original Date Submitted: 5/4/2015 1:20:27 AM

Description:
Contact Information
Handle: David I McIntosh
Site Name: PowerShell
Feedback ID: 1300430

Frequency: PowerShell
Regression: >function emptyArray() { @() }
>$lt = @() ; $lt.Count
0
>$lt1 = @(); $lt1 -eq $null; $lt1.count; $lt1.gettype()
0
IsPublic IsSerial Name BaseType

True True Object[] System.Array

>$lt += $lt1; $lt.Count
0
>$lt += emptyArray; $lt.Count
0
>$lt2 = emptyArray; $lt2 -eq $null; $lt2.Count; $lt2.gettype()
True
0
You cannot call a method on a null-valued expression.
At line:1 char:38
+ $lt2 = emptyArray; $lt2 -eq $null; $lt2.Count; $lt2.gettype()
+ ~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
>$lt += $lt2; $lt.Count
0
>$lt3 = $null; $lt3 -eq $null;$lt3.gettype()
True
You cannot call a method on a null-valued expression.
At line:1 char:32
+ $lt3 = $null; $lt3 -eq $null;$lt3.gettype()
+ ~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
>$lt += $lt3; $lt.count
1
>function addToArray($la, $lb) { $la += $lb; $la.count }
>$lt = @(); $lt.Count
0
>addToArray $lt $lt1
0
>addToArray $lt $lt2
1

SerializationVersion 1.1.0.1

BuildVersion 6.2.9200.16481

PSVersion 3.0

Problem Description:
When a function returns an empty array (in the pipe) and this is assigned to a variable, it is changed into something that is not quite $null and not quite an empty array. If this variable is subsequently passed in as a parameter to a function, it is further changed into what seems to be truly a $null

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

Repro Steps:
>function emptyArray() { @() }
>$lt = @() ; $lt.Count
0
>$lt1 = @(); $lt1 -eq $null; $lt1.count; $lt1.gettype()
0
IsPublic IsSerial Name BaseType

True True Object[] System.Array

>$lt += $lt1; $lt.Count
0
>$lt += emptyArray; $lt.Count
0
>$lt2 = emptyArray; $lt2 -eq $null; $lt2.Count; $lt2.gettype()
True
0
You cannot call a method on a null-valued expression.
At line:1 char:38
+ $lt2 = emptyArray; $lt2 -eq $null; $lt2.Count; $lt2.gettype()
+ ~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
>$lt += $lt2; $lt.Count
0
>$lt3 = $null; $lt3 -eq $null;$lt3.gettype()
True
You cannot call a method on a null-valued expression.
At line:1 char:32
+ $lt3 = $null; $lt3 -eq $null;$lt3.gettype()
+ ~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
>$lt += $lt3; $lt.count
1
>function addToArray($la, $lb) { $la += $lb; $la.count }
>$lt = @(); $lt.Count
0
>addToArray $lt $lt1
0
>addToArray $lt $lt2
1

SerializationVersion 1.1.0.1

BuildVersion 6.2.9200.16481

PSVersion 3.0

Expected Results:
$l_t2 should behave as null or @(), not somewhere inbetween!

Internal BugId: 14438

Votes from Connect: 3

Original Date Submitted: 4/30/2015 2:06:48 PM

Description:
Contact Information
Handle: Holger Froebe
Site Name: PowerShell
Feedback ID: 1290413

Frequency: PowerShell
Regression: Windows 7 SP1 X64 - German
Following release notes:
Checked for all the updates - OK
Powershell 4.0 was installed - OK
Selecting package from MS Download Center:
Windows6.1-KB2908075-x64
Starting the Update-Package gives me the above error.

Maybe a Problem with UI Culture - I work with a german Windows and maybe the Preview is
only applicable to english Windows ?

Problem Description:
Installing Powershell 5.0 on Windows 7 gives me error:
This update is not applicable to your Computer.

Followed release notes:
Checked for all the updates - OK
Powershell 4.0 was installed - OK

Selected the right package from download Center:
Windows6.1-KB2908075-x64

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

Repro Steps:
Windows 7 SP1 X64 - German
Following release notes:
Checked for all the updates - OK
Powershell 4.0 was installed - OK
Selecting package from MS Download Center:
Windows6.1-KB2908075-x64
Starting the Update-Package gives me the above error.

Maybe a Problem with UI Culture - I work with a german Windows and maybe the Preview is
only applicable to english Windows ?

Expected Results:

Internal BugId: 14422

Votes from Connect: 4

Original Date Submitted: 4/14/2015 8:18:28 AM

Description:
Contact Information
Handle: JasonHorner
Site Name: PowerShell
Feedback ID: 1246396

Problem Description:
often we need to parse a file and not rely on its extension, while magic number parsing is imperfect it can provide some value.
this could be used for general file parsing as well as some security scenarios

Here is a script that implements this feature though I don't think it is completely robust:
http://powershell.com/cs/blogs/tips/archive/2010/08/09/reading-file-quot-magic-number-quot.aspx

unix support a similar capability via the file utility:
http://en.wikipedia.org/wiki/File_%28command%29

More info on magic number parsing:
http://en.wikipedia.org/wiki/Listoffile_signatures

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

Repro Steps:

Internal BugId: 14377

Votes from Connect: 3

Original Date Submitted: 2/19/2015 11:08:09 PM

Description:

Contact Information
Handle: Rohn Edwards
Site Name: PowerShell
Feedback ID: 1138469

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

Problem Description:
In the December 2014 and February 2015 WMF 5.0 previews, flags enumerations that have byte, sbyte, short, or ushort underlying types have to be cast or coerced to a numeric type before -band, -bor, or -bxor bitwise operations will work.

int, uint, long, and ulong underlying types still work as expected.

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

Repro Steps:
First, ensure $PSVersionTable.PSVersion is 5.0.10018.0

To see the error, run this command:
PS> [System.Windows.Input.KeyStates]::Down -band [System.Windows.Input.KeyStates]::Down

KeyStates has an underlying type of 'Byte'. The command works if you modify it like this:
PS> [System.Windows.Input.KeyStates]::Down.value__ -band [System.Windows.Input.KeyStates]::Down

Expected Results:
No errors are expected, like running this command:
It appears that version 5 returns an instance of the enumeration instead of a numeric value (which it looks like previous versions return).

Internal BugId: 13250

Votes from Connect: 5

Original Date Submitted: 2/6/2015 3:54:49 PM

Description:
Contact Information
Handle: edi89
Site Name: PowerShell
Feedback ID: 1117495

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

Problem Description:
Using paramter validation in functions works just find - something like this:
function test{

Param (

    [ValidateRange(3,8)]

    [Int] $mytest )


write-host $mytest

}
test 4
test 9
The problem is, that it seems, that parameter validation is in fact just a special case of variable validation which leads to the circumstance, that the variable used (in this case $mytest) is beeing validated every time you use it. Try this:
function test{

Param    (

    [ValidateRange(3,8)]

    [Int] $mytest)


$mytest = $mytest+5

write-host $mytest

}

test 4

It seems to be by design, but the documentation about parameter validation is misleading if not completly wrong, because it says something like:"parameters are validated when you call the function/cmdlet", which simply is not the way it works - the variable is validated everytime you use it.

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

Repro Steps:
function test{

Param    (

    [ValidateRange(3,8)]

    [Int] $mytest)


$mytest = $mytest+5

write-host $mytest

}

test 4

Expected Results:
test 4
The variable cannot be validated because the value 9 is not a valid value for the mytest variable.
At line:6 char:5
+ $mytest = $mytest+5
+ ~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : MetadataError: (:) [], ValidationMetadataException

+ FullyQualifiedErrorId : ValidateSetFailure

4

Internal BugId: 13225