Votes from Connect: 6

Original Date Submitted: 3/14/2015 4:56:44 AM

Description:
Contact Information
Handle: J. Michael Delaney
Site Name: PowerShell
Feedback ID: 1179419

Problem Description:
Love PowerShell. It helps me so much in my daily tasks and I am constantly wowing co-workers with my skills.

When scripting, the only thing I don't like about PowerShell is that when doing conditional statements with if/elseif/else and looping constructs, that I need to use brace brackets when the conditional or loop executes one line of code.

For example, in other languages such as C++, I can do this:

If(x=10)
std::cout << "hello world!"
Else
std::cout << "goodbye!"

In PowerShell, I would need do this:

If($x -eq 10)
{
Write-host "hello world!"
}
Else
{
Write-host "goodbye!"
}

To me, seems unnecessary to have that since other languages that were the influence behind PowerShell have that functionality and yet PowerShell does not.

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

Repro Steps:

Internal BugId: 14311

Votes from Connect: 8

Original Date Submitted: 3/3/2015 5:52:55 AM

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

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

Problem Description:
Currently, there is no way to detect whether a command parameter has a default value or what the default value is. It's important to help authoring and to command parsing.

I can use the AST to get the default value, but that works only for functions and scripts; not for cmdlets.

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

Repro Steps:
(gcm <command>).ParameterSets.Parameters | gm

Expected Results:
TypeName: System.Management.Automation.CommandParameterInfo

Name MemberType Definition

Equals Method bool Equals(System.Object obj)
GetHashCode Method int GetHashCode()
GetType Method type GetType()
ToString Method string ToString()
Aliases Property System.Collections.ObjectModel.ReadOnlyCollection[string] Aliases {get;}
Attributes Property System.Collections.ObjectModel.ReadOnlyCollection[System.Attribute] Attributes {get;}
DefaultValue Property string DefaultValue {get;}
HelpMessage Property string HelpMessage {get;}
IsDynamic Property bool IsDynamic {get;}
IsMandatory Property bool IsMandatory {get;}
Name Property string Name {get;}
ParameterType Property type ParameterType {get;}
Position Property int Position {get;}
ValueFromPipeline Property bool ValueFromPipeline {get;}
ValueFromPipelineByPropertyName Property bool ValueFromPipelineByPropertyName {get;}
ValueFromRemainingArguments Property bool ValueFromRemainingArguments {get;}

Internal BugId: 14277

Votes from Connect: 5

Original Date Submitted: 3/2/2015 8:58:03 PM

Description:
Contact Information
Handle: Trond Hindenes
Site Name: PowerShell
Feedback ID: 1156994

Frequency: Always Happens
Regression: I do not know if this issue existed previously

Problem Description:
If a workflow uses deep nesting (at least 3 levels of nesting), erroraction does not work. This is reproducable in both the V4 and V5 feb preview of the WMF.

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

Repro Steps:
Consider the following 3 workflows
workflow one
{

Write-Output "one"

}

workflow two
{

one

}

workflow three
{

two -ErrorAction Stop

}

this code does not compile. If removing the "ErrorAction" parameter in workflow three, it works.

Expected Results:
workflow should compile.

Internal BugId: 14275

Votes from Connect: 3

Original Date Submitted: 1/3/2015 6:07:28 AM

Description:
Contact Information
Handle: The Deeds
Site Name: PowerShell
Feedback ID: 1074131

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

Problem Description:
Part 1:

In bash, we say:

rm -f

In Powershell, the equivalent is:

rm -Force

Please add an alias -f, so to make it compatible with unix-like shells. It helps a lot in C/C++ CMAKE and other scripting scenarios like Nodejs etc.

Part 2:

We desperately need mkdir -p (or --parents) switch of Unix in Windows. Going by the man (manual); http://www.computerhope.com/unix/umkdir.htm, it says:

"Create parent directories as necessary. When this option is used, no error is reported if a specified DIRECTORY already exists."

The emphasis on "no error is reported". This is EXTREMEMLY important in C/C++ make recipes.

Hope it will buzz into the ears at Redmond and will arrive in posh vNext.

Thanks in anticipation!

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

Repro Steps:
mkdir /temp; rm -rf /temp

-f is not a switch, instead use rm -r /temp -Force! Which is yuck!

mkdir -p /temp/and/then/some/non/existent/path

-p is unrecognized.

Expected Results:
Introduce -f switch to rm and -p to mkdir in vNext of powershell.

Internal BugId: 13174

Votes from Connect: 3

Original Date Submitted: 1/3/2015 3:54:37 AM

Description:
Contact Information
Handle: rpseekell
Site Name: PowerShell
Feedback ID: 1074018

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

Problem Description:
I use this script to connect to Office 365 via PowerShell, which I think is pretty standard:
$cred = Get-Credential
$sess = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred -Authentication basic -AllowRedirection
Import-PSSession -Session $sess

However, since updating to the November preview of PowerShell (WMF) 5, the new-PSSession command hangs and never finishes. I get a message like,
WARNING: Your connection has been redirected to the following URI: "https://podXXXXXXXX.outlook.com/powershell-liveid?PSVersion=5.0.9883.0 "
and minutes later, nothing else has happened.
Uninstalling the November update and going back to the May update or PS/WMF4 will cause it to work again.

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

Repro Steps:
$cred = Get-Credential
$sess = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred -Authentication basic -AllowRedirection
Import-PSSession -Session $sess

Expected Results:
Commands above finish and return a PSModuleInfo object like this:
ModuleType Version Name ExportedCommands

Script 1.0 tmp_na0ljv0x.dmw {Add-DistributionGroupMember, Add-MailboxFolderPermi

And then I can run commands against Office 365.

Internal BugId: 13171

Votes from Connect: 3

Original Date Submitted: 1/2/2015 7:28:29 AM

Description:
Contact Information
Handle: Roland Illig 2
Site Name: PowerShell
Feedback ID: 1073011

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

Problem Description:
The German version of the installer for Microsoft Security Essentials has two wrong translations:

1. „Falls keine Firewall aktiviert ist, aktivieren Sie die Windows-Firewall (empfohlen).“

This text should not even be in the installer in this form. Either the firewall is already activated, then the checkbox is useless and must not be shown at all. Or the firewall is not already activated, then the ”If no firewall is activated“ is redundant and should therefore be removed. Don’t confuse the user with unnecessary decisions.

1. „Aktivieren Sie die automatische Beispielübermittlung.”

This must be in a passive voice. “Automatische Beispielübermittlung aktivieren.”
Additionally, the word ”Beispiel” is not understandable for an average user. There is a long explanatory text above, but that doesn’t even mention the word “Beispiel“.

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

Repro Steps:
Expected Results:

Internal BugId: 13169

Votes from Connect: 3

Original Date Submitted: 12/11/2014 7:11:16 AM

Description:
Contact Information
Handle: Clint Stotesbery
Site Name: PowerShell
Feedback ID: 1051712

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

Problem Description:
I've run into a rare case. I can't use New-Object on a class whose GetEnumerator method throws NotSupportedException. System.Security.Cryptography.Xml.SignedInfo's GetEnumerator method throws a NotSupportedException: http://msdn.microsoft.com/en-us/library/system.security.cryptography.xml.signedinfo.getenumerator(v=vs.110).aspx

The stack trace shows TypicalEnumerable as this method catches Exception and then rethrows it as an ExtendedTypeSystemException. I followed the complete stacktrace (hint: there are delegates involved not in the stack trace) and I can't figure out a way to prevent this case from happening.

One workaround is to sub class SignedInfo and implement GetEnumerator so it doesn't throw an exception. Then use Add-Type and use the sub class. This works with New-Object so it doesn't throw an exception. The problem is that when I try to return my sub class from inside a function, the return keyword and Write-Output end up "losing" the object which results in it returning null to the calling function.

This may be a bug in SignedInfo (why implement IEnumerable and then have GetEnumerator throw a NotSupportedException??!!!) but New-Object shouldn't be calling GetEnumerator... it should only be calling the type's constructor.

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

Repro Steps:
PS C:&gt;Add-Type -AssemblyName System.Security
PS C:&gt; New-Object System.Security.Cryptography.Xml.SignedInfo
New-Object : The following exception occurred while trying to enumerate the collection: "Specified method is not
supported.".
At line:1 char:1
+ New-Object System.Security.Cryptography.Xml.SignedInfo
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : NotSpecified: (:) [New-Object], ExtendedTypeSystemException

+ FullyQualifiedErrorId : ExceptionInGetEnumerator,Microsoft.PowerShell.Commands.NewObjectCommand

PS C:&gt; try { New-Object System.Security.Cryptography.Xml.SignedInfo } catch [Exception] { Write-Host $_.Exception | Format-List -Force }
System.Management.Automation.ExtendedTypeSystemException: The following exception occurred while trying to enumerate the
collection: "Specified method is not supported.". ---> System.NotSupportedException: Specified method is not supported.

at System.Security.Cryptography.Xml.SignedInfo.GetEnumerator()
at System.Management.Automation.LanguagePrimitives.TypicalEnumerable(Object obj)

Expected Results:
I should be able to run New-Object on a type without its GetEnumerator method being invoked. That seems like strange behavior.

Internal BugId: 13142

Votes from Connect: 3

Original Date Submitted: 12/4/2014 3:29:25 AM

Description:

Contact Information
Handle: Josef Nemec
Site Name: PowerShell
Feedback ID: 1045858

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

Problem Description:
When calling Add-Member over an object all ScriptProperty members are being invoked (script blocks from those properties are invoked). I found it during testing on PowerShell 5 preview (from Windows 10 preview build), but it also occurs in PS 4 (tested on Windows 8.1). It seems like it occurs only with System.Management.Automation.dll 6.3.9600.17400 and newer since it works for me on 8.1 machines with version 6.3.9600.17090.

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

Repro Steps:
Execute following commands:

$global:BaseObject = New-Object PSObject
$global:BaseObject | Add-Member ScriptProperty "Test" { Write-Host "testing message" }
$global:BaseObject | Add-Member NoteProperty "Test2" 2

"testing message" will be displayed after second Add-Member call, which indicates that property code was executed even when not called directly.

Expected Results:
ScriptProperty members shoudn't be executed during Add-Member call, but only when explicitly called, i.e. by running $BaseObject.Test in provided example.

Internal BugId: 13130

Votes from Connect: 5

Original Date Submitted: 10/29/2014 11:53:04 PM

Description:
Contact Information
Handle: Stephen Owen
Site Name: PowerShell
Feedback ID: 1014669

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

Problem Description:
Currently there is no easy method to determine which version of PowerShell a particular cmdlet will work within.

Take the example of New-PSDrive. This command was introduced in PowerShell version 2.0, but the current Version property displayed when I run 'Get-Command New-PSDrive | Format-List' displays the value of 3.1.

While this cmdlet was included in 3.0 and 4.0, it is misleading that the version of 3.1 is displayed, when the cmdlet will function perfectly within PowerShell version 2.0.

In a lively discussion on the matter today on Twitter with a number of PowerShell MVPs, we were unable to find a conclusive command or one-liner to run to obtain the base version of a cmdlet, or the version in which it was introduced.

While adding this data to all existing cmdlets would be quite a workload, I think this is valuable information which helps provide teachable moments and added information to the PowerShell Command Line Interface experience.

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

Repro Steps:
Get-Command New-PSDrive | Select Version

>Version

3.1.0.0

Expected Results:
Get-Command New-PSDrive | Select Version,IntroducedIn

>Version IntroducedIn

3.1.0.0 2.0

Internal BugId: 13074

Votes from Connect: 4

Original Date Submitted: 10/6/2014 9:54:44 PM

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

Frequency: Always Happens
Regression: I don

Problem Description:
When writing a simple example to debug a PowerShell Background Job, the Background Job does not have enough time to initialize, before the Debug-Job command is invoked. Examine the following example:

$ScriptBlock = {

$Foo = 1;

Wait-Debugger;

$Foo++;

};

$Job = Start-Job -ScriptBlock $ScriptBlock;
Debug-Job -Job $Job;

When I run the above code in the PowerShell ISE, I receive an error message from Debug-Job, stating:

"Debug-Job : The provided job and all child jobs were examined but no jobs were found that could be debugged. In order to debug a job or child job the job must support debugging and also be in a running state."

Solution

To solve for this, I would suggest adding optional parameters: -Wait and -Timeout. The purpose of these parameters would be to cause the Debug-Job command to "wait" (a specified amount of time) for the specified Background Job to be in a "Running" state, so that the debugger can be invoked. The -Timeout parameter would be the number of milliseconds that Debug-Job should wait for the Background Job to be in a valid (Running) state for debugging. I would suggest a default of 1000 milliseconds, just to provide enough time for the Background Job to initialize.

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

Repro Steps:
Expected Results:

Internal BugId: 11034

Votes from Connect: 28

Original Date Submitted: 9/29/2014 7:28:00 PM

Description:
Contact Information
Handle: Axel B. Andersen
Site Name: PowerShell
Feedback ID: 984532

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

Problem Description:
When running Powershell Logon or Logoff Scrips in GPO's the -NoProfile switch is not included in the command. This results in very long logon/logoff times, if users have filled their Powershell Profile with a lot of modules. It can take up to 10 minutes, if the profile needs user input to load.

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

Repro Steps:
Create a powershell profile with just this one line:
read-host "Please type something"

Create a logon script with this content:
start-transcript c:\temp\test.txt # Make sure the folder exists before running the script.
gps
stop-transcript

Create a GPO and configure the User Logon Powershell Script above.

Link the GPO to the OU where the testuser with the profile resides.

Log on with the test user.

Expected Results:
The logon process will wait for the Powershell Script to time out. It will halt at Read-Host, which can be seen in the c:\temp\test.txt file after logon.

Internal BugId: 11025

Votes from Connect: 4

Original Date Submitted: 9/15/2014 7:04:41 AM

Description:
Contact Information
Handle: Derp McDerp
Site Name: PowerShell
Feedback ID: 972024

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

Problem Description:
Specifically:

1. it should auto-complete the xml based on their doctypes


2. it should recognize the interior of <ScriptBlock>s as PowerShell scripts rather than as text blobs and format and auto-complete those correctly.


3. it should provide better outlining of the xml (e.g. if you put the caret on an end tag or start tag it should highlight the entire interior of that xml node)

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

Repro Steps:
Expected Results:

Internal BugId: 11001

Votes from Connect: 4

Original Date Submitted: 9/14/2014 4:22:48 PM

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

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

Problem Description:
When 'Get-ChildItem -Recurse -LiteralPath' is run against a directory whose name contains square brackets, no output is produced.

Take a directory with the following contents:

PS> cmd /c dir /s d:\tmp\dir[1]
Volume in drive D is DATA
Volume Serial Number is 0454-9DBF

Directory of d:\tmp\dir[1]

2014-09-14 09:23 <DIR> .
2014-09-14 09:23 <DIR> ..
2014-09-14 09:23 <DIR> subdir

           0 File(s)              0 bytes

Directory of d:\tmp\dir[1]\subdir

2014-09-14 09:23 <DIR> .
2014-09-14 09:23 <DIR> ..
2014-09-14 09:23 <DIR> ssdir

           0 File(s)              0 bytes

Directory of d:\tmp\dir[1]\subdir\ssdir

2014-09-14 09:23 <DIR> .
2014-09-14 09:23 <DIR> ..
2014-09-14 09:23 12 file.txt

           1 File(s)             12 bytes


 Total Files Listed:

           1 File(s)             12 bytes

           8 Dir(s)  463,074,471,936 bytes free

This doesn't produce any output:

PS> gci -Recurse -LiteralPath 'd:/tmp/dir[1]'

Whereas this works:

PS> gci -Recurse -Path 'd:/tmp/dir[1]'

Directory: D:\tmp\dir[1]

Mode LastWriteTime Length Name

d---- 2014-09-14 09:23 subdir

Directory: D:\tmp\dir[1]\subdir

Mode LastWriteTime Length Name

d---- 2014-09-14 09:23 ssdir

Directory: D:\tmp\dir[1]\subdir\ssdir

Mode LastWriteTime Length Name

-a--- 2014-09-14 09:23 12 file.txt

This is discussed a.o. at https://connect.microsoft.com/PowerShell/feedback/CreateFeedbackForm.aspx?FeedbackFormConfigurationID=434&FeedbackType=1

P.S. There might already be a bug filed for that same issue, but it's currently not possible to search for existing bugs on Connect (browsing is available, but there are more than 2,400 bugs opened...)

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

Repro Steps:
gci -Recurse -LiteralPath 'd:/tmp/dir[1]'

no output is produced

Expected Results:
The contents of the directory d:/tmp/dir[1] should be returned

Internal BugId: 11000

Votes from Connect: 6

Original Date Submitted: 9/11/2014 4:15:39 AM

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

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

Problem Description:
Help documentation is more time consuming than it needs to be. My biggest pain point with help is that I like to include links to all other commands with the same noun to aid in discoverability. Sure, there is Get-Command -Noun ..., but it is useful in help documentation to include links to those commands as well. This also helps modern help tools link to those commands more easily.

As I create a module, adding additional commands, I really dislike having to circle back to the comment-based help and add the new commands to the links. Ditto when renaming a command.

I would like to see help automatically include any commands that have the same noun in the links of related items in the command help. With that in place, command authors would only have to worry about including links to online help, or links to other commands that may not be as obviously related but that you would want end users to be able to discover via help. The rest (links to commands with the same noun) would just be magic. As a plus, anyone extending a set of commands with additional verbs could have their commands automatically linked as well, without having to set up the links themselves.

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

Repro Steps:
New-Module -Name Test -ScriptBlock {

<#

.SYNOPSIS

    Get something.

.DESCRIPTION

    The Get-Something command gets something.

#>

function Get-Something {

    [CmdletBinding()]

    param()

}


<#

.SYNOPSIS

    Set something.

.DESCRIPTION

    The Set-Something command gets something.

#>

function Set-Something {

    [CmdletBinding()]

    param()

}

} | Import-Module
Get-Help Get-Something
Get-Help Set-Something

Expected Results:
You should see Set-Something in the RELATED LINKS section of Get-Something help and Get-Something in the RELATED LINKS section of Set-Something help because they share the same noun.

Internal BugId: 9994

Votes from Connect: 5

Original Date Submitted: 9/8/2014 11:00:11 PM

Description:
Contact Information
Handle: Oisín Grehan
Site Name: PowerShell
Feedback ID: 966940

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

Problem Description:
As of v5, the call (&) operator cannot invoke .NET methods. With the implied deprecation of new-object in v5 by way of the "new(...)" synthetic static constructor method, this becomes a more obvious lack.

One thing new-object has that the new v5 static method "new" does not is splatting support. Syntactically, this seems to make most sense when combined with support for invoking .NET methods with the call (&) operator. Here is an example on how this might work:

PS> [string]::format

OverloadDefinitions

static string Format(string format, System.Object arg0)
...

PS> $arguments = @{format="Hello, {0}.", arg0="world"}
PS> & ([string]::format) @arguments
Hello, world.

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

Repro Steps:
see description

Expected Results:
see description

Internal BugId: 9990

Votes from Connect: 4

Original Date Submitted: 7/18/2014 5:22:57 AM

Description:
Contact Information
Handle: R Jason Morgan
Site Name: PowerShell
Feedback ID: 922914

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

Problem Description:
When you install the WMF 5 May preview on Windows 8.1 enterprise with update x64, KB2894868-x64, the nuget.exe file that gets placed at %winddir%\System32\config\systemprofile\AppData\Local\Microsoft\Windows\PowerShell\PowerShellGet\nuget.exe doesn't work. This issue is noticeable when you try and run the find and install *-Module cmdlets as SYSTEM. Specifically you notice it when trying to use them in DSC, like with cPSGet.

I've added a link to the PowerShell.org repository where you can find the resource. Additionally, you can just try executing that particular nuget.exe file. It looks like it's just a bad file.

https://github.com/PowerShellOrg/DSC

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

Repro Steps:
Try running the cPSGet resource, or using PowerShellGet when running as SYSTEM, or just try running the nuget.exe file @ %winddir%\System32\config\systemprofile\AppData\Local\Microsoft\Windows\PowerShell\PowerShellGet\nuget.exe

Expected Results:

Internal BugId: 8903

Votes from Connect: 4

Original Date Submitted: 7/16/2014 11:54:14 PM

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

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

Problem Description:
When I invoke:

PS> Get-Help .\foo.ps1

I get something like:

NAME

c:\users\sto\somedir\somesubdir\more\foo.ps1

SYNOPSIS

Some useful script

SYNTAX

c:\users\sto\somedir\somesubdir\more\foo.ps1 -logdir <String> -outputdir <String> [-debugmode]

[<CommonParameters>]


c:\users\sto\somedir\somesubdir\more\foo.ps1 -zipfile <String> -outputdir <String>  [-debugmode]

[<CommonParameters>]

There should be a means to remove the (most often useless) "c:\users\sto\somedir\somesubdir\more&quot; paths, for instance when using the help text in documentation, or sharing it over email, the reader most likely won't have the script stored at the same location!

This is discussed at length at http://social.technet.microsoft.com/Forums/scriptcenter/en-US/5a14e963-90ea-4ca1-9ab7-42c28515b427/how-can-i-avoid-path-when-referencing-script-name-in-help?forum=winserverpowershell

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

Repro Steps:
Invoke Get-Help with a scriptname as the argument.

Expected Results:
Only the scriptname (or the exact string passed to Get-Help) should be included in the resulting help text.

Internal BugId: 8900

Votes from Connect: 5

Original Date Submitted: 7/4/2014 10:53:07 PM

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

Frequency: Always Happens
Regression: I do not know if this issue existed previously

Problem Description:
The Set-Acl cmdlet overwrites the SACL (and appears to protect it) when called by an administrator (even when the security descriptor object contains no SACL information at all). This can cause a populated SACL to be completely cleared when a user is expecting just DACL modifications.

This happens in PSv4. I think I recall seeing it in versions 2 and 3, but I haven't confirmed it.

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

Repro Steps:
Run the following script (there is a point where you must stop and inspect the SACL before moving on):

Create a new folder:

$FolderPath = "c:\temp\SetAclTest"
if (Test-Path $FolderPath) {

throw "Delete '$FolderPath' to make sure we have a default security descriptor"

}
$Folder = New-Item c:\temp\SetAclTest -ItemType directory

Get security descriptor with SACL:

$SD = Get-Acl $FolderPath -Audit

Add an Audit ACE and save the SD:

$AuditAce = New-Object System.Security.AccessControl.FileSystemAuditRule (

"Everyone",

"FullControl",

"ContainerInherit, ObjectInherit",

"None",

"Failure"

)
$SD.AddAuditRule($AuditAce)

Save the change:

$SD | Set-Acl

At this point, you can use GUI to confirm SACL has at least one non-inherited ACE

Get security descriptor w/o SACL and save it back out (no changes made)

$SD = Get-Acl $FolderPath
$SD | Set-Acl

Now object's security descriptor has a blank DACL with inheritance disabled

Expected Results:
If the security descriptor object was obtained by a call to Get-Acl without the -Audit switch, I would expect Set-Acl to not mess with the SACL.

Internal BugId: 8874