In general, yes. Some modules are system specific (in particular, Win32 systems are pretty different from unix-based systems). And of course, when jumping between systems, you have to worry about the version of perl installed, accessory modules installed, and where everything is installed. But on the whole, with everything installed, you can run scripts without changes on any supported system.

One more thing is that is it when one compiles a programme in perl (by that I mean runs it) why do not we get a executable as once a programme has been compiled it means that it has been converted into machine readable code by the compiler..?

Perl code is interpreted, and run, but a lot of the running is still dynamically determined. There are perl->executable programs out there (I've lost track of the status at the moment), and they work by embedding the perl interpreter into the executable. A compiled C program is very different from a running perl program.

A compiled C program is very different from a running perl program.

To try to help clarify your 2nd question a bit more: It is my understanding that, in general, C programs are "compiled" into an executable, whereas Perl scripts are "interpreted" at runtime--each time the script is run (this would not include the executable Perl programs swiftone mentions, I'm assuming). Hence the differing terms, C program and Perl script. Although this adds to the runtime overhead, it makes debugging nicer in Perl since you don't have to re-compile the whole program after every little change. (Please correct me if I'm wrong, though, as I'm still learning Perl and would welcome any chance to improve my understanding)

C programs are "compiled" into an executable, whereas Perl scripts are "interpreted" at runtime

Actually, I believe that perl scripts have a sort of "pre-compile" step. This is where BEGIN{} blocks and use statements and other such pre-runtime things are decided. Though this normally happens at the first step of running the program (not true in cases like mod_perl), this step is normally refered to as "compiling"

As for script versus program, from the perlfaq1:
Is it a Perl program or a Perl script?

Larry doesn't really care. He says (half in jest) that "a script is what you give the actors. A program is what you give the audience."

(More available in the faq)

I can also write code that is not portable. Using system calls that require extra software are only portable if you provide the extra software. (For example, Sendmail is not standard on NT, so if you want to run a script that uses Sendmail you must find an NT port of Sendmail.)

Additionally there are modules that are OS specific (like the Win32 modules).

As for the term 'compile', when a script is run it is first compiled into something called Perl byte-code. This is like, but not the same as, assembly language. The interpreter then interprets the byte-code.

Note that incompatibilities such as these are often the result of someone making the assumption that the script will only be run on the platform of choice. If you plan ahead, you can use variables like $^O to determine your operating system, and use that information to select an appropriate directory separator. Things like binmode should be used across the board if you truly want your scripts to be portable across OS's. It's simply a "no-op" under Unix.

Also note that Perl functions like open and system typically accept Unix-style slashes (/) for specifying path names when opening files or executing programs. Unfortunately (and this may depend on the syntax of the system/exec call), Win2k may not follow this convention.

But basically the point of my post is that you can write Perl code that is totally portable, so long as you are aware of OS-specific conventions and code to accomodate, and don't make bad assumptions about your environment. Otherwise you may end up having to do some minor tweaks to "port" your script from one OS to another.

Of course you are quite right, and to some extent I did these things, but there was some difficulty in getting a good Perl (version > 3) for VMS at that time, and for reasons I won't get in to we could not compile Perl ourselves... I guess that gets back to the earlier point on having similar Perls on each platform.

As a testament to Perl, in some of the VAX work Perl was used to replace Fortran code for translating Fortran binary data structures to ASCII for dumping to PCs, and it was a heck of a lot easier to use than Fortran!