Everything I know about Perl can be fit on a pin head

[SteveGlo]

and still leave room for all Shakespeares'plays.

So please excuse my ignorance.

I have just been given a project brief with one of those unmoveable deadlines (mid-January) and I need some insights.

A third party has written a Perl script which will take as input 2 files (text) and also calls some freeware - mixes it all up and generate an XML.

What (I think) they want me do do is write something or other that generates the 2 files from some database tables
using MapBasic programs then 'runs' the perl script.

One of the issues is (to quote)

"the environment under which the perl script runs is not known. The ideal would be a Windows executable but it is suspected that it may run in DOS under a DOS command prompt. If that is the case, running the perl script from the application that generates the 2 files could be a challenge"

So, excusing all the vagaries, can someone tell me how perl scripts are usually run and whether or not there are any major difficulties running perl scripts from (eg) VB programs that shell DOS commands?

I'll understand if the above is regarded as unintelligible garbage.

 

[TrojanWarBlade]

Perl does work in windoze.
Perl scripts are part interpreted and part compiled so you need the perl interpreted to run the scripts. You do NOT usually get an executable from a perl script (although there are some commercial perl compilers available that will generate a .exe if that's really necessary).
Anyway, the upshot is that if you have an association for the ".pl" extension to your perl interpreter then when you double click the script it will be sent to perl for processing and will usually kick off a dosprompt for the output (stdout).
If you give us more detail about what the perl script actually needs to do then maybe we can help more.
I don't know anything about MapBasic so that does not help.

Perl can create windoze windows (if you see what I mean) but that's usually unneccessarily overcomplicating the issue.
In your case it sounds like you need to feed some data in (from somewhere), process it and generate some output files.
Perl is ideal for that.

Tell us where the data comes from, what it looks like, what processing you need done on it and what you need the output to look like and you might be surprised just how simple it is and one of us may even be able to do some or all of it for you.

Give us more to chew on please!!!




Trojan.

 

[SteveGlo]

Trojan

Thanks for the response. I was given sight of this work this morning and all the interested parties haven't come back to work today so I was just hoping to get some more background before I start in on them.

I haven't had sight of the perl script (not that it'd probably mean much to me), apparently it has been written by a third party and is not to be tampered with by 'us'.

I think that what is envisaged is that some wrap around application, possibly VB, first runs 2 MapBasic programs to generate the necessary files and then starts up the perl script which takes as input, during processing, the 2 files that have just been generated.

I can probably write the code that creates the 2 files its the bit that comes next that may be of concern. If it hadn't been raised as an issue in the project brief I would have assumed that VB could shell a DOS command to run a perl script quite easily.

I presume the 2 files and file path haven't been hard-wired into the perl script but who knows what people get up to nowadays.

I think the intended userbase is IT iliterate so effectively they just want a start up form (VB?) with a 'Go' command button.

I assume that the perl script can itself be enclosed within some sort of perl.bat file which can also store the location and file names needed during processing.

Initially this is all to be run on a stand alone laptop and I am not even sure what perl associated software has to be installed but once I have sight of the actual perl script hopefully the authors will include some help text about what it needs as input parameters etc,

Anyway I will certainly return to this thread if necessary - I don't think my organisation's IT section has any perl expertise.

Thanks again.

Steve

 

[PaulTEG]

A batch file is what you need to run the programs, or a perl script.

That way if there's no gui, it can be set up as a Scheduled Job, or even as a service on the windows box if needs be

--Paul

Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[SteveGlo]

Paul

Thanks for answering. If a perl script needs as input 2 files and the path to these is not hardwired in the script what would be a standard way to supply the location of these 2 files as parameters - if you were running the perl script from Start->Run. I want to to test that from some VB ShellExecute code with some dummied up script I can get off the net (a simple script that does the usual 'Hello p1 p2' where p1 and p2 and firstname and lastname).

Nothing is available to me yet but the fur is beginning to fly - the script won't be available 'til 25 January apparently even though it was originally supposed to be ready before the end of December.

Course the post-script development time has not been extended!

 

[PaulTEG]

First off make sure that the script is a dependency on the project plan. Then it's late arrival will push out your deadline.

It's a game, don't be soft and play by the rules ;-)
You won't need to, what you're looking to do is very straightforward, but there's no need to be a wuss

#!/usr/bin/perl
$param1=$ARGV[0];
$param2=$ARGV[1];

print "You entered $param1 $param2\n";

@results=`perl /path/to/script.pl $param1 $param2`;
foreach (@results) {
  print;
}

HTH

Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[SteveGlo]

Paul

Thanks for the code example. We won't be expected to tinker with the perl script that is being supplied. What I really want to know is what I need to run it. I am thinking of running it from VB and I wonder if it is as simple as;

Dim RetVal
RetVal = Shell("c:\blah\perlscript.pl,param1, param2", 1)

or

RetVal = Shell("c:\blah\perlscript.pl param1 param2", 1)

(or I may use the ShellExecute api).

but it will only take a few minutes to code and test so I am not to worried about it. If it is not so simple as that the problem probably lies outside of any claim to expertise that I have anyway.

I don't intend to be railroaded either - I have had more than enough of the client division going its own way right up to the final days of a 'project' then coming to the IT section and demanding we fix the little bits that are left to do.

Thanks again.

Steve

 

[PaulTEG]

RetVal=Shell("C:\Perl\bin\perl.exe perlscript.pl param1 ... paramX")

Should be all you need, you can test with a hello world type script in advance of the script's arrival

HTH
--Paul

 

[SteveGlo]

Paul

Thanks a million - that is the syntax that I have been after. The laptop with the perl.exe is due next Friday so I'll be able to test then.

Thanks again

Steve

 

[PaulTEG]

http://www.activestate.com,

just look for activeperl, and you're sorted, it's free

Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[Ghodmode]

The perl script runs as an argument to the program perl.exe. This program runs from the console. You can use a shell escape from VB or any other programming language to execute something like "c:\Program Files\ActiveState\Perl\bin\perl.exe myscript.pl". If the script doesn't have any console output, you don't need to run it in a console (i.e.: command prompt).

I think that answers the original question, but I gotta say it...

The basics of all programming languages are the same.

You have variables with data types, conditional statements, loop control statements, functions, libraries, etc.

If you mention OO characteristics, that does make it a little bit more complex, but not really that much.

If you know about these basics, you can probably read some source code and get the gist of what a program is trying to do.

So, anyone who is bold enough to call themself a programmer should know these basics.

These basics also apply to the Microsoft programming languages. The problem is that the IDE is so "intuitive" that some people can't create computer programs without it. Those people call themselves programmers too

--
-- Ghodmode

 

[SteveGlo]

Thanks Ghodmode

I've been programming for a long time and I agree that there are many shared concepts between programming languages. However it is not always possible to guess syntax and that was what I was after and I thank the responders for taking the trouble.

I've had no contact with perl before this project came up. Basically the perl script that will be supplied will be a closed box which we will not be able to examine (at least contractually) even if we had the texhnical skills to do so.

What is embarrassing is that after all this effort the funding division may go ahead and get the third party writers of the perl script to do everything else as well!

In other words - a complete waste of my time and evferyone else in my section that has been involved.

 

[PaulTEG]

That's why cross departmental charging is such a nice concept, they get hung for trying to hang you, paying for stuff on the double, it'd be fun at the next budgets meeting :-D

Spend an hour a week on CPAN, helps cure all known programming ailments ;-)