«

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

>>>>> "i" == iarunkumar <> writes:

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

--
Uri Guttman ------ -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Uri Guttman wrote:

>>>>>> "i" == iarunkumar <> writes:
>
> 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 wrote:

> Uri Guttman wrote:
>
>>>>>>> "i" == iarunkumar <> writes:
>>
>> 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)

Michele Dondi wrote:

> 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

wrote:
> 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

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

wrote:
> 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

On Feb 24, 7:46 pm, Mark Clements <mark.clementsREMOVET...@wanadoo.fr>
wrote:
> iarunku...@gmail.com wrote:
> > 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

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

steve

On Feb 23, 7:50 pm, iarunku...@gmail.com wrote:
> 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

On 26 Feb, 18:53, "gf" <greg.fergu...@icrossing.com> wrote:
> On Feb 23, 7:50 pm, iarunku...@gmail.com 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.