views:

1151

answers:

4

I am feeling surprised by the difference between two seemingly identical scripts.

first.ps1:

"A"
if ($true) { "B" } 
"C"

second.ps1:

"A"
if ($true) { "B" 
} 
"C"

Now open a CMD window, and run these scripts like this:

    powershell - < first.ps1
    powershell - < second.ps1

first produces:

A
B
C

while second produces just

A

+2  A: 

Not sure why the redirection to input doesn't work, but if you just specify the script as an input argument to powershell, it seems to work:

C:\fa2>powershell.exe C:\fa2\tc.ps1
Comparison starts
There was a difference
Comparison over
zdan
+2  A: 

This has to be a bug.

In the redirection under cmd.exe case, the function completes normally and correctly if the if and else blocks are individually all on one line:

$candidate = '.\foo.txt'
$current= '.\bar.txt'

"Comparison starts"
if ($(diff $(get-content $current) $(get-content $candidate)).length -gt 0){"There was a difference"} 
else {"There was not a difference"}
"Comparison over"

But if either block is split up onto more than one line and that branch is taken, the script aborts with no warning/output.

I'd report this on the PowerShell feedback site (connect.microsoft.com).

Roy
I don't have that connection available. I emailed one of the powershell guys directly and he said he didn't think powershell supports input redirection in this way.
Ry
+2  A: 

Edit:

Yep, Jay proved it. The root problem is that Powershell does not support the '<' operator. I've been searching all day for some official documentaion on the web, but have not found it. I just occured to me to check some old notes, and I found a reference to this not being supported in v1. It only supports '>'.

I'll try to update if I find something more official than my memory. Leaving original text just for completnes.


I dont think the accepted answer is enitrely true here.

Take a look at Lee Holmes blog: link

He is one of the devs on the Powershell team, and wrote the Powershell Cookbook, just to give a little credence to his words.

I've run into this kind of problem with some complicated and archaic Bat scripts that relied on some funky fancy binary redirection. Powershell would run the Bat file, but at the point where the binary redirection took place it would just stop. Using [Process]:Start as described in the blog post worked wonderfully, and allowed me to parse the output of the Bat file like any other nicely behaved script to boot.

In your case I assume "diff" is an actuall exe and not a function, and its outputing binary and not text.

On a side note, I really don't see the need for redirecting the output of the script to Powershell like youre doing. Seems kind of counterproductive. You wrote a powershell script, seems like a waste not to use the paramter specifically provided to handle running input.

James Pogran
I'm not redirecting the output of the script. The script is being used as input to powershell.
Ry
I'm pretty sure the main problem is diff , outputting binary instead of text.Yes, the script is being input into powershell, my poor word choice notwithstanding, but I still think you're going about it wrong. Use the parameter designated for this usage (-command).
James Pogran
I just rewrote the question, and you can see that 'diff' is not the issue.
Jay Bazuzi
If you use '<' in PowerShell, it says "The '<' operator is reserved for future use."
Jay Bazuzi
A: 

I don't think this is a bug. Try typing each of those lines in on the console and you will see what is happening. When you type and open bracket and don't close it, PowerShell goes into a multiline entering mode. To exit this mode, you need a closing bracket AND a blank line afterward. If you have a blank line before or after the "C" it should work.

Of course, maybe it is a bug and just has the same effect as multiline input. :)

I can't get this to work myself, powershell is ignoring what I send into it.

JasonMArcher