perldoc -f do, perldoc -f require, perldoc -f use. If you ask me, you are better off making B.pl a real module, but then if it's really called like that, then don't call it B.pm, since the latter already exists and is in core.
All in all it's hard to suggest you a good strategy without knowing what A.pl and B.pl really do. For sure what you're asking is awkward, as such, and most people will smell a XY Problem here.
| [reply]
[d/l]
[select] |
... and to add to this excellent advice, take a look at Including files in order to help you solve X
| [reply] |
In regards to question 2:
"Scoping" applies only within a single program; A.pl and B.pl are independent programs, so they have no variables in common. The only ways (of which I'm aware) to get information from one to the other are by environment variables (if, for example, B.pl is forked from A.pl), command line arguments, or some form of interprocess communication, such as pipes.
As pointed out by the prior respondents, you've got a couple of choices, depending on your application design: re-write B.pl as a module (with a nice, descriptive name that does not clobber a core module), rewrite A.pl to include the required functionality of B.pl, or re-write both to use some form of interprocess communication. This could be as simple as something like
A.pl ]arguments for A.pl] | B.pl [arguments for B.pl]
…but probably not.
update: fixed markup
emc
"Being forced to write comments actually improves code, because it is easier to fix a crock than to explain it. " —G. Steele
| [reply]
[d/l] |
I almost never have two Perl scripts calling each other. In most cases, either:
- (a) they are integrated closely enough that one (or both) should really be a module, and I end up instantiating one from the other (or a controller script) and calling its methods, or
- (b) they are independent enough that I have them both talk to a database or a file and trigger them independently by some external event.
Just my $0.02 worth ...
No good deed goes unpunished. -- (attributed to) Oscar Wilde
| [reply] |
