I have a little unix/Linux experience. I don't know Perl. I'm trying to run a basic "Hello world" file in Perl on OSX. Has anybody else had any luck with this? What is the path to the binaries? Is it #!/usr/bin/Perl ? To make my script executable I do a chmod u+x <filename> from the command line right? Is there a way to make a perl script executable by doubleclicking on it? If so Perl on X is going to rock.

Has anybody had any luck with this? Thanks.

yeah for the most part...
The file system browser (excuuuuuse me the finder) doesn't seem to recognized it as an executable file and opens it in the editor for me when I doubleclick.. All it would do anyway is to launch a terminal window and run it there. You can easily drag the file into a terminal window and hit the return key for the same effect..
I think the "finder" should see the file as executable and do this for me.
jhh

[petard]

Originally posted by jhh:
I think the "finder" should see the file as executable and do this for me.

To get the Finder to take the appropriate action for these perl scripts, simply open the inspector for the file in question (command-i) and select "Application" from the show menu. Then set the Application to Terminal.app. Terminal then pops up a window when you double-click on the .pl file from the finder and the script is run.

--
petard

I used vi to create a file:
#1/usr/bin/perl
print ("hello, world!\n");

2 lines
I saved the file in my default user directory as HelloPerl.pl
At the command prompt I typed:] chmod u+x HelloPerl.pl
I then typed:] HelloPerl.pl
I got back:] HelloPerl.pl: Command not found
Am I even using the right path to the binaries? Do I need to use the command prompt to create the path to the Perl binaries? I'm stumped at square one. Any help would be greatly appreciated.

btw: when I used the Inspector to associate the Terminal App with the HelloPerl.pl file I didn't even get the error message. Nothing. Just a blank first line command prompt.

[int69h]

when in doubt use which.

[davinci:~] terry% which perl
/usr/bin/perl
[davinci:~] terry%

Contents of my HelloPerl.pl

#!/usr/bin/perl
print "Hello World!\n";

Attempt to run HelloPerl.pl

[davinci:~] terry% chmod u+x HelloPerl.pl
[davinci:~] terry% HelloPerl.pl
HelloPerl.pl: Command not found.
[davinci:~] terry% ./HelloPerl.pl
Hello World!
[davinci:~] terry%

This means that the current directory is not in $PATH.
In order to fix this issue this command: setenv PATH "${PATH}:."

If you get tired of entering this command in every instance of Terminal, you can append it to a file named .tcshrc in your home directory.

[int69h]

when in doubt use which.

[davinci:~] terry% which perl
/usr/bin/perl
[davinci:~] terry%

Contents of my HelloPerl.pl

#!/usr/bin/perl
print "Hello World!\n";

Attempt to run HelloPerl.pl

[davinci:~] terry% chmod u+x HelloPerl.pl
[davinci:~] terry% HelloPerl.pl
HelloPerl.pl: Command not found.
[davinci:~] terry% ./HelloPerl.pl
Hello World!
[davinci:~] terry%

This means that the current directory is not in $PATH.
In order to fix this issue this command: setenv PATH "${PATH}:."

If you get tired of entering this command in every instance of Terminal, you can append it to a file named .tcshrc in your home directory.

[parallax]

That's the correct binary location.

The script works for me, try typing in:

perl HelloPerl.pl at the command line.

prior to setting the path as specified by "int69h" the method provided by "parallax" worked. It never occured to me to throw the file to perl as an argument, but that did work, however as int69h so graciously instructed setting the path by typeing ] setenv PATH "${PATH}:." makes a perl script work just like a shell script which is what i wanted. Thanks!

Adding your curret directory to your PATH with PATH=${PATH}:. can be a security risk. Someone might disable a common system command and place a trojaned someplace sensitive.

just a thought.
j

[int69h]

If someone has enough privileges to remove system commands, you've got a lot more to worry about than a trojan.

Let's say some luser writes a program that appends + + to ~/.rhosts and leaves it somewhere as ls. Since . is at the end of the path you won't execute that binary anyways. You'll execute /bin/ls. If they've got +w to /bin/ls, they could just put their trojan there and not fool around with duping you into running it. For that matter, they could just echo "+ +" >> /Users/YOU/.rhosts.

What I was trying to get at was that IMHO, having "." in $PATH isn't a risk except for uid 0. I forgot that many of OSX's users have no exp. w/ UNIX, and that they wouldn't know that Golden Rule.

Here's another Golden Rule. Always, always, always run pwd before rm -rf. Several years ago I managed to rm -rf / while trying to clean out /tmp. Wiped all of 'nix partitions as well as the DOS partition I had mounted. One of the few times I can remember getting physically ill from something that happened on the 'puter.

[int69h]

If someone has enough privileges to remove system commands, you've got a lot more to worry about than a trojan.

Let's say some luser writes a program that appends + + to ~/.rhosts and leaves it somewhere as ls. Since . is at the end of the path you won't execute that binary anyways. You'll execute /bin/ls. If they've got +w to /bin/ls, they could just put their trojan there and not fool around with duping you into running it. For that matter, they could just echo "+ +" >> /Users/YOU/.rhosts.

What I was trying to get at was that IMHO, having "." in $PATH isn't a risk except for uid 0. I forgot that many of OSX's users have no exp. w/ UNIX, and that they wouldn't know that Golden Rule.

Here's another Golden Rule. Always, always, always run pwd before rm -rf. Several years ago I managed to rm -rf / while trying to clean out /tmp. Wiped all of 'nix partitions as well as the DOS partition I had mounted. One of the few times I can remember getting physically ill from something that happened on the 'puter.