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