I see a gaping security hole. You are passing strings from the wild directly to a command line which is interpreted by the shell. Fixing that will probably fix your stated problem, too.

First, make sure that your trim(uc(thing)) actualy makes your string safe to use (I kind of doubt it; better to do an explicit string check or match it to a hardcoded hash key).

Then, clarify what it is you want to do in the second script. Do you want to do actual CGI stuff? Why don't you hand off to it with an exec, then, instead of a system? Having two scripts contending for the I/O of CGI is a path to failure.

Describe what you are trying to achieve.

Perhaps you should write out what you expect the parameters to the second script to look like, then run that script from the command line using the parameters as you have written them. Debug your second script "manually" first, then try executing it from the first script.

First, I may have been unclear in my question/posture and thus I must remedy that lack of clarity now. I am VERY, VERY new to PERL. In fact, if there were a way to compare a pool that was 1mm deep by 1mm in diameter, that would be MANY, MANY times the volume of knowledge I have about PERL. So, here's what I'm trying to do and why I'm thinking I should progress down said path. If there is a better way to do this then please, tell me. I'll do it EXACTLY the way you say.

Technical Boundaries:

1) In my production environment the set of scripts will be fired via a tool called Dollar Universe. Dollar Universe is a centralized job scheduling tool (think of cron on crack) use to schedule many jobs on multiple machines. If you want you can see http://www.orbitsw.co.uk/du_index.html for more details. 2) As a result of #1 I MUST assume that my scripts will NOT have access to a standard Solaris shell. In fact, said scripts only have access to STDIN. This means doing things like 'pwd' to get the current working dir seems not possible inside the script. 3) I will be developing this set of scripts on a development environment where I WILL have access to a shell BUT, again I SHOULD NOT assume this in production. Along with the dev environment there is a test and a production look alike that these scripts will move through.

4) When the job scheduler calls my script as a daily, monthly, weekly or any other "time frame" job I need it to pass the "controller" script called laoder.pl 2 parameters. The first parameter will tell the loader.pl what is the operating time frame and the second, if it is in the proper time frame, will tell the loader.pl what granularity of Oracle data load to perform for which time frame.

5) Since 4 is true, I have to be able to receive the CLI parameters in loader.pl and possibly pass them on to other *.pl scripts in directories BELOW the dir level of loader.pl

6) The end goal of this is to, based on the passed parameters, fire an Oracle sqlldr process to load up some flat file data into some Oracle tables.

7) By using a controller *.pl file (that's loader.pl) I hope to design this in a way to be able to EASILY add or delete timeframe loads as marketing decides they want them added/deleted.

As far as 'Debug your second script "manually" first' ... I have and it works great. In other words, I can pas it parameters manually at the CLI and it runs like a champ. But, based on the items above I can't assume this script will have access to a shell when it runs in production .... thus the reason I want to "magically" pass in stuff from script 1 (loader.pl).

Thanks in advance for your help. Have a nice day and remember I'm REALLY new at this.

So in a nutshell:

Script 1 executes script 2 and passes two pieces of information to it? Ok, cutting out the noise somewhat you have something like this:


script 1:

my $script2 = ...; # including dir as required
my $param1 = ...;
my $param2 = ...;

system("$script2 \"$param1\" \"$param2\"");

script 2:

my $param1 = shift; #Pull off the first command line argument
my $param2 = shift; #Pull off the second command line argument

#do stuff with $param1 and $param2
[download]

---

Perl is Huffman encoded by design.

You may find the replies in this thread illuminating.