PERL Miscellaneous - handle to /dev/null?

Author

handle to /dev/null?

peterkayatwork@yahoo.com

2005-09-20, 7:01 pm

Hi,

I want to be able to attempt to open a file handle on a file, and if it
fails, I would like to open a "/dev/null" filehandle as it were...

So, if it fails, I want this to produce no output:

print $filehandle "This should go nowhere\n";

No warnings would be nice too :) What's the best way to do this?

--Peter

A. Sinan Unur

2005-09-20, 7:01 pm

peterkayatwork@yahoo.com wrote in
news:1127257085.114202.61860@f14g2000cwb.googlegroups.com:

> Hi,
>
> I want to be able to attempt to open a file handle on a file, and if
> it fails, I would like to open a "/dev/null" filehandle as it were...
>
> So, if it fails, I want this to produce no output:
>
> print $filehandle "This should go nowhere\n";
>
> No warnings would be nice too :) What's the best way to do this?

What have you tried so far?

Is the 'obvious' solution good enough for you?

#!/usr/bin/perl
use strict;
use warnings;

use constant NULLFILE => 'NUL';

my $file;
open $file, '>', 'Z:/Test'
or open $file, '>', NULLFILE
or die "Cannot open: $!";

print $file "Hello World\n";

__END__

Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)

comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/c...guidelines.html

Fred@fred.net

2005-09-20, 7:01 pm

On 20 Sep 2005 15:58:05 -0700, peterkayatwork@yahoo.com wrote:

>Hi,
>
>I want to be able to attempt to open a file handle on a file, and if it
>fails, I would like to open a "/dev/null" filehandle as it were...
>
>So, if it fails, I want this to produce no output:
>
>print $filehandle "This should go nowhere\n";
>
>No warnings would be nice too :) What's the best way to do this?
>
>--Peter

See here Peter. Right off the bat you've broken at least 125 comp.lang.perl.misc rules.

You posted no code, this ain't a "write my code for me" service.

use strict;
use warnings;

my $var = "/dev/null";

open( FILE_HANDLE, $var ) or die("Cannot open file $var $!");

Snip

#Now why do you want to print to a filehandle you've opened on
#/dev/null?

print $filehandle "This should go nowhere\n";

You are printing something to no where. I don't know if the code above would work,
I'm stuck at home on windows, but ..... why send something no where at all?

Cheers and Best Regards,
Fred
Occasionally of fred.net

xhoster@gmail.com

2005-09-20, 9:59 pm

peterkayatwork@yahoo.com wrote:
> Hi,
>
> I want to be able to attempt to open a file handle on a file, and if it
> fails, I would like to open a "/dev/null" filehandle as it were...
>
> So, if it fails, I want this to produce no output:

Printing to a filehandle which is not open will produce no output, other
than optional warnings.

>
> print $filehandle "This should go nowhere\n";
>
> No warnings would be nice too :) What's the best way to do this?

Put
no warnings "unopened";

In the largest scope(s) which have all of the prints to this particular
file handle, but no prints to other file handles which you do want warnings
for.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Babacio

2005-09-21, 3:56 am

peterkayatwork@yahoo.com writes:

> Hi,
>
> I want to be able to attempt to open a file handle on a file, and if it
> fails, I would like to open a "/dev/null" filehandle as it were...
>
> So, if it fails, I want this to produce no output:
>
> print $filehandle "This should go nowhere\n";
>
> No warnings would be nice too :) What's the best way to do this?
>

Have a look on IO::Null, which allows you to link a file handle to a
bottomless sink.

use IO::Null;

open FILE, '>blop.txt' or tie(*FILE,IO::Null);
print FILE "Coucou\n";

This should work. A more elegant way to write it would be to use
IO::Null->new() but it seems that the package is quite buggy. Have a
look on the source and on a chapter about 'tie' in a perl book if you
whish to write something better.

--
Bé erre hue ixe eu elle, Bruxelles.

peterkayatwork@yahoo.com

2005-09-21, 6:59 pm

Thanks - this should suffice for me. I'm not on a unix system, so I
have no real /dev/null to write to...

But I figured out it's not "unopened" that I need, but "closed":

#!/usr/bin/perl
use warnings;
use strict;
no warnings "closed";

my ($f);

open($f, ">") or warn "Couldn't open nothing - won't print to it!\n";

print $f "No error message if 'no warnings \"closed\"'\n";

__END__

Thanks :)

--Peter
peterkayatwork (at) yahoo.com

peterkayatwork@yahoo.com

2005-09-21, 6:59 pm

> You posted no code, this ain't a "write my code for me" service.

Heh - I posted no real code because there wasn't any code to post. It
was still a theoretical question, not a "write this for me." Besides,
I did post some code that didn't do what I want:

print $filehandle "This should go nowhere\n";

Unfortunately, it produces a warning message...

> why send something no where at all?

Because I want to be able to print to the file handle without having to
worry about whether or not it opened successfully - I've got more than
one filehandle I'm printing to simultaneously. It would be more
troublesome to pull bad filehandles out of the array...

--Peter

Fred@fred.net

2005-09-21, 6:59 pm

On 21 Sep 2005 14:11:04 -0700, peterkayatwork@yahoo.com wrote:

>
>Heh - I posted no real code because there wasn't any code to post. It
>was still a theoretical question, not a "write this for me." Besides,
>I did post some code that didn't do what I want:
Your right I agree, I'm sorry I jumped the gun on that one.
Really disapointed in myself.
>
>print $filehandle "This should go nowhere\n";
>
>Unfortunately, it produces a warning message...
You might consider eval.
>
>
>Because I want to be able to print to the file handle without having to
>worry about whether or not it opened successfully - I've got more than
>one filehandle I'm printing to simultaneously.
>It would be more
>troublesome to pull bad filehandles out of the array...

We have an array of file handle names at this point?
Nothing wrong with that.
You could write a "wrapper" sub that calls open() and only
loads your array with the good filehandles. What would that be...
all the good calls to open()?
We don't want to print to a bad one right?

This all sounds kind of

. I considered that you might be trying for
a daemon process. As such you could send all output (file descriptors)
to /dev/null and have a well behaved daemon.
You obviously have something even more devious in mind.
>
>--Peter
Regards,
Fred

peterkayatwork@yahoo.com

2005-09-21, 9:56 pm

Fred said:
> You obviously have something even more devious in mind.

The real goal is to be able to parse a single log file in multilple
(and extensible) formats, so someone can see say, a markup with all the
details (and some extra ones added), or a filtered version with only
important information marked. Rather then read through the original
file multilple times, I want to handle all the formats line-by-line,
and output them simultaneously. Hence the array of file handles...
But I don't want to cut out an entire format if the output file can't
be opened, because I'm still interested in meta-data collected.

I'm going to go with an object representation that stores the
filehandles along with the filtering code; that way, I just loop
through the objects, pass them the log data and the object can deal
with its filehandle.

Unfortunately, it needs to run on Windows, so I have to worry about
file locking keeping output files from opening... I'd let it break if
it was just people write-protecting files :)

I don't know if that counts as "devious", but there it is!

--Peter
peterkayatwork (at) yahoo.com

Fred@fred.net

2005-09-23, 3:58 am

On 21 Sep 2005 17:15:47 -0700, peterkayatwork@yahoo.com wrote:

>Fred said:
>
>The real goal is to be able to parse a single log file in multilple
>(and extensible) formats, so someone can see say, a markup with all the
>details (and some extra ones added), or a filtered version with only
>important information marked. Rather then read through the original
>file multilple times, I want to handle all the formats line-by-line,
>and output them simultaneously. Hence the array of file handles...
>But I don't want to cut out an entire format if the output file can't
>be opened, because I'm still interested in meta-data collected.
>
>I'm going to go with an object representation that stores the
>filehandles along with the filtering code; that way, I just loop
>through the objects, pass them the log data and the object can deal
>with its filehandle.
>
>Unfortunately, it needs to run on Windows, so I have to worry about
>file locking keeping output files from opening... I'd let it break if
>it was just people write-protecting files :)
>
>I don't know if that counts as "devious", but there it is!
>
>--Peter
>peterkayatwork (at) yahoo.com
On 21 Sep 2005 17:15:47 -0700, peterkayatwork@yahoo.com wrote:

>Fred said:
Peter then opined:
I don't know if that counts as "devious", but there it is![color=darkred]
>
1. The real goal is to be able to parse a single log file.
2. in multilple and extensible formats.

3 (?)so someone can see say, a markup with all the
details (and some extra ones added), or a filtered version with only
important information marked.

What, are we going to grep some regex out of the file..
gotta do it by iteration. Linear.

4 (?) Rather then read through the original
file multilple times,
You only have to read it once. There is not another case.

5. (?)I want to handle all the formats line-by-line,
and output them simultaneously.
Hence the array of file handles...

Well it seems if #1 is true then certainly #2 can be, uhmm,
accomdated.

Right?

We’ll read the entire file, that single log file. We can slurp it,
if we dare, or we can read it line by line. It would seem if one were
interested in parsing Tag type elements from a log file a single pass
through the file would be sufficient in either of the file reading contexts.
Lists are after all terrible useful.

6 (?) But I don't want to cut out an entire format if the output file can't
be opened, because I'm still interested in meta-data collected.

I gotta confess, you lost me there on the meta-data part. Meta
data of what? The failed open/read on a file handle? And to what extent? OTOH.....

you did write some code.

You coded:

if the output file can't
be opened
don't print
else
print

I'm going to go with an object representation that stores the
filehandles along with the filtering code; that way, I just loop
through the objects, pass them the log data and the object can deal
with its filehandle.

That sounds great! I wish I knew more of OOP and perl.

Unfortunately, it needs to run on Windows, so I have to worry about
file locking keeping output files from opening... I'd let it break if
it was just people write-protecting files :)

I don't know if that counts as "devious", but there it is!

--Peter
peterkayatwork (at) yahoo.com

Peace.

peterkayatwork@yahoo.com

2005-09-26, 6:58 pm

Fred@fred.net wrote:
> What, are we going to grep some regex out of the file..

More or less. Except it's more complicated then a regex, and I want 3
or 4 different output files. And I want to be able to define a new way
to get output files on the fly.

> We'll read the entire file, that single log file. We can slurp it,
> if we dare, or we can read it line by line.

I'm a big fan of line-by-line. Works easier on my poor brain :)

> 6 (?) But I don't want to cut out an entire format if the output file can't
> be opened, because I'm still interested in meta-data collected.
>
> I gotta confess, you lost me there on the meta-data part. Meta
> data of what? The failed open/read on a file handle? And to what extent? OTOH.....

Ah, the meta-data would be how many lines got output to each file. Or
rather, the number of lines that matched each condition.

> That sounds great! I wish I knew more of OOP and perl.

Ha! Once you know more about OOP and Perl you start asking questions
like "How do I use a code-ref to an object in perl?"

No, seriously, read `perldoc perltoot` & you'll know enuf to at least
create/access objects in Perl. It's really a fabulous tutorial, and
fairly quick to read. And interesting, to boot.

--Peter

Sponsored Links