So I was doing some scripting and and after a while the code got a bit bigger than just one line. So I decided it is time to bring out the big guns enter PowerShell Integrated Scripting Environment (ISE). So I copied the oneliner that was working perfectly into the ISE and noticed that it wasn’t working anymore. So what black magic was changing what I just had copied and pasting into the ISE.

$array = ('Row1
Row2
Row3').split()
$array.count

So after a bit of research I found out the following logic.

When running by just inserting the text into a Powershell window everything is great. When I tried both just executing a ps1 file or from the ISE I got the following results:

What is going on

So now we are getting different results for the same split depending if we specify the separator or not. So lets check how the split is defined.

As we see here there is not really a split() without parameters but there seems to be a default separator. And if we read the MSDN article, we find that it is white-space characters. First we need to talk about what is a newline.

The newline

So there are atleast three new lines, line feed (the character), a new line (like just pressing the enter key), newline (a clothes brand). Well the last is really not the point here. So what makes up a new line. Here comes the tricky part, it depends. To understand this we need to go to the line feed the character.

Line feed is the ASCII character 10. It in most programming languages escaped by writing \n, but in powershell it is `n. But Windows is not content with just one character, Windows also uses carriage return which is ASCII character 13. Escaped \r. So what is the difference? Line feed advances the pointer down one row and carriage return returns it to the left side again. If you store a file in Windows by default are linebreaks are stored as first a carriage return and then a line feed \r\n. When we aren’t using any parameters for the split() command it will split on all white-space characters, that is both carriage return, linefeed, tabs and a few more. This is why we are getting 5 results when there is both carriage return and line feeds.

But why did it work when you just ran it in a Powershell console?

Lets look into that string and see that thing I was talking about:

Here in the ISE window we are seeing both the carriage return and the line feed. Next we are turning our eyes on the Powershell console instead.

Here we see that when pasting directly into the Powershell console a new line is represented only by the line feed.  So all file operations have both characters and others have only the feed line? No, as you see in the example above I did paste directly into the Powershell ISE and got the same behavior as with a text file.

How can I make it work

Lets just make sure we don’t have any carriage returns to make problems for us.