Well, start by parsing the .pm files for subs and build a list of them, then parse the .pl file looking for the sub names being used.

Even a simple /^\s*sub\s+(\w+)/ match to find the subs would get you 99% of the way there for most purposes. Then assemble a regex to match the sub names you found already and use that to search the main.pl for places the subs are used. Easy peasy.

sh
find $dir -name '*.pm' \
| xargs awk '/^[ \t]*sub[ \t]+[_a-z0-9]+/ { print $2 }' \
| xargs -I % fgrep --word-regexp % *.pm
[download]

Have you looked into using pre-existing cross-reference tools?

Searching Google for "xref for PHP" I got these hits that look interesting:

• http://phpxref.sourceforge.net/
• http://xref-lint.net/

I then searched for "PHP cross reference" to turn up these additional ones:

• http://phpcrossref.com/
• http://bertgarcia.com/php-cross-reference-library

It strikes me, though, that you may want a more general tool. OpenGrok comes to mind. So does LXR.

Hi Pajout

Of course. The code I'm faced with is PHP, but I think Perl is probably more suited to the tasks such as this where text parsing is involved, hence the post here.

The code I am looking at refactoring for a specific application is published open-source by Yubikey on Github, so the relevant files are as follows:

https://raw.githubusercontent.com/Yubico/yubikey-val/master/ykval-verify.php

https://raw.githubusercontent.com/Yubico/yubikey-val/master/ykval-common.php

https://raw.githubusercontent.com/Yubico/yubikey-val/master/ykval-synclib.php

So synclib and common are the libraries, and verify is the main file.

Wait! As fare as i understood you, you want to refactor PHP code using Perl, right?

If so please:

Read more... (589 Bytes)

Regards, Karl

«The Crux of the Biscuit is the Apostrophe»

...thanks. And, what output of that perl software do you expect?

Darn thing (searching for methods) is even more harder when a method name is a variable, possibly formed partially. Similarly problem is when subs are produced en masse or via AUTOLOAD.

Well, Perl gives you several different ways to “split a program into multiple modules,” and (especially when dealing with older, legacy applications) it can be hard to “usefully generalize” such things.   Instead of trying to go for a cross-referencing tool or any sort of “[automated] refactoring” tool ... instead of chasing seriously after what’s likely to be a white-rabbit ... I would simply look at each of the subs that are known to be provided by, say, lib1, and use “good ol’grep -iw” to chase-down occurrences, one at a time.   Look at the use lib1 statements ... do they specify qw(subroutine names)?   Is the lib1::subroutine nomenclature being used?

And, finally but most-importantly, “where and how does it hurt?”   If you decided that you only had time and resources to commit to changing 20% of the occurrences, which 20% would it be, and why?

“Refactoring” kinda makes me nervous, like the billboards that I see advertising “iLipo-suction.”   The billboards always feature a curvaceous model who obviously never required liposuction in her life, and promise that the procedure can be done “without downtime.”   Well, I know of someone who died from liposuction:   merely putting an “i-” in front of it does not make it risk-free, nor painless.   And, likewise, I’ve seen some pretty-stable applications which became extremely unstable as a result of “refactoring” that sought to address an “issue” that, in the grand scheme, really didn’t exist.   I would suggest approaching the task very deliberately, and manually, bearing in mind that the task must include a comprehensive test-suite to prove both present-state and future-state.   Don’t attempt to refactor 100%.   Seek the 20% that can be shown to make 80% of the business difference with 5% of the risk.   Identify those pieces, and what you intend to do with them, and how you intend to prove the work, first.