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:> test-path " "
True

Expected Results:
ps> test-path " "
False

Internal BugId: 2549

Votes from Connect: 12

Original Date Submitted: 4/30/2010 9:13:05 PM

Description:
Contact Information
Handle: Roman Kuzmin
Site Name: PowerShell
Feedback ID: 556004

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

Problem Description:
The more detailed question and investigation is in here:
http://stackoverflow.com/questions/2744047/mysterious-different-conversion-to-string-of-seemingly-same-input-data

Items returned by (Get-ChildItem <path>) and (Get-ChildItem <path> -Include *) are converted to strings differently. Different results of the two commands below, IMHO, do not make any practical sense and only lead to confusion and bugs:

This command gets just file names

string[]

This command gets full file paths

string[]

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

Repro Steps:
(see the description)
Output:
File1.txt
File2.txt
C:\TEMP\Test\File1.txt
C:\TEMP\Test\File2.txt

Expected Results:
Output:
C:\TEMP\Test\File1.txt
C:\TEMP\Test\File2.txt
C:\TEMP\Test\File1.txt
C:\TEMP\Test\File2.txt

Internal BugId: 2530

Votes from Connect: 15

Original Date Submitted: 3/31/2010 2:02:45 PM

Description:
Contact Information
Handle: Martin Zugec
Site Name: PowerShell
Feedback ID: 546066

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

Problem Description:
Please re-consider default behavior of Import-Module. Current issue is that if you want to use namespaces (module\verb-noun), you still need to pay attention to name of your functions, because last one always wins.

This forces us to use SCCM\Get-SccmObject always simply because of the fact that we never know which function we will overwrite. SCCM\Get-Object would overwrite Get-Object in this case. This makes modules less useful.

Default behavior should be that current functions are not overwriten - if there is conflict, new functions should be available by Namespace only.

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

Repro Steps:
1.) Create module SCCM.psm1
2.) Create function Get-Object and export it from module
3.) You can access this function using SCCM\Get-Object (perfect), however it will overwrite built-in Get-Object

Expected Results:
I would expect that new functions won't overwrite existing ones. From design perspective, modules can be easily used as dynamic libraries of functions - but if they are not loaded all at once, it can be extremely dangerous, because you never know what you will overwrite.

Internal BugId: 2493

Votes from Connect: 17

Original Date Submitted: 12/9/2009 12:06:32 AM

Description:
Contact Information
Handle: Xaegr
Site Name: PowerShell
Feedback ID: 518895

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

Problem Description:
When you need to send a array of objects to switch statement, you cannot just pipe it:
PS > Get-EventLog security -newest 100 | Switch ($.EventId) {672 {$Id672++} 680 {$Id680++} }
or
Get-EventLog security -newest 100 | Select -expandProperty eventid | Switch {672 {$Id672++} 680 {$Id_680++}}

You need to specify full expression as "argument" for a switch, like this:
Switch (Get-EventLog security -newest 100 | select -expandproperty eventid) {672 {$Id672++} 680 {$Id680++} }

It works, but the first variant is much more powershell like. People are expecting this to work. It also will make using switch in ad-hoc pipelines much easier.

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

Repro Steps:
Get-EventLog security -newest 100 | Switch ($.EventId) {672 {$Id672++} 680 {$Id_680++} }

Expected Results:

Internal BugId: 2294

Votes from Connect: 12

Original Date Submitted: 10/31/2009 4:57:26 AM

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

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

Problem Description:
I see that trying to import a module where the module does not exist yields a non-terminating error. I think that really should be a full-blown terminating error; a failure to load a dependency like that really should stop the script. Having to use get-module -list available, or bump $erroractionpreference up to "stop" just to let try/catch work seems like a bit of a hack.

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

Repro Steps:
ps> try { import-module foo } catch { "caught" }
The specified module 'foo' was not loaded because no valid module file was found in any module directory.

+ CategoryInfo          : ResourceUnavailable: (foo:String) [Import-Module], FileNotFoundException

+ FullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Commands.ImportModuleCommand

Expected Results:
ps> try { import-module nonexistant } catch { "caught" }
caught

Internal BugId: 2242

Votes from Connect: 13

Original Date Submitted: 12/27/2008 11:39:54 PM

Description:

Contact Information
Handle: tfl
Site Name: PowerShell
Feedback ID: 389767

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

Problem Description:
I think the new auto-help stuff is fantastic. But it's a tad buggy and inconsistent.

To demonstrate this, I've created a simle advanced function file (get-autohelp.ps1) attached. You will need to save this file then run get-help against it to see the errors I note.

Here are the issues:

1. You can not specify a .NAME section in auto-help. If you do, then the output returned by get-help is heaviliy truncated. You should enable the developer to specify a name section, with Get-Help then supplementing this with the file name that the script lived in.




2. Two sections change name from script file to output by Get-Help. The ".DESCRIPTIION" section becomes "Detailed Description" in get-help output. And .LINK befomes "RELATED LINKS. This is inconsistent. Either make Get-Help produce the section names in the file, or change what sections you can specify in the file to match what get-help produces.




3. .LINK links are shown in basic get-help output, and with -FULL, but not -Detailed. This is inconsistent - anything shown in basic output should be shown with -full or -detailed.




4. It's not clear how to use .COMPONENT, .ROLE and .FUNCTIONALITY sections. These do not appear to be output in any use of get-help. If nothing else, there needs to be more details on these sections.

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

Repro Steps:
1. Take Get-AutoHelp.ps1 from bug report and save it.
2. To see issue 1, add a section:
.NAME

FOO

before line 2 in attached script. Run Get-Help, Get-Help -full, Get-Help -Detailed against the script, then do it again with these lines removed.

1. Run Get-Help, Get-Help -full, Get-Help-Detailed to see the first three issues.




2. Run get-help -role *, get-help-component * to see issue

Expected Results:
1. Ability to specify a name
2. Consistency of section names to get-help output
3. Ability to use .COMPONENT, .ROLE, and .FUNCTIONALITY sections

Internal BugId: 1838

Votes from Connect: 14

Original Date Submitted: 7/23/2008 3:57:45 AM

Description:

Contact Information
Handle: Dmitry Sotnikov
Site Name: PowerShell
Feedback ID: 357352

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

Problem Description:
Some cmdlets accept scriptblocks for some parameters, while others don't. This is very inconsistent and confusing.

On the one hand you can use this syntax for these examples: http://blogs.msdn.com/powershell/archive/2008/04/21/mindwarpingpower-cmdlets-scriptblock-parameters.aspx

On the other, something like this would fail for no apparent reason:
Get-DistributionGroup | Set-DistributionGroup -DisplayName {$_.name}

This is actually (IMHO) a design flaw of PowerShell (unfortunately still present in v2 ) – you (if you are develkopping cmdlets) cannot just have scriptblock support for your parameters. To have your parameters accept scriptblocks you either need to declare their type as ScriptBlock (not an option for your example of setting TsProfilePath which is a string) or make it accept value from pipeline (and face the side effects).

A very bad decision someone made at some point, and – as your email demonstrates – leading to a confusing and inconsistent behavior of some cmdlets accepting scriptblocks for some parameters, while others do not.

This should be changed so that there is consistent experience across all cmdlets from all Microsoft teams and 3rd-parties.

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

Repro Steps:
Expected Results:

Internal BugId: 1696

... in a folder at C:\config containing text files (and perhaps a similar folder in the user's home directory). Changing those text files would directly apply changes to Windows settings. Services could read those files directly or use a Windows text-based configuration management API.

Text-oriented configuration has many advantages: it makes devops-style workflows much more simple, entire server configurations could be versioned in git or svn along with the apps they host, spinning up new servers would be much simpler, and tools like Chef and Puppet would integrate far more smoothly and simply with Windows.

I suggest this as a parallel to the Command Prompt team's plans to support alternate shells. PowerShell is primarily API-oriented, whereas standard *nix shells (and accompanying scripting languages/tools, like Perl, awk, sed, etc.) are text-oriented. Imagine a Perl script that could install and configure Apache on both Windows and Linux, or a Ruby script that could alter a power user's monitor configuration without hitting any Windows APIs!

Thanks!

(x-post here: https://wpdev.uservoice.com/forums/266908-command-prompt/suggestions/8222103-support-text-oriented-windows-configuration-manage)