0

I'm running ActiveState Perl 5.10.1 on Windows XP.

The following program executes, but produces no output at the command line:

#!c:/perl/bin/perl.exe

use strict;
use warnings;

print "foo\n";

If I remove the shebang line, I get 'foo' shown as the output, as expected.

I get the same result if I execute using file association only (foo.pl), referencing perl via PATH (perl foo.pl) or even directly referring to the perl executable (c:\perl\bin\perl.exe foo.pl).

I don't understand why the script works without the shebang line, but I get no output when the shebang line is present. My understanding is that the shebang line isn't strictly necessary for Perl in Windows, but it's considered good practice in case you want to use switches like -w...

It makes no difference if I explicitly make the handle STDOUT, i.e. print STDOUT "foo\n";

This is driving me absolutely crazy; any tips would be appreciated.

GainfulShrimp
  • 168
  • 6
  • 70 (presumably bytes) – GainfulShrimp Jun 07 '13 at 07:04
  • ok, correct line endings for Windows. – ikegami Jun 07 '13 at 07:05
  • I doubt it will make a difference, but can you add the missing newline at the end and try again? – ikegami Jun 07 '13 at 07:07
  • If I save the script as ANSI (rather than UTF-8) in Notepad++, I get size of 67. I guess that's the BOM? But it makes no difference to the result - still nothing with the shebang present. :( – GainfulShrimp Jun 07 '13 at 07:07
  • Sorry that's just my quoting in this question - the actual file has two new lines at the bottom. – GainfulShrimp Jun 07 '13 at 07:08
  • ok, should have asked this to begin with. Can you provide the following: `perl -0777nE"say unpack 'H*', $_" foo.pl` (a hex dump of the file). – ikegami Jun 07 '13 at 07:11
  • The thing is, I've seen this kind of problem with files with the wrong line endings. – ikegami Jun 07 '13 at 07:12
  • It outputs this: `2321633a2f7065726c2f62696e2f7065726c2e6578650d0d757365207374726963743b0d757365207761726e696e67733b0d0d7072696e742022666f6f5c6e223b0d0d` – GainfulShrimp Jun 07 '13 at 07:15
  • You might be onto something here... retyping the file in Notepad, gives a different output to that hex dump: `2321633a2f7065726c2f62696e2f7065726c2e6578650a0a757365207374726963743b0a757365207761726e696e67733b0a0a7072696e742022666f6f5c6e223b0a0a` – GainfulShrimp Jun 07 '13 at 07:20
  • And the Notepad-produced file gives output as expected. Now I need to figure out what's broken with my Notepad++ (I've not had this problem before and I've been using this machine for Perl for years now!). – GainfulShrimp Jun 07 '13 at 07:22

1 Answers1

5

The program I gave you was incorrect. It should have been

perl -0777nE"BEGIN { binmode STDIN }; say unpack 'H*', $_" <foo.pl

But it still revealed the problem. Your lines are terminated by carriage returns (0D) instead of CRLF (0D0A)!

2321633a2f7065726c2f62696e2f7065726c2e6578650d
0d
757365207374726963743b0d
7573652‌​07761726e696e67733b0d
0d
7072696e742022666f6f5c6e223b0d
0d

To Perl, that's all one line. That's right, your entire program is a very long shebang line.

Switch from MacOS line endings (a machine that was obsolete 10 years ago) to Windows lines endings, and your problem should go away.

ikegami
  • 367,544
  • 15
  • 269
  • 518
  • Thank you so much. I had just discovered as you posted this that the program worked if I used Edit > EOL Conversion > Windows (in Notepad++). I have no clue how I accidentally switched to "Mac mode". :) – GainfulShrimp Jun 07 '13 at 07:38
  • Macs these days (i.e. OS/X) use unix line endings (0A). I was very surprised to see 0D! – ikegami Jun 07 '13 at 07:44