This matter has already been resolved. Thank you for following up.
: TeamSolCO wrote:
:
: > To start, let me say this:
: > 1) I have both "Learning Perl 3rd Ed" and "Programming Perl 3rd Ed"
: > 2) I have read "Learning Perl 3rd Ed", and I use "Programming Perl 3rd Ed" as
reference.
: > 3) I have searched with Google for several key words related to my problem, but
the mass of junk I get back is not
: > helpful.
: > 4) The application source is roughly 450 lines long, and the FAQ for this list
asks users not to mass-post such
things,
: > otherwise I'd post it here en-masse for help.
: >
: > And, most importantly:
: > A) I didn't write the application I'm working on, I extended it (to a great deal)
using the same programming style
as
: > the original author (and other programmers before me), except that I've been
"cleaning up" the old code a great
deal.
: > B) I understand this application is quite old, probably written in Perl 4 days,
and shows no OO influence (was
: > originally written as a down-and-dirty utility script).
: >
: > That said, please do not assume that I am incompetent; I'm just frustrated. I've
been programming for more than 20
: > years, just not with Perl (no, I'm not a VB "programmer" -- my experience is
primarilly C).
: >
: > Now then, I've opened a can of worms by adding "use strict" and "use warnings" to
the source. Keep in mind that
this
: > application was running JUST FINE before doing this. I'm only trying to
'modernize' this old code. Having started
with
: > a couple screen-fulls of resulting errors, I'm down to just one: "Can't use an
undefined value as a symbol
: > reference..." The partucular block that causes this error is:
: >
: > sub close_fifo {
: > close($hndFIFO);
:
: Why is an old C programmer doing this? It is very clear that the function above
makes use of some variable $hndFIFO.
Where
: does this variable come from? How is it scoped and where is it initialized? You
know that these things should not be
left
: a mystery. Although Perl does not require formal function signatures, good structre
still calls for explicit passing
of
: arguments, and explicit declarations of identifiers being used.
:
: The interpreter is asking where this value gets its definition. You should give it
an answer.
:
: > }
: >
: > It's related open sub is:
: >
: > sub open_fifo {
: > close_fifo();
:
: Don't count on this filehandle being global. Most likely, in the course of cleaning
up other portions of the code,
you
: inadvertently declared the filehandle within some lexical scope. Don't try to
reverse that action, as it represent
: progress. Instead, trace the filehandle toits opening make sure it is declared
within an appropraite scope, and then
: explicitly store, and pass it so that it is available, properly defined, when needed.
:
: > # Make sure the $hndFIFO file is a pipe.
: > unless (-p $path_fifo) {
: > unlink($path_fifo);
: > system("mkfifo $path_fifo") or die("Can't mkfifo $path_fifo: $!");
: > chmod(0600, $path_fifo);
: > }
: >
: > # Open the $hndFIFO stream.
: > open($hndFIFO, "< $path_fifo") or die("Can't open $path_fifo: $!");
: > }
: >
: > and, at the top of this source, I have declared $hndFIFO (along with the log file
handle) using our as in:
: >
: > our ($hndLOG, $hndFIFO);
:
: Hard to say without looking at the source as a whole. Why not just call it
serindipity that this global declaration
failed,
: and try again using careful and well-though-out lexical scoping. If you have been
programming that long, you should
know
: that globals are poison seeds in code of any complexity.
:
: >
: >
: > Before applying the aforementioned pragmas, the FIFO handle was simply, FIFO.
There was no "our" declaration, at
all,
: > and the variable/handle name was not prefixed with the scalar $ indicator.
Everything worked at that time...
Clearly,
: > I'm trying to delcare the FIFO (and log file) file handles as global to the
application so that I can access them
freely
: > in several other subs. What do I need to do to satisfy the strict pragma, while
accomplishing my goal?
: >
: > Thanks!!
: >
: > - William Kimball
: > "Programming is an art-form that fights back!"
:
: Well, william, you are on the right track. Do not regret integrated error-detection
in your code. Work with the
messages
: it gives. It was obvious to me, without seeing any error messages, that there was
something funky about an identifier
: popping up out of thin air to be used in a function.
:
: For what its worth, Perl is more tolerant on this issue than I am. You may well be
able to address this issue by
specifying
: your intent to use the more-broadly-scoped value. Perl allows the redeclaration of
our variables within a scope, and
takes
: this as a signal to use the variable declared in the outer scope:
:
: sub close_fifo {
: our$hndFIFO;
: close($hndFIFO);
: }
:
: Whether that will be enough, I don't know. The error message reffered to a lack of
definition, not to improper
declaration,
: so you will have to trace through all code that addresses this global to see that it
is getting properly assigned, and
that
: no loose cannons are blowing it away before it gets used. That goes with the
territory when using globals.
:
: Joseph
:
:
: --
: To unsubscribe, e-mail: [EMAIL PROTECTED]
: For additional commands, e-mail: [EMAIL PROTECTED]
: <http://learn.perl.org/> <http://learn.perl.org/first-response>
:
:
:
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
