Powershell 2.0 / 4.0 question

This topic contains 10 replies, has 6 voices, and was last updated by Profile photo of Missy Januszko Missy Januszko 2 months ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #48429
    Profile photo of Missy Januszko
    Missy Januszko
    Participant

    The following line of code works in Powershell 2. It does not work in Powershell 4.

    foreach ($acc.DisplayName in $AccountInfo) {$newAccList = $acc.DisplayName + ',' + $NewAccList}
    

    It was changed to this for Powershell 4:

    foreach ($acc in $AccountInfo) {$newAccList = $acc.DisplayName + ',' + $newAccList}
    

    The discussion surrounding this line of code is regarding forward-compatibility statements that Powershell 2 is forward-compatible with Powershell 4.

    Any thoughts? Thanks in advance!
    -Missy

    #48433
    Profile photo of Craig Duff
    Craig Duff
    Participant

    Specifying the property name you want in the foreach assignment is pointless. I'm surprised powershell 2 allowed it, but my testing confirms that it does. Nevertheless it isn't necessary and doesn't seem to do anything. Take:

    powershell -v 2
    $items = Get-ChildItem
    ForEach($item.Name in $items) { $item.Length }

    The powershell version 4 code you posted will work just as well in version 2.

    • This reply was modified 2 months ago by Profile photo of Craig Duff Craig Duff.
    • This reply was modified 2 months ago by Profile photo of Craig Duff Craig Duff.
    #48436
    Profile photo of Dan Potter
    Dan Potter
    Participant

    delete

    • This reply was modified 2 months ago by Profile photo of Dan Potter Dan Potter.
    #48440
    Profile photo of Missy Januszko
    Missy Januszko
    Participant

    The disclaimer is this is not my code – I was surprised that this did work in 2.0, but testing showed it actually did work. My question is really "why did this work in 2.0?" and "what was tightened or changed in 4.0 that made it stop working?"

    #48443
    Profile photo of Dan Potter
    Dan Potter
    Participant

    That's a strange script, maybe there is more to it?

    $accountinfo.displayname -join ', '

    #48448
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    Could be that Microsoft didn't even realize this "worked" in v2. PowerShell v3 was a pretty major rewrite of the engine (adding the new AST, changing from the CLR to the DLR, etc), so the behavior may have changed without anyone really intending or noticing it.

    #48451
    Profile photo of Missy Januszko
    Missy Januszko
    Participant

    Yes, there's more to it. It was sent to me to investigate the "forward compatibility issue" so I limited it to just the one line that caused a problem. Merely trying answer the compatibility question to keep to the question posed to me and not perform a code review.

    #48453
    Profile photo of Dan Potter
    Dan Potter
    Participant

    I'm going with never noticed because only one person in the powershell arena would write it like that:D Join was available in 2.0

    #48455
    Profile photo of Rob Simmers
    Rob Simmers
    Participant

    It may have to do with features introduced in V3 with implicit foreach. In version 2, $service.Name is scalar and appears to have represented the cursor location of $service in $services:

    $services = Get-Service
    foreach ($service.Name in $services){$service.Name}
    

    In version 3 (and above), implicit foreach, will take a referenced object and perform a for loop automatically which could have caused performance issues. It could also just be a bug that was found and patched because as already mentioned, it's poor practice since $service is a placeholder versus an object before you get inside the loop construct. My .02 on the matter, but I don't know if you could get a definitive answer unless it was from the Powershell dev team.

    #48463
    Profile photo of Don Jones
    Don Jones
    Keymaster

    I think, too, that nobody here can really answer your questions of "why" and "what changed." Sadly, we don't have that kind of insight, and can only surmise. I'd suggest opening a ticket on UserVoice, which is where the team monitors.

    Perhaps more pointedly, I'd suggest that "it doesn't matter." What is, is. Now, if the question is, "what is the product team policy on forward compatibility," they have a goal of minimizing breaking changes. To the point, in fact, where they've left some goofy stuff lying around solely to not break things. In this case, as others have surmised, I bet they didn't know your 2.0 code even worked, as it's pretty nonstandard programming. So they wouldn't have known they were breaking it. And as Dave mentioned, the rewrite in 3.0 was likely the culprit.

    I would say 99% of the time they're either forward compatible or are clear about breaking changes. That doesn't eliminate edge cases like this, though, and it's just my observation. Nobody in the community can make a definitive statement on behalf of the team, and we can only rarely speak to their intentions.

    #48465
    Profile photo of Missy Januszko
    Missy Januszko
    Participant

    I will provide the feedback re: the programming, and if pressed for more information about forward compatibility, I will open a UserVoice. Thank you to everyone who responded!!

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.