any perl tool to create a flow of perl scripts

[iarunkumar]

We have hundreds of perl scripts being used. It's hard to debug and
don't know the flow like which one is calling which. Is there any tool
that creates a flow chart like giving a visual view of multiple perl
scripts.

Thanks
Arun

 

[Uri Guttman]

i> We have hundreds of perl scripts being used. It's hard to debug and
i> don't know the flow like which one is calling which. Is there any tool
i> that creates a flow chart like giving a visual view of multiple perl
i> scripts.

sounds like a bad design to begin with. having scripts calling scripts
is slower and harder to debug. convert most/many to modules and you will
be able to track their usage better, improve speed and ease
maintenance. otherwise tracking will need something like strace to see
what procs get called.

in other words, hire a quality perl professional to refactor your mess
into a cleanly designed system.

uri

 

[john.swilting]

i> We have hundreds of perl scripts being used. It's hard to debug and
i> don't know the flow like which one is calling which. Is there any
tool i> that creates a flow chart like giving a visual view of multiple
perl i> scripts.

sounds like a bad design to begin with. having scripts calling scripts
is slower and harder to debug. convert most/many to modules and you will
be able to track their usage better, improve speed and ease
maintenance. otherwise tracking will need something like strace to see
what procs get called.

in other words, hire a quality perl professional to refactor your mess
into a cleanly designed system.

uri

:-[

 

[john.swilting]

i> We have hundreds of perl scripts being used. It's hard to debug and
i> don't know the flow like which one is calling which. Is there any
tool i> that creates a flow chart like giving a visual view of multiple
perl i> scripts.

sounds like a bad design to begin with. having scripts calling scripts
is slower and harder to debug. convert most/many to modules and you will
be able to track their usage better, improve speed and ease
maintenance. otherwise tracking will need something like strace to see
what procs get called.

in other words, hire a quality perl professional to refactor your mess
into a cleanly designed system.

uri

:-[

me, I start to improve me. I do not post any more in France. it does not
like me
(co)

 

[john.swilting]

Here, instead, I bet most people like you as much as to acknowledge
your contributions to the group along the lines of acknowledged people
in

if I can help it, I would post a solution

 

[xhoster]

We have hundreds of perl scripts being used. It's hard to debug and
don't know the flow like which one is calling which.

How is this calling taking place?

Is there any tool
that creates a flow chart like giving a visual view of multiple perl
scripts.

I'd use the system's grep, find, etc.. Or maybe Perl.

Xho

 

[Mark Clements]

We have hundreds of perl scripts being used. It's hard to debug and
don't know the flow like which one is calling which. Is there any tool
that creates a flow chart like giving a visual view of multiple perl
scripts.

Autodia will help you to analyse individual scripts and the modules they
use. If your applications aren't modularized at all then this is going
to be of limited value.

Mark

 

[steve]

Autodia will help you to analyse individual scripts and the modules they
use. If your applications aren't modularized at all then this is going
to be of limited value.

Mark

Hi Arun,
I'm working on something similar for testcases that have
dependancies on other testcases, build a graphical representation of
these dependancies

steve

 

[gf]

We have hundreds of perl scripts being used. It's hard to debug and
don't know the flow like which one is calling which. Is there any tool
that creates a flow chart like giving a visual view of multiple perl
scripts.

This is a messy solution, but you've already got a messy problem so it
can only help...

Write a bit of code to add a line to each of the Perl scripts that are
in your execution paths. Since you don't know for sure what's called
by what you need the line in all scripts.

That line needs to append a trace message to a single file that you
define using a date/time stamp and the name of the running program,
plus its passed in arguments. You might even want to dump the
environment too if you suspect there's significant information being
used there too.

Something like this (untested line) should work...

1 and open (my $__LOG, '>>', '/absolute/path/to/writable/log'),
print $__LOG scalar(localtime),"\t","$0 @ARGV\n",
close($__LOG);

(I wrapped the line to help it survive formatting by news browsers so
unwrap it into a single line.)

You can insert that line into your scripts by running something like
this untested and simplistic code...

#!/usr/bin/perl

use warnings;
use strict;

my $code = q{
1 and open (my $__LOG, '>>', '/absolute/path/to/writable/log'),
print $__LOG scalar(localtime),"\t$0 @ARGV\n",
close($__LOG);
};
foreach (@ARGV)
{
if ( open( my $FI, '<', $_ ) && open( my $FO, '>', "$_.new" ) )
{
while (<$FI>)
{
print $FO $code, "\n" if ( $. == 2 );
print $FO $_;
}
}
close $FO;
close $FI;
rename $_, "$_.old";
rename "$_.new", $_;
}

Then, as the application runs each script will update the log file
showing when they were called and what their parameters were.

You'll have a starting point to track down the execution flow then.

As you get things figured out or don't want something writing to the
log, change the leading 1 to a 0 in the code files you understand and
that file will 'gnore the log statement.

Just be very aware that this can create a very large log file in a
very short time, depending on the activity and structure of the
overall application.

Greg

 

[blazar]

On Feb 23, 7:50 pm, (e-mail address removed) wrote:

Something like this (untested line) should work...

1 and open (my $__LOG, '>>', '/absolute/path/to/writable/log'),
print $__LOG scalar(localtime),"\t","$0 @ARGV\n",
close($__LOG); [snip]
As you get things figured out or don't want something writing to the
log, change the leading 1 to a 0 in the code files you understand and
that file will 'gnore the log statement.

1) At first I didn't understand the C<1 and> bit. In light of the
explanation above, I do. Yet I find it somehow confusing. People
generally use a C<DEBUG> constant set at the top of their scripts
instead. I understand that here the situation is slightly different,
because it's not a matter of debugging single scripts but a whole
bunch of them, and I see the usefluness of a simple "tag" to be
recognized and automatically changed. Anyway a thing like

use constant DEBUG => 1;

is also easy to find and replace with

use constant DEBUG => 0;

Alternatively one can use an environment variable, and even a mixed
approach like thus:

use constant DEBUG => $ENV{THIS_JOB_DEBUG};

So that she can turn it definitely on or off for individual scripts.

2) Your code as suggested won't work: a lexical variable is not
available in the same statement that defines it:

$ cat foo.pl
#!/usr/bin/perl

use strict;
use warnings;

1 and open (my $__LOG, '>>', '/absolute/path/to/writable/log'),
print $__LOG scalar(localtime),"\t","$0 @ARGV\n",
close($__LOG);

__END__

$ perl foo.pl
Global symbol "$__LOG" requires explicit package name at foo.pl line
7.
Global symbol "$__LOG" requires explicit package name at foo.pl line
8.
Execution of foo.pl aborted due to compilation errors.

Though you may convert it to something that *does* work:

if (DEBUG) {
open my $__LOG, '>>', '/absolute/path/to/writable/log'
or die "$!\n!";
print $__LOG scalar(localtime),"\t","$0 @ARGV\n",
}

3) In addition to your conceptually good suggestion, I don't know
*how* each script "calls" other ones, but the OP may want to "trap"
each of them by overloading some core functions or operators, if that
is possible.