I have a strange situation on my hands. I have to use a set of Perl subroutines (coded by someone else) in my scripts. Now these subroutines are all *^&%* weird copyrighted stuff. Meaning I can copy them into my scripts (or call them or whatever) but I can not edit a bloody alphabet in them. Now this guy who wrote these subroutines had no sense of what strict is. So I have to break my strict rules to include them. What I am thinking of doing is this:

Thanks Larry and FishMonger. I like FishMonger's idea of rewriting that stuff especially since its not a very complex idea. But I might end in some legal trouble (its an algorithm which is probably patented). So I will not go there.

I am sure its not the -w sign which is the problem. I get the usual error if you forget a "my" when you use a variable the first time, "Global symbol $blahblah requires explicit package name in /path/to/script line 1245" (or something very similar).

I like the idea of creating a module in which I can insert the dirty subroutines intact. Since I am not really rewriting any of "their" code, I guess compiling should not be a problem. I will try that.

But here is something else. This guy actually opens a file handle in the main module and prints to it in other modules that he calls from the main module. Now I know that you can transfer references to file handles between subroutines. But that is not being done here. So that code goes like this

I had no clue this could be done. But I tried running just these modules separately and this works. Is this really allowed??? Or is this still allowed unofficially to cater for legacy code? These subroutines were written in 2002. I will appreciate a clarification.

As I said before the code works without errors even if you do not pass a reference to the file handle (refer code above). But it does not actually print to the file. Instead, it prints to the screen. So the code I posted above would output like below

Code

prompt:/> ./script.pl printing to FH in sub1 though it was opened in mainsub prompt:/>

to the screen instead of the file referred to by FH, filename.ext. The file itself will be created with a 0 bytes size (but this is expected since I legally opened and closed a file handle)

I would have expected Perl to throw a tantrum and stop or at the least complain before carrying on execution. But it does neither and mind that I have the -w switch in place. This is weird and should probably be a bug.

Thanks for thr reply. Nope! I just wrote a representative example. I don't think I can post the code I am using directly because it is *&^$&%&* copyrighted (as mentioned above) which is where the troubles in my life started in the first instance :-). Anyways this is a complete code example:

Move all of your "unstrict" code into a separate module, doing whatever you have to do to get it to compile, then "use" it in your "strict" program. I've tested this approach and it works.

In the end I did what you suggested. At least that saves me from seeing that code :-) Still have a knot in my tummy but I can live with that. You should have looked at the original code. It was terrible - syntax, readability, formatting, et al. I hope the guy who wrote it stopped coding in perl.

This will create a 0 bytes filename.ext and print the message to the screen. It is my personal opinion that this should at least elicit a warning from perl.

-AP

If that's true, then your perl installation is broken.

Other than using the -w switch, which you should not do, instead of the warnings pragma, that is the same as what I have already shown to work.

Please list, execute and post your example as I did.

Now, if you're saying that the actual production code, which obviously differs from the posted example, exhibits this behavior, then that is certainly possible. I can only help you troubleshoot the code you post.