a flash of inspiration...

I assume you "exit" your program when done.

why not use this instead:

# replace exit(0); with:
exit(close(DATA));

# or (at beginning of script)
sub exit_script {
  close(DATA);
  exit(0);
}

# then replace your exit calls with
exit_script;
[download]

timtowtdi though...

cLive ;-)

Comment on a flash of inspiration... Download Code

Replies are listed 'Best First'.
Re: a flash of inspiration... by Adam (Vicar) on Apr 05, 2001 at 01:29 UTC
Actually, no. I'm writing a module, and short of overloading CORE::exit I don't have control over the exit. That's also why I don't want <DATA> to show up in error messages. Why would the user of my module care if I'm reading the module's DATA? They wouldn't. On a side note, I'm not sure I understand your answer anyway. The problem isn't with exit, its with warn and die. Specifically, if you have an open filehandle then Perl mentions that when formating your error messages. That's one of the many good reasons to close filehandles when you are done with them, and to use IO::File which observes scope. (normal filehandles are global - although later versions of Perl allow you to scope them via my) My problem is that DATA is not a normal filehandle (as Ovid remembered above). I can't close it, because you can't open it. But once I've read from it, it shows up in error messages. So the question is, how do you keep it open for re-reading, without it showing up in error messages.	[reply]
Re: Re: a flash of inspiration... by cLive ;-) (Prior) on Apr 05, 2001 at 01:41 UTC
Am I missing something here? Is there any reason why you can't read in the data when the module is loaded, and assign it when you need to?!? ie: `package mod_name; { local $/; @mod_name::TableTemplate = map {chomp; hex} split ' ', <DATA>; close DATA; } my @Table = @mod_name::Table_Template;` [download] Or am I missing something completely obvious ?!? cLive ;-)	[reply] [d/l]
Re: Re: Re: a flash of inspiration... by Adam (Vicar) on Apr 05, 2001 at 01:51 UTC
wellllll.... (hem, haw) That would work. I could do that. But that doubles the memory requirements, requires an additional cost of copying the table the extra time. In most cases, you would be right. But in this case, what I need is to re-read the data section. That is the specific task on hand. You see, in the real world this routine would only get called once. But I want to Benchmark it. Thus the problem. Caching DATA like that would defeat the benchmark.	[reply]