On Tue, Nov 02, 2010 at 09:59:12PM -0400, Uri Guttman wrote:
why are you concerned about closing the DATA handle? it is internal to
the program. actually it is the handle the perl binary uses to read the
source file and it is left at the seek point where the DATA starts.
Because, I understand
On Wed, Nov 3, 2010 at 8:42 AM, Brian Reichert reich...@numachi.com wrote:
On Tue, Nov 02, 2010 at 09:59:12PM -0400, Uri Guttman wrote:
why are you concerned about closing the DATA handle? it is internal to
the program. actually it is the handle the perl binary uses to read the
source file and
On Wed, Nov 03, 2010 at 09:04:40AM -0700, Ben Tilly wrote:
What was wrong with the CPAN module Proc::Daemon?
Nothing; I have to admit, I didn't know it was there, until I was
largely done with what I had done. The internal module did not
have the original function of daemonizing, and had been
On Tue, Nov 02, 2010 at 09:59:12PM -0400, Uri Guttman wrote:
well, perl keeps it open so it can be used by anyone reading from
DATA. you can check for it specially with some code i got from
someone. it is special in that it is NOT tainted while all other handles
are.
Without delving further
Perhaps this all just illustrates a pile of bad assumptions I've
been making, but:
I have a perl app that daemonizes itself. Among it's daemonizing
efforts, it closes all file handles.
My app currently utilizes a third-party perl module, which in turn
makes use of the DATA file handle, as
BR == Brian Reichert reich...@numachi.com writes:
BR I have a perl app that daemonizes itself. Among it's daemonizing
BR efforts, it closes all file handles.
BR My app currently utilizes a third-party perl module, which in turn
BR makes use of the DATA file handle, as described in
