Just an FYI: Perl doesn't care about the line-endings in source files. Perl on any platform will happily and correctly parse source files with line-endings from any platform it supports*.

* If there's some weird platform out there that uses some exotic line-ending scheme, Perl probably won't understand it unless Perl has already been ported to it. This is not the case for Unix (Mac OS X) and Windows.

Now I am confused. Do I need to worry about line endings in this script or not?

#!/usr/bin/perl

print "Hello\n"

That may well be true if you invoke 'perl' and then give it a file containing the script. But if you use the usual "shebang" method to invoke 'perl' from a script file, then it definitely matters what line-endings you use. I.e. with the wrong line endings, it is as if the whole script is on the "shebang" line. Try it!

You shouldn't have to.

Another thing to try would be the following:

It's functionally the same as the test script, but without the script. If this works, there's something particular to reading scripts. If it doesn't, the Perl installation is just plain broken.

Yes, you do.
You always need to have Unix-style line-endings in any script files you want to run as if they are executables - i.e. by just typing the name of the script file.
Just make things easier on yourself by running the one-line Perl script I supply in the Unix FAQ and you will be sure that your script file has the correct line-endings.

To be more clear, Perl doesn't care, but the shell does. I created the test script in Windows, using VMware Fusion.

Here's the shell session I tested with:

Running the script straight from the command-line failed, because the shell treated the DOS end-of-line character as part of the interpreter name.

When I ran perl manually, passing it the name of the script, Perl parsed and ran it correctly.

Sorry to be pedantic, but it's not the shell - it's the OS's underlying exec mechanism. See references in the Wikipedia article I linked to above re "shebang".

Technically, we're both right.

Because the exec function can't find the interpreter listed, it passes it off to the shell to try. The error message I posted is from bash, not the kernel.

To illustrate:

The test script is named moo. All it does is echo a line, using the interpreter cow, which doesn't exist. However, the script still runs, using the current* shell as the interpreter.

It can also be shown that the exec function does not treat a carriage-return (the first character DOS uses to indicate end-of-line) as a whitespace character. Here is the same script I posted above, but with a parameter added to the interpreter invocation (-w turns on warning mode for Perl):

* Or it uses the $SHELL environment variable or the user's default shell. I am not sure.

Umm, you forgot the "!" in the shebang line, so it's just treated as a comment. Nothing funny there.

Oops! Good catch! :o

(Offtopic)
On the subject of funny stuff, see post #17 of this old thread: http://forums.macosxhints.com/showthread.php?t=12881

I miss mT around here. We used to talk regularly after he left the forums, but I haven't seen him in ages.

What's wrong is that it was posted 07/01 and not 04/01, Hayne. :p

It also occurs to me that the original script doesn't necessarily produce output.

Make the last line

print "done";

then run it.

Thinking I should have been more descriptive in where I was going.

"I use the terminal to run the script and I don't get any errors, but nothing else happens either"

HTTP::Request::Common should echo back an error if it can't get a dns entry for the site. it should echo back if it does and connect properly. but what if it doesn't connect at all? As in gets a host name but times out trying to connect?

What if the script is doing something, but you have it in a condition where there is no output?

Stick some print statements in and see where it dies?


By the way, your script works exactly as posted (with the path to perl correction noted above) on my leopard computer, exactly as it should.

You. Are. Cruel.

:D