views:

319

answers:

6

I am in the process of answering a request for tender on a contract that requires a decent amount of text processing. The main trouble is that the customer wants to be able to run this on any UNIX (HPUX, Solaris, AIX, FreeBSD) or Linux (SLES, RHEL) platform, which may constrain what I use to do it. They don't want to make the installation of extra tools a pre-requisite.

I'm torn between Perl and awk. I know that Perl is an ideal tool for processing text (and I'm reasonably adept at it) but, before I put in the RFT response that Perl will be required, I'd like to find out if anyone is running on a platform where Perl is not installed by default.

It'd be handy to list those platforms in the RFT and give the client the option of which way they want to go. I have a vague recollection that it's not on FreeBSD in the default install and it may also be that the non-Linux platforms also don't have it.

Any other tools can be suggested but, given my familiarity with Perl and awk, they'll probably be the only ones on the shortlist.

+2  A: 

Almost every *nix (except some for very limited disk space) has Perl installed. AFAIK, even FreeBSD. Just in case it isn't, you can transform Perl program into an executable that will not need perl with PAR::Packer.

Alexandr Ciornii
Why *even* FreeBSD?
Sinan Ünür
@Sinan, I'm guessing "even BSD" since I had a vague thought they didn't ship it as standard, but through the ports.
paxdiablo
@Pax Duh! His response makes sense then. I have used FreeBSD since version 5 and all of them had Perl installed by default. The system Perl tended to be older than the ports Perl, but there is a shell script that allows root to select which Perl will be default.
Sinan Ünür
Good, that's probably what I was (mis)remembering. Most of the code will be pretty baseline Perl (I don't even do objects) so should run, even on Perl 4, if need be.
paxdiablo
+1  A: 

even if Perl might be installed on almost every *nix platforms, they might not be the same version , so be aware of this. With the requirement that it needs to works on most *nix, you can just code with shell+ utilities. For parsing files, awk+shell can do the job as well. you just have to write it in a "portable" format. check this out for more info

ghostdog74
one of Perl's goals (unlike many other languages) is to be very compatible across releases, so it is only necessary to write for minimum version.
Alexandr Ciornii
I guess this would be Perl 5.6.
innaM
There's a few (very odd) platforms that don't have good Perl ports beyond 5.004, but generally 5.6 is a good target -- it's been in use since 2000.
ephemient
+4  A: 

If the client does not have Perl on their machines you can always use Par::Packer to create an executable for that platform. This also means that you don't have to worry about using modules, since they will be included in the executable as well.

Chas. Owens
Be warned if the module specifically uses a non-permissive license like AGPL or something. You'll have to actually distribute the source code for the modules you use then. Not difficult, but it can be a pain.
Weegee
Hmm, I would argue that one, you can recover the source from the executable and, so long as you don't modify it, CPAN should count as making the source available.
Chas. Owens
@Weegee, Par::Packer just zips the files, so it is trivial to extract any code. LGPL may requires that you make it possible for the user to build new executable with their modified code, which could be a problem. The easiest way to deal with that is to include any libraries concerned in a separate par file. Your main file can then load the secondary file.
daotoad
A: 

Although I would guess that all current versions of the operating systems you mention install Perl, there will of course be older versions around that didn't and haven't. You should also be aware that even tools like awk were not routinely installed on very old UN*X versions, as it and other programming tools were optional extras (at extra cost). I remember Altos systems where even the TCP/IP stack was an extra cost item, but presumably you won't be going that far back :-)

Bottom line: If your app really needs Perl you should check it is installed (via a Bourne shell script - if theat doesn't work you are really screwed) and if not provide some way of installing it.

anon
+11  A: 

You can get a version of Perl compiled for just about any unix variant. Perl doesn't have to be 'installed', but can run inside of your application's directory. I would bundle Perl with my distribution, so you can ensure you're running the same version.

It is very difficult to write a completely cross platform shell script, without testing on the target OS. If you develop an awk script, you are probably going to develop using the GNU variant on Linux, which is a superset of the POSIX awk. I'm often configuring opening source packages on Solaris, and I'm constantly finding issues where people assume your running a modern version of a tool. For example, on Solaris bash is not the standard bourne shell (/bin/sh), and echo does not take any parameters. If you do try to code with POSIX awk, you may find yourself limited by the regex library, or out dated conventions.

Perl's artistic license allows you to bundle it with your program, as long as you follow a couple of simple things like keeping the copyright in tact.

brianegge
Actually, that's a good idea (bundling in a subdirectory) since it allows me to control the version as well although I'll have to ship multiple packages (or one package with lots of perl subdirectories selected at runtime, one per platform). I'll check out the licence. +1.
paxdiablo
A: 

Commercial Unices tend to be bundled with very old versions of Perl.

Walter H