The easiest way would be to make the XML output functionality into a module. Then you could use that functionality in your child program direcctly.

The hard way is to look at perlipc and choose one of the various ways to pass information between processes and keep your parent program as it is.

• How are you invoking and communicating with your child? If you are using text (e.g. piping, backticks or a common file), then XML makes sense because you are already handling it. Data::Dumper and eval could also work, but that's a little more hackish.

• Consider using threads and threads::shared; then you can literally pass the object. This will require some additional crafting if your child script is canned.

• Finally, why are you doing interprocess communication? It generally makes things profoundly more complicated. There are times when it's necessary, but I try to avoid it when I can.

Your child script returns a hash reference .. how? I wonder if you mean subroutine, not script. A reference is an address in memory which will become invalid at the conclusion of the script because perl will release all memory at the end of the program. In any event, if you could share your source code, it would help.

Thanks mate.Now i got it.All references will get clear as soon as script dies.I will write a seperate XML generating module and import that into my child script to produce xml output.I am not aware of how scripts communicate using perlipc.I just called child script from my parent script as follows.


my $hashref = `iim.pl -i $inputfile`;
[download]

I expected that output of iim.pl could be a hashref.Now, i get it.We can collect only STDOUT of child script in the parent script.Am i right?
Thanks,
Sriram

As long as you start the child script as you are, yes, the communication directly between parent and child is limited to STDOUT and possibly STDERR. There are many ways to communicate indirectly: have the child write the xml data out to a file which the parent will open, for instance. In your case, passing the XML directly back to the parent seems the best idea.

perlipc discusses inter-process communication, exchanging messages between independent processes running at the same time. I've read that myself, but I can't claim to understand how it works. Threads are another way to accomplish the same thing and communication between is easier. See these tutorials for more information.

G'day Sriram,

The built-in module Storable allows you to store Perl data structures and retrieve them later. This may be suitable for your use.

Here's a very quick-and-dirty example of a "parent script" (pm_1078041_parent.pl) calling a "child script" (pm_1078041_child.pl). The child creates a hashref, stores it and exits. The parent retrieves the hashref and uses it to create XML.

[XML::Simple was only used for demonstration purposes. Please don't take that as any sort of recommendation.]

The parent script (pm_1078041_parent.pl):

#!/usr/bin/env perl

use strict;
use warnings;

use Storable;
use XML::Simple;

my $file = 'pm_1078041_store';

`pm_1078041_child.pl`;

my $hashref = retrieve $file;

my $xml = XML::Simple->new->XMLout($hashref);

print $xml;
[download]

The child script (pm_1078041_child.pl):

#!/usr/bin/env perl

use strict;
use warnings;

use Storable;

my $file = 'pm_1078041_store';

my $hashref = {
    key1 => 'qwerty',
    key2 => 'asdfgh',
    key3 => {
        A => 1, B => 2, C => 3,
    },
    key4 => [5, 6, 7],
};

store $hashref => $file;
[download]

A sample run:

$ pm_1078041_parent.pl
<opt key1="qwerty" key2="asdfgh">
  <key3 A="1" B="2" C="3" />
  <key4>5</key4>
  <key4>6</key4>
  <key4>7</key4>
</opt>
[download]

Thanks Ken. I personally use LibXML.