I have a need to first test an XML file for duplicate element attributes, i.e. elements with the same attribute values. Then I need to compare those same attributes to another array.
Given XML of
<Definitions>
<Sets>
<Set id='S1' />
</Sets>
<Package>
<Package id='P1' />
<Package id='P2' />
</Package>
</Definitions>
I can use
$a = $xml.SelectNodes('//Package').id
to build an array of ids. And I found this thread with an answer from Dale Qiao that looks like it should work. Namely
$a=@(1,2,3,1,2)
$b=$a | select –unique
Compare-object –referenceobject $b –differenceobject $a
But when I revise that for my scenario like this
$a = @($invalidXML.SelectNodes('//Package').id)
$b=$a | select –unique
Compare-object –referenceobject $b –differenceobject $a
I get an error Compare-Object : Cannot bind argument to parameter 'DifferenceObject' because it is null.
But $a is not empty, it is the list of ids as expected.
So, first off what is going wrong. And secondly, can someone explain what is happening in that's second line, $b=$a | select –unique. I have never seen the results of a variable assignment piped like this. And what I thought was happening isn't, since I though
$b = (Select-Object -InputObject $a –unique)
would be the same, without the pipeline, and it is not. $b in that case is actually still identical to $a which makes no sense to me. But that said, I have some vague recollection of Select-Object behaving differently when used in the pipeline and not. Which is frustrating as all get out.
EDIT: It wasn't Select-Object, it was Sort-Object as I asked here. So, still wondering why it fails even using the pipeline when working with the XML, and wondering if there is a similar way to select unique items using .NET rather than a pipeline, because as with that other question, I find the pipeline to often be slow as molasses, and not particularly good for readability, so always looking for other options and falling back to the pipeline when it really is the only, or sometimes more performant, approach.
EDIT2: So, I may have answered my own question. ON the base why isn't it working front, the issue is that the array I get is really a [System.Object], and if I actually case to something else, say [System.Collections.Generic.List[String]], then Compare-Object can work with it.
And I can avoid the pipeline if I sort using the technique in that link about Sort-Object, and also cast the results of that. That said, not sure this
$a = [System.Collections.Generic.List[String]]@($invalidXML.SelectNodes('//Package').id)
$b = [System.Collections.Generic.List[String]][System.Collections.Generic.SortedSet[String]]::new($a, [System.StringComparer]::InvariantCultureIgnoreCase)
Compare-object –referenceobject $b –differenceobject $a
is really improved readability. :) It IS more performant, at around 25% of the time required for the pipeline version when I tested with an array of just 128 characters. The pipeline is taking a full 2 seconds, but even the .NET approach is taking half a second, which is not viable since this is going to happen many times at initialization. Time to look for ways to speed this up.
EDIT #3: Doh. I was doing 1000 iterations of each test, to get larger numbers for comparison. This is unlikely to be repeated much more than 100 times at initialization, and even the pipeline approach is only taking .2 seconds for that. So I suspect I can choose exclusively based on readability. And I may just keep the .NET as seeing it more often, with a comment explaining why I used it, means I will remember it. :)
EDIT #4: Doh. Nice reminder to myself how important even the most subtle of formatting can be, especially when tired.
$b=$a | select –unique looked really weird to me. Like the result of $b=$a was being piped to select –unique. But, add some spaces and $b = $a | select –unique suddenly means $b is equal to the results of $a | select –unique. Glad I looked at this a few days later, and in the morning. :) Debating if I should really use this, at least in scripts.
$b = ($a | select-object –unique)
