Can't use global FILEHANDLEs?

[Teamsolco]

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);
}

It's related open sub is:

sub open_fifo {
close_fifo();

# 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);


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!"

[Steve Grazzini]

TeamSolCO wrote:

> 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);
> }
>
> It's related open sub is:
>
> sub open_fifo {
> close_fifo();

When you call this the first time, you'll end up doing

close($hndFIFO = undef);

And strict won't let you dereference "undef" as a filehandle -- for
historical reasons, filehandles and glob/symbol references are more
equivalent than they should be, and that's why your error message is
complaining about a "symbol reference".

Now, if you're sure you need to close $hndFIFO before re-opening it,
you could do:

sub open_fifo {
close($hndFIFO) if defined $hndFIFO;

But it will get closed automatically when you re-open $hndFIFO, and
I think that should be sufficient.

--
Steve

[John W. Krahn]

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.

If you could post it somewhere where it can be downloaded, that would be
best.

> 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.

BTDT ... Loads 'O Fun.

> 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..."

Perl's warning/error messages are described in the perldiag.pod
document.

perldoc perldiag
[snip]
Can't use an undefined value as %s reference
(F) A value used as either a hard reference or a sym*
bolic reference must be a defined value. This helps
to delurk some insidious errors.

You can have perl print out these messages automatically if you add the
line "use diagnostics" to your program.

> The partucular block that causes this error is:
>
> sub close_fifo {
> close($hndFIFO);
> }
>
> It's related open sub is:
>
> sub open_fifo {
> close_fifo();
>
> # Make sure the $hndFIFO file is a pipe.
> unless (-p $path_fifo) {
> unlink($path_fifo);

You should check the return from unlink.

unlink $path_fifo or die "Cannot unlink $path_fifo: $!";

> system("mkfifo $path_fifo") or die("Can't mkfifo $path_fifo: $!");

system() returns true on failure and false on success so using 'or' will
cause it to die on success and the $! variable will not contain any
useful information as system() doesn't set $!. The system() entry in
perlfunc.pod describes this behaviour and the correct way to use
system().

perldoc -f system

But you could use the POSIX::mkfifo() instead.

use POSIX qw( mkfifo );

mkfifo $path_fifo or die "Can't mkfifo $path_fifo: $!";

> chmod(0600, $path_fifo);

You should check the return from chmod.

chmod 0600, $path_fifo or die "Cannot chmod $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);

Why use 'our' and not 'my'? Why use scalars and not filehandles?

> 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?

It is not clear from the snippet you provided what the problem is.
Sometimes errors are reported for the wrong line number. I know from
experience that converting Perl4 code to Perl5 can at times be quite
challenging. It would help a lot to see the original Perl4 code.



John
--
use Perl;
program
fulfillment

[Rob Dixon]

"Teamsolco" <teamsolco@teamdelsol.com> wrote in message news:002b01c3e77c$af51cb00$1000090a@ryoga...

> 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);
> }
>
> It's related open sub is:
>
> sub open_fifo {
> close_fifo();
>
> # 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);
>
>
> 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!"
>
>

[Rob Dixon]

Sorry - bad click.

/R

[Teamsolco]

Awesome. This tip cleared the problem right up; thanks for explaining it!

----- Original Message -----
From: "Steve Grazzini" <grazz@pobox.com>
To: "TeamSolCO" <teamsolco@teamdelsol.com>
Cc: "Perl Beginners List" <beginners@perl.org>
Sent: Friday, January 30, 2004 3:26 PM
Subject: Re: Can't use global FILEHANDLEs?


: TeamSolCO wrote:
: > 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);
: > }
: >
: > It's related open sub is:
: >
: > sub open_fifo {
: > close_fifo();
:
: When you call this the first time, you'll end up doing
:
: close($hndFIFO = undef);
:
: And strict won't let you dereference "undef" as a filehandle -- for
: historical reasons, filehandles and glob/symbol references are more
: equivalent than they should be, and that's why your error message is
: complaining about a "symbol reference".
:
: Now, if you're sure you need to close $hndFIFO before re-opening it,
: you could do:
:
: sub open_fifo {
: close($hndFIFO) if defined $hndFIFO;
:
: But it will get closed automatically when you re-open $hndFIFO, and
: I think that should be sufficient.
:
: --
: Steve
:
:

[Teamsolco]

: > 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.
: If you could post it somewhere where it can be downloaded, that would be
: best.

I'll consider that, but people interested will have to be willing to sort through a mess of Perl4/5 migratory code
(which changes every time I get into it). Unless anyone volunteers, I'll just post the offending segments as-needed.
Thanks, though.

: > 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.
: BTDT ... Loads 'O Fun.

You're not kidding. When I'm stronger with Perl, I'll be sure to author original solutions in the future.

: > 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..."
:
: Perl's warning/error messages are described in the perldiag.pod
: document.
:
: You can have perl print out these messages automatically if you add the
: line "use diagnostics" to your program.

I wasn't aware of the benefit of "use diagnostics", which has turned out quite useful. Thanks!

: > The partucular block that causes this error is:
:
: You should check the return from unlink.
: system() returns true on failure and false on success so using 'or' will
: cause it to die on success and the $! variable will not contain any
: useful information as system() doesn't set $!. The system() entry in
: perlfunc.pod describes this behaviour and the correct way to use
: system().
: You should check the return from chmod.

I'm sure I read it somewhere, but I had forgotten about the qwirky system() return. Based on your recommendation, I
have fully rewritten that (and similar) segment of code to be more sensitive to failure (useless $! values will just
come with the territory):

unless ((unlink($path_fifo)) && ((system("mkfifo $path_fifo")) || (chmod(0600, $path_fifo)))) {
die("Cannot initialize $path_fifo: $!");
}

: > our ($hndLOG, $hndFIFO);
:
: Why use 'our' and not 'my'? Why use scalars and not filehandles?

I'm using 'our' because the objective is to use it globally through the application's many subs. The compiler forced me
to use scalars by throwing a "Cannot use constants..." type error when attempting to use the traditional, 'HNDFIFO' and
'HNDLOG' variable names in "our (HNDFIFO, HNDLOG);" fashion. What I have now is working. Do you have a better
recommendation?

: > 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?
:
: It is not clear from the snippet you provided what the problem is.
: Sometimes errors are reported for the wrong line number. I know from
: experience that converting Perl4 code to Perl5 can at times be quite
: challenging. It would help a lot to see the original Perl4 code.

There isn't much left of the original Perl4 code, aside from its legacy present in the resulting hodge-podge conversion,
but thanks.

[John W. Krahn]

Teamsolco wrote:

>
> : You should check the return from unlink.
> : system() returns true on failure and false on success so using 'or' will
> : cause it to die on success and the $! variable will not contain any
> : useful information as system() doesn't set $!. The system() entry in
> : perlfunc.pod describes this behaviour and the correct way to use
> : system().
> : You should check the return from chmod.
>
> I'm sure I read it somewhere, but I had forgotten about the qwirky
> system() return. Based on your recommendation, I have fully rewritten
> that (and similar) segment of code to be more sensitive to failure

? (useless $! values will just come with the territory):

>
> unless ((unlink($path_fifo)) && ((system("mkfifo $path_fifo")) || (chmod(0600, $path_fifo)))) {
> die("Cannot initialize $path_fifo: $!");
> }

You are still not going to get the correct error message from system()
as it doesn't set $!. If you use POSIX::mkfifo() this will work
correctly. As an aside, I dislike using excess parenthesis (this is not
Lisp!)

use POSIX 'mkfifo';

die "Cannot initialize $path_fifo: $!"
unless unlink $path_fifo and mkfifo $path_fifo and chmod 0600,
$path_fifo;

> : > our ($hndLOG, $hndFIFO);
> :
> : Why use 'our' and not 'my'? Why use scalars and not filehandles?
>
> I'm using 'our' because the objective is to use it globally through the
> application's many subs. The compiler forced me to use scalars by
> throwing a "Cannot use constants..." type error when attempting to use
> the traditional, 'HNDFIFO' and 'HNDLOG' variable names in "our (HNDFIFO,
> HNDLOG);" fashion. What I have now is working. Do you have a better
> recommendation?

Perl's filehandles are "global". Unless you are using packages,
filehandles, like directory handles, subroutine names, labels, etc. are
globally accessible. our() just lets you create "global" scalars,
arrays and hashes when strict is in use and it has the same scoping
rules as my(). So, to summarize, "use strict" requires you to declare
all scalars, arrays and hashes with my() or our() which both enforce the
same block or file scoping rules. Without "use strict" all scalars,
arrays and hashes which are not declared with my() or our() are scoped
to the current package. All variables that are not scalars, arrays or
hashes are package scoped. Since filehandles are neither scalars,
arrays or hashes you cannot declare them with my() or our(). If Perl's
standard filehandles were working before then you obviously are not
using packages so using "global" scalars instead does not really provide
any benefits IMHO. :-)

> : It is not clear from the snippet you provided what the problem is.
> : Sometimes errors are reported for the wrong line number. I know from
> : experience that converting Perl4 code to Perl5 can at times be quite
> : challenging. It would help a lot to see the original Perl4 code.
>
> There isn't much left of the original Perl4 code, aside from its legacy
> present in the resulting hodge-podge conversion, but thanks.

You mean you don't use CVS so you can undo any fatal changes? :-)


John
--
use Perl;
program
fulfillment

[John McKown]

On Sat, 31 Jan 2004, John W. Krahn wrote:

<snip>

> use POSIX 'mkfifo';
>
> die "Cannot initialize $path_fifo: $!"
> unless unlink $path_fifo and mkfifo $path_fifo and chmod 0600,
> $path_fifo;
>

Just one, very minor "improvement", of the above might be:

die "Cannot initialize $path_fifl: $!"
unless unlink $path_fifo and mkfifo($path_info,0600);

Granted, this is a nit, but if in a loop which executes a million times,
it could add up. I guess that I've been on "CPU constrained" systems for
so long that every millisecond is now precious <grin>.

--
Maranatha!
John McKown

[Teamsolco]

: > I'm sure I read it somewhere, but I had forgotten about the qwirky
: > system() return. Based on your recommendation, I have fully rewritten
: > that (and similar) segment of code to be more sensitive to failure
: ? (useless $! values will just come with the territory):
: >
: > unless ((unlink($path_fifo)) && ((system("mkfifo $path_fifo")) || (chmod(0600, $path_fifo)))) {
: > die("Cannot initialize $path_fifo: $!");
: > }
:
: You are still not going to get the correct error message from system()
: as it doesn't set $!. If you use POSIX::mkfifo() this will work
: correctly. As an aside, I dislike using excess parenthesis (this is not
: Lisp!)

Thanks for bringing this up. I'm not especially familiar with POSIX as it is only lightly mentioned in "Learning Perl,
3rd Ed". Consequently, I haven't been interested in researching it further. Also, remember that I'm working with
someone else's code. They used system(), so I'm just running with it. Because of that, as I explained, not getting a
useful value in $! just comes with the territority. As for the parenthesis, that is an established technique (but,
aren't we stepping away from the problem to discuss theory and style?). It's a control thing you pick up with as many
years of C behind you as me -- it greatly improves predictibility, which helps debug far more quickly than when you are
solely at the mercy of precedence (in my experience).

: > I'm using 'our' because the objective is to use it globally through the
: > application's many subs. The compiler forced me to use scalars by
: > throwing a "Cannot use constants..." type error when attempting to use
: > the traditional, 'HNDFIFO' and 'HNDLOG' variable names in "our (HNDFIFO,
: > HNDLOG);" fashion. What I have now is working. Do you have a better
: > recommendation?
:
: Perl's filehandles are "global". Unless you are using packages,
: filehandles, like directory handles, subroutine names, labels, etc. are
: globally accessible. our() just lets you create "global" scalars,
: arrays and hashes when strict is in use and it has the same scoping
: rules as my(). So, to summarize, "use strict" requires you to declare
: all scalars, arrays and hashes with my() or our() which both enforce the
: same block or file scoping rules. Without "use strict" all scalars,
: arrays and hashes which are not declared with my() or our() are scoped
: to the current package. All variables that are not scalars, arrays or
: hashes are package scoped. Since filehandles are neither scalars,
: arrays or hashes you cannot declare them with my() or our(). If Perl's
: standard filehandles were working before then you obviously are not
: using packages so using "global" scalars instead does not really provide
: any benefits IMHO. :-)

Again, as a seasoned C programmer: If I don't painstakingly declare a variable and it's scope, then I'm not in control
of it. Lack of control leads to unpredictable results. I'm not willing to accept such haphazzard conditions because
debugging isn't my idea of a good use of my time. I did try, at first, to run with the filehandles undeclared as this,
but the compiler threw errors about the symbols being unresolved in other subs outside the one issuing the open(). In
reaction to the errors, I resorted to my old-school techniques.

: > There isn't much left of the original Perl4 code, aside from its legacy
: > present in the resulting hodge-podge conversion, but thanks.
:
: You mean you don't use CVS so you can undo any fatal changes? :-)

I'll be blunt: I'm not familiar with 'CVS'. If this is an equivalent to source code/version control (which I am very
familiar with, under different names), then it would be overkill for such a minor, single-source project. Any changes I
make to this ~450 line application are easily fixed or undone, if necessary. Thanks, though.

In any event, the application is running very well now. Thank you for your help. I will not respond further to issues
regarding this thread.

[R. Joseph Newton]

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

[Rob Dixon]

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);
> }
>
> It's related open sub is:
>
> sub open_fifo {
> close_fifo();
>
> # 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);
>
>
> 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?

I think you need to rant a little less. You've spent most of the post
telling us how great you and youre achievements are and how awful the
rest of the world is. If you really have twenty years' experience how
come you have little idea what to do next?

Rob

[Teamsolco]

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]beginners-unsubscribe@perl.org[/email]
: For additional commands, e-mail: [email]beginners-help@perl.org[/email]
: <http://learn.perl.org/> <http://learn.perl.org/first-response>
:
:
: