Author Posts

September 1, 2015 at 7:11 pm

I am trying to sort out the basics. What is the difference between using split in these two different ways?

PS C:\> $a.split("he").length
57
PS C:\> ($a -split "he").Length
5
PS C:\>

September 1, 2015 at 8:06 pm

$a.split("he").length
splits at each individual "h" and "e" character

whereas

($a -split "he").Length
is splitting when both "he" characters are present together.

September 1, 2015 at 8:22 pm

In a more general sense why is .split() different than -split? I thought they were the same just in a different format.

September 1, 2015 at 8:45 pm

It's also notable to mention that .split() is a method of the system.string class:

https://msdn.microsoft.com/en-us/library/b873y76a(v=vs.110).aspx

and -split is a powershell console operator

https://technet.microsoft.com/en-us/library/hh847811.aspx

or do Get-Help about_split

Looking at the MSDN documentation for the split method for system.string objects you can see that the only constructor for the split method with one argument accepts a char array or "char[]". Since you've supplied "he" as the argument, the operator will convert that to a char array or char[] ("h","e") and split on the individual letters, which explains the behaviour described by Curtis.

To mimic the default behaviour of -split with the .split() method, you can do the following:

$a.split(@("he"),[system.stringsplitoptions]::RemoveEmptyEntries)

September 1, 2015 at 9:44 pm

Thanks. That clears up a lot 🙂

September 1, 2015 at 9:50 pm

The -split operator is essentially wrapping the [regex]::Split() method, rather than string.Split().

September 2, 2015 at 7:16 am

Peter,

Adding [StringSplitOptions]::RemoveEmptyEntries to .Split() does not make it act like -Split in most cases, as .Split() will still split on each individual character.

For example, ("weather") -Split "he"
results in
weat
r

but ("weather").Split( "he", [StringSplitOptions]::RemoveEmptyEntries )
results in
w
at
r

September 2, 2015 at 7:23 am

Tim, the key to Peter's example is the @() around the split criteria. I believe [StringSplitOptions]::RemoveEmptyEntries just puts it into the overload scenario that is needed for the criteria to be recognized as a string. To be honest, I am not a programmer by trade, so I'm just doing my best here to understand what is going on. The way I read this, Split is going to break down the split criteria, if you pass it a string, it breaks it down into characters, if you pass it an array of strings, it uses the whole string.

In your example
("weather").Split( @("he"), [StringSplitOptions]::RemoveEmptyEntries )

Results in:
weat
r

Another example
("weather teather").Split( @("he", "ea"), [StringSplitOptions]::RemoveEmptyEntries )

Results in
w
t
r t
t
r

September 2, 2015 at 7:39 am

Ah, I see. I was focusing on RemoveEmptyEntries and why that wouldn't help. But it's not really there to remove the empty entries, it's just there to get .Split() to use an overload that can take an array of strings instead of an array of characters. And then the @() tells it you want it to be an array with a single string, instead of a string representing an array of characters.

Nice.

This would then do the same thing, with less typing (and without removing empty entries, which you usually don't want to do anyway.

("weather").Split( @("he"), 'None' )