Again, you should use all strictures. use strict 'vars'; limits strict checking. use strict; is what you want.
The code change that I gave you for printout() is correct. printout()won't work without that change. Past that, the problem is how you call printout().
You cannot pass a simple bareword file handle like STDOUT as a parameter.
Bareword filehandles are global in scope and don't need to be passed as parameters because they are known everywhere, in all subroutines.
If you want to pass filehandles as a parameter, you should use lexically scoped filehandles (using "my") which can be passed as parameters.
Also as a style rule, whatever level of the program opens a file, that level should be responsible for closing it.
In your case, I would
move the opening of the Lumber File up to the main program level.
There is no need to ever create the "bareword filehandle, LH". Start off by creating a lexical filehandle to begin with and you don't have to worry about "translating" bareword to normal variable.
printout() is not needed. A single line suffices and is more clear.my $LumberFile="$Dir/$Subdir/lumber.wrl"; open my $Lumber_fh, '<', $LumberFile or warn "Ooops Cannot Open Lumbe +r File: $LumberFile !! \n Proceeding using STDOUT"; my $out_fh = *STDOUT unless (defined $Lumber_fh); ... As a style point, I add "_fh" ("filehandle") as a suffix to remind myself that this variable is a filehandle and not some integer or other thing. The "*" in front of STDOUT is critical! This allows the "translation" of the bareword filehandle STDOUT into the lexical program variable "my $out_fh". Without that, Perl figures that STDOUT is a string. Now you can pass $out_fh as a parameter to other subs or use it yourself, e.g. print $out_fh "something";
Update:
The error processing above is rather crude and I don't recommend it. In general, if there is a directory path that is supposed to be the "output file" and you can't open it, you should "die" and await changes to that filename/permissions. Normally you would not keep going and "waste" what might potentially be a significant computation effort. I would treat a null string $LumberFile name and non-null string $LumberFile differently.
You might find amusing: A long time ago, when I was working with IBM mainframes, we had a job that ran for 5 days straight. That did not alarm us. We expected that. The unexpected part came when program abended due to a simple JCL (Job Control Language) error before writing the result to a magnetic tape. We had about 16 tape drives on that machine and it would have been completely fine for the program to "open" one of the drives for 5 days and hang on to it. The coding error that involved acquiring a tape drive for output wasn't apparent until after 5 days of number crunching! We lost 5 days of computing, the cost of which was not insignificant. So, in general I would open the output file before I had calculated some result to output to it.
In reply to Re^3: Filehandle in subroutine in use VRML.pm
by Marshall
in thread Filehandle in subroutine in use VRML.pm
by smittypaddler
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |