|
s_gaurav1091 has asked for the wisdom of the Perl Monks concerning the following question:
Hi Monks,
I need to port a perl script to windows.I want to know that is there some direct way to do it or I need to change all the unix commands which i have used in my script?plz suggest |
Re: porting a script to windows
by secret (Beadle) on Dec 13, 2005 at 12:52 UTC
|
It depends on what you do in your script.
Of course if you are using `` or system you will need to have the proper windows executables instead of the unix ones.
You can also change the shebang to #!perl.
Also, some modules are not cross compatible.
Finaly some perl things don't work well under windows. Everything (almost) you need to know is in perlport . | [reply] |
Re: porting a script to windows
by Happy-the-monk (Canon) on Dec 13, 2005 at 12:56 UTC
|
Furthermore, if you will have to maintain and support your script on several platforms, you might want to try to get rid of the external commands by looking for solutions in pure Perl. That makes cross platform scripts easier, most of the time.
Have a go on CPAN search to see, if what you need isn't already available.
...in my experience, it often is.
Cheers, Sören
| [reply] |
Re: porting a script to windows
by jonadab (Parson) on Dec 13, 2005 at 14:16 UTC
|
Hi Monks, I need to port a perl script to windows.I want to know that is there some direct way to do it or I need to change all the unix commands which i have used in my script?
If you mean Perl builtins that have their roots in
Unix culture, then you won't need to change anything.
However, if you've been calling actual external
system commands (e.g., with backticks, system, or
exec), then that's inherently unportable. (It's
often not even portable from one Unix to another,
unless you know what you're doing. For instance,
`ps -A` works on Linux, but on some unices you
have to use `ps -x` instead. On Windows, of
course, ps is not a command at all.)
Another thing to note is that if you have hardcoded
any paths, you'll have to change them. However, you
*should* be reading in paths from a configuration
file or the command line (unless your code is all
in a single file, in which case you can just set
them in variables at the very top of the script).
Hardcoding paths leads to trouble even if you
don't end up porting to a completely different
platform.
The biggest pain in moving to Win32 is that with
the most popular Perl distribution (from ActiveState),
there's no CPAN support out of the box. There's ppm,
but it's just not the same. If you rely heavily on
the CPAN, you may end up needing to go with Cygwin
Perl or somesuch so that you can get CPAN.pm working.
Oh, and there's also the small matter of Perl not
being included in the operating system. Windows is,
as far as I am aware, the *only* major operating
system remaining that *doesn't* include perl out
of the box.
"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."
— Pratico & Van Pelt, BBHG, p68
| [reply] |
|
|
| [reply] |
|
|
ppm does not constitute CPAN support. It does provide for (some, limited) module installation, but what it provides is only comparable to what is available for other languages, like Java or Python; it is not full CPAN support. Many modules are not available at all, and those that are available are usually rather badly out of date.
This is not entirely ActiveState's fault. They had to make bricks out of straw to provide anything at all for module installation, due to a marked paucity on the host operating system of the sorts of facilities that are normally expected on a POSIX system (e.g., make).
| [reply] |
Re: porting a script to windows
by xdg (Monsignor) on Dec 13, 2005 at 15:10 UTC
|
change all the unix commands which i have used in my script
If you script is dependent on lots of unix commands that you're calling via system or backticks, then you probably need to rewrite a lot of it purely in Perl.
However, I've been very pleased with unixutils as a native port of many standard GNU utilities to Win32. If you're only relying upon tools included in that project, then you may be able to use them seamlessly with your existing script -- though there could be some subtle differences that won't work as you expect.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply]
[d/l] |
Re: porting a script to windows
by QM (Parson) on Dec 18, 2005 at 16:18 UTC
|
No one has mentioned cygwin yet, so I'll throw it out. If you have to option to install it on the target machines, that may cover the Unix commands that have no Windoze equivalent.
However, as implied by other responses, anything outside of pure Perl may have issues. For instance, the ps command comes in many flavors, and it's not always easy to tell which flavor(s) is(are) available at runtime by inspecting pathnames or even man pages.
If you can list your dependencies outside of Perl, you'll be halfway to porting it. You should also look at perlport and other resources for future programs.
-QM
--
Quantum Mechanics: The dreams stuff is made of
| [reply]
[d/l]
[select] |
|
|
