: > 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.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
