[31323] in Perl-Users-Digest
Perl-Users Digest, Issue: 2568 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 24 06:09:43 2009
Date: Mon, 24 Aug 2009 03:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 24 Aug 2009 Volume: 11 Number: 2568
Today's topics:
Drug agents raid Beverly Hills pharmacy in Jackson prob <asim.ssat@gmail.com>
Ekta to chant Gayatri Mantra for Miss Universe <asim.ssat@gmail.com>
Re: Possibly useful perl script to filter lines in one sln@netherlands.com
Re: Possibly useful perl script to filter lines in one <tadmc@seesig.invalid>
Re: Possibly useful perl script to filter lines in one (Tim McDaniel)
Re: Possibly useful perl script to filter lines in one sln@netherlands.com
Re: Possibly useful perl script to filter lines in one <nat.k@gm.ml>
Re: Possibly useful perl script to filter lines in one sln@netherlands.com
Re: Possibly useful perl script to filter lines in one <mvdwege@mail.com>
Re: Possibly useful perl script to filter lines in one <nat.k@gm.ml>
Re: Possibly useful perl script to filter lines in one sln@netherlands.com
Re: Possibly useful perl script to filter lines in one sln@netherlands.com
Re: Possibly useful perl script to filter lines in one sln@netherlands.com
Re: Possibly useful perl script to filter lines in one <mvdwege@mail.com>
Re: Possibly useful perl script to filter lines in one sln@netherlands.com
Re: Possibly useful perl script to filter lines in one <mvdwege@mail.com>
Re: Preventing lines from printing (Tim McDaniel)
Re: Preventing lines from printing <uri@StemSystems.com>
Re: Preventing lines from printing <dot@dot.dot>
Printing only on a match <dot@dot.dot>
Re: windows one liner to output unix line feed sln@netherlands.com
Re: windows one liner to output unix line feed sln@netherlands.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 23 Aug 2009 18:45:24 -0700 (PDT)
From: asim malik <asim.ssat@gmail.com>
Subject: Drug agents raid Beverly Hills pharmacy in Jackson probe
Message-Id: <997e5f3c-18e0-4826-a49f-975378b4d225@s6g2000vbp.googlegroups.com>
LOS ANGELES : US federal drug agents raided a Beverly Hills pharmacy
as part of an ongoing investigation into
www.nfa786.blogspot.com
------------------------------
Date: Sun, 23 Aug 2009 18:37:48 -0700 (PDT)
From: asim malik <asim.ssat@gmail.com>
Subject: Ekta to chant Gayatri Mantra for Miss Universe
Message-Id: <478c4f37-4d74-4e49-8428-2fe90ad18e0c@k26g2000vbp.googlegroups.com>
Talking exclusively to TOI, Rita says, =91I spoke to Ekta sometime back
today; she was a little tired and was planning to get some sleep as
she gets hardly www.nfa786.blogspot.com
------------------------------
Date: Sun, 23 Aug 2009 19:41:13 -0700
From: sln@netherlands.com
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <e0v3955j4v6k9hpipt8j59mfca7eep9kt4@4ax.com>
On Sun, 23 Aug 2009 17:27:13 -0700, Nathan Keel <nat.k@gm.ml> wrote:
>sln@netherlands.com wrote:
>
>> On Sun, 23 Aug 2009 14:37:45 -0500, Tad J McClellan
>> <tadmc@seesig.invalid> wrote:
>>
>>>Ben Burch <benburch@pobox.com> wrote:
>>>
>>>> #!/usr/bin/perl
>>>
>>> use warnings;
>>> use strict;
>>>
>>>> open (EXCLUDE, $file2);
>>>
>>>You should always, yes *always*, check the return value from open():
>>>
>>> open my $EXCLUDE, '<', $file2 or die "could not open '$file2' $!";
>>>
>>>> while ($line = <EXCLUDE>)
>>>
>>> while ($line = <$EXCLUDE>)
>>>
>>>> if(!exists($exclude{$line}))
>>>
>>> unless ( exists $exclude{$line} )
>>>
>>>or at least make wise use of whitespace and punctuation:
>>>
>>> if ( ! exists $exclude{$line} )
>>
>> Hi Tad.
>>
>> I've seen that always check the return value of open
>> here on this NG, then die if not true?
>>
>> Why die if open didn't die? Whats the worse thing that can happen?
>> I think the worse thing is that a read or write doesen't happen.
>> It won't crash the system or mess up the file allocation tables.
>>
>> Its funny, if you pass a failed open filehandle like
>> open my $fh, 'non-existant-file.txt'
>> to a read $fh,... the read passivily fails. There is no
>> fatal error.
>>
>> But if you pass an undefined filehandle to read, it
>> die's.
>>
>> Something to consider since a failed open does not really
>> cause problems because and apparently an undefined handle is
>> enough to cause a die from Perl's i/o functions (well at least read ).
>>
>> So, why is it always, yes always, necessary to check the return
>> value from open() ?
>>
>> -sln
>
>If you want to open/read/write to a file, there's an intended reason.
>It doesn't have to be a die, the point is to be aware of the problem
>and have it output or log the problem, which helps troubleshoot
>problems (and unintended bugs). He said to always check the return
>value, he didn't say to always die. If you have a script that doesn't
>need to open a file you told it to, why are you opening it?
I used to work for a company that did a lot of automation using perl.
I was new to Perl, but was hired because of my c++ background, but
ended up having to do all perl.
Looking back on it, thier motto was don't die on anything, do not stop
the automation.
The entire environment was dynamically generated. There was not a die
anywhere in any line of code. The check for existence is fine, but you
can't wrap all your other code in if's all the time. Definetly logs though,
lots of them, on the chance something didn't work.
They could have used something like this, though they didn't have it.
use strict;
use warnings;
my ($buf,$length) = ('',5);
# Invoke error #1, NON - FATAL error on read.
# File doesen't exist, however, $fh is valid
open my $fh, '<', 'notexists.txt';
# Invoke error #2, FATAL error on read
#my $fh;
open STDERR, '>errors.txt';
{
local $!;
my $status = eval { read ($fh, $buf, $length) };
$@ =~ s/\s+$//;
if ($@ || (!$status && $!)) {
print "Error in read: ". ($@ ? $@ : $! ). "\n";
}
}
print "More code ...\n";
exit;
__END__
-sln
------------------------------
Date: Sun, 23 Aug 2009 22:22:19 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <slrnh94199.d8a.tadmc@tadmc30.sbcglobal.net>
sln@netherlands.com <sln@netherlands.com> wrote:
> On Sun, 23 Aug 2009 14:37:45 -0500, Tad J McClellan <tadmc@seesig.invalid> wrote:
>>You should always, yes *always*, check the return value from open():
> I've seen that always check the return value of open
> here on this NG,
It's been said often enough.
> then die if not true?
No, then do "whatever is appropriate for your situation".
The admonition is to check the return value.
It is not to take any particular action if the check fails, though
die is often used, as it is most often the appropriate action.
(the purpose of most programs is to process a file's
contents, so there is no point in continuing if such a program
cannot read the file's contents.
)
> Why die if open didn't die?
open() does not die, if it fails it fails silently (which is why
you should always, yes *always*, check its return value).
So I don't know what you mean.
Show me some code where an open() dies...
> Whats the worse thing that can happen?
You silently get the wrong output and wonder what went wrong.
> But if you pass an undefined filehandle to read, it
> die's.
No it doesn't.
Show me a program where you pass an undefined filehandle to read
and it dies...
> Something to consider since a failed open does not really
> cause problems
It does if the purpose of the program is to process that file.
> So, why is it always, yes always, necessary to check the return
> value from open() ?
So that it will fail noisily rather than fail silently!
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Mon, 24 Aug 2009 03:41:34 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <h6t25e$n42$1@reader1.panix.com>
In article <slrnh94199.d8a.tadmc@tadmc30.sbcglobal.net>,
Tad J McClellan <tadmc@seesig.invalid> wrote:
>sln@netherlands.com <sln@netherlands.com> wrote:
>> On Sun, 23 Aug 2009 14:37:45 -0500, Tad J McClellan <tadmc@seesig.invalid> wrote:
>
>>>You should always, yes *always*, check the return value from open():
>
>> I've seen that always check the return value of open
>> here on this NG,
...
>> Whats the worse thing that can happen?
>
>You silently get the wrong output and wonder what went wrong.
That's bad, but I think the worst is that you get the wrong output and
DON'T notice (and therefore don't wonder). Instead, you work with bad
or missing data.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 23 Aug 2009 21:30:06 -0700
From: sln@netherlands.com
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <bi54959htmid2e985fmui1351rt4lc053s@4ax.com>
On Sun, 23 Aug 2009 22:22:19 -0500, Tad J McClellan <tadmc@seesig.invalid> wrote:
>sln@netherlands.com <sln@netherlands.com> wrote:
>> On Sun, 23 Aug 2009 14:37:45 -0500, Tad J McClellan <tadmc@seesig.invalid> wrote:
>
>>>You should always, yes *always*, check the return value from open():
>
>> I've seen that always check the return value of open
>> here on this NG,
>
>
>It's been said often enough.
>
>
>> then die if not true?
>
>
>No, then do "whatever is appropriate for your situation".
>
>The admonition is to check the return value.
>
>It is not to take any particular action if the check fails, though
>die is often used, as it is most often the appropriate action.
>
>(the purpose of most programs is to process a file's
> contents, so there is no point in continuing if such a program
> cannot read the file's contents.
>)
>
>> Why die if open didn't die?
>
>
>open() does not die, if it fails it fails silently (which is why
>you should always, yes *always*, check its return value).
>
>So I don't know what you mean.
>
>Show me some code where an open() dies...
>
Yeah, show me, so why die?
>
>> Whats the worse thing that can happen?
>
>
>You silently get the wrong output and wonder what went wrong.
>
>
>> But if you pass an undefined filehandle to read, it
>> die's.
>
>
>No it doesn't.
>
>Show me a program where you pass an undefined filehandle to read
>and it dies...
>
use strict;
use warnings;
my ($buf,$length) = ('',5);
# Invoke error #2, FATAL error on read
my $fh;
{
local $!;
my $status = eval { read ($fh, $buf, $length) };
$@ =~ s/\s+$//;
if ($@ || (!$status && $!)) {
print "Error in read: ". ($@ ? $@ : $! ). "\n";
}
}
print "More code ...\n";
__END__
c:\temp>perl ss.pl
Error in read: Can't use an undefined value as a symbol reference at ss.pl line
13.
More code ...
c:\temp>
>
>> Something to consider since a failed open does not really
>> cause problems
>
>
>It does if the purpose of the program is to process that file.
>
Not if its a juggernaught program that isin't allowed to die.
Aka automation
>
>> So, why is it always, yes always, necessary to check the return
>> value from open() ?
>
>
>So that it will fail noisily rather than fail silently!
Fail all you want, but please don't die...
-sln
------------------------------
Date: Sun, 23 Aug 2009 21:36:49 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <BNokm.90427$nL7.82795@newsfe18.iad>
sln@netherlands.com wrote:
>
> I used to work for a company that did a lot of automation using perl.
> I was new to Perl, but was hired because of my c++ background, but
> ended up having to do all perl.
> Looking back on it, thier motto was don't die on anything, do not stop
> the automation.
> The entire environment was dynamically generated. There was not a die
> anywhere in any line of code. The check for existence is fine, but you
> can't wrap all your other code in if's all the time. Definetly logs
> though, lots of them, on the chance something didn't work.
I'm not suggesting any code needs to die. I'm also not suggesting every
read is vital and can't be ignored. Just for the record.
------------------------------
Date: Sun, 23 Aug 2009 23:11:19 -0700
From: sln@netherlands.com
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <alb495ltndu0kflb1rqq3ab79d58pkd3i6@4ax.com>
On Mon, 24 Aug 2009 03:41:34 +0000 (UTC), tmcd@panix.com (Tim McDaniel) wrote:
>In article <slrnh94199.d8a.tadmc@tadmc30.sbcglobal.net>,
>Tad J McClellan <tadmc@seesig.invalid> wrote:
>>sln@netherlands.com <sln@netherlands.com> wrote:
>>> On Sun, 23 Aug 2009 14:37:45 -0500, Tad J McClellan <tadmc@seesig.invalid> wrote:
>>
>>>>You should always, yes *always*, check the return value from open():
>>
>>> I've seen that always check the return value of open
>>> here on this NG,
>...
>>> Whats the worse thing that can happen?
>>
>>You silently get the wrong output and wonder what went wrong.
>
>That's bad, but I think the worst is that you get the wrong output and
>DON'T notice (and therefore don't wonder). Instead, you work with bad
>or missing data.
In reality, you should never need to check the return value from open().
If you can't program to that spec, you haven't been paid to program.
-sln
------------------------------
Date: Mon, 24 Aug 2009 08:41:06 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <864orxlnnh.fsf@gareth.avalon.lan>
sln@netherlands.com writes:
> On Sun, 23 Aug 2009 22:22:19 -0500, Tad J McClellan <tadmc@seesig.invalid> wrote:
<snip>
>>
>>Show me a program where you pass an undefined filehandle to read
>>and it dies...
>>
> use strict;
> use warnings;
>
> my ($buf,$length) = ('',5);
>
> # Invoke error #2, FATAL error on read
> my $fh;
>
> {
> local $!;
> my $status = eval { read ($fh, $buf, $length) };
> $@ =~ s/\s+$//;
> if ($@ || (!$status && $!)) {
> print "Error in read: ". ($@ ? $@ : $! ). "\n";
> }
> }
>
> print "More code ...\n";
>
> __END__
> c:\temp>perl ss.pl
> Error in read: Can't use an undefined value as a symbol reference at ss.pl line
> 13.
Your program is not dying on an undefined filehandle. It is dying on an
undefined scalar. This is not the same.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Sun, 23 Aug 2009 23:46:06 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <OGqkm.151440$0e4.60998@newsfe19.iad>
sln@netherlands.com wrote:
>
> In reality, you should never need to check the return value from
> open(). If you can't program to that spec, you haven't been paid to
> program. -sln
To say one should never need to check the return value (rather than
arguing about die'ing), just shows how unqualified you are as an
alleged programmer. No one is suggesting to not check other things,
but checking that a file opened is sometimes useful or needed. If you
don't recognize or admit that, then you are a complete failure at
simple programming logic.
------------------------------
Date: Mon, 24 Aug 2009 00:06:09 -0700
From: sln@netherlands.com
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <7te4959htmid2e985fmui1351rt4lc05kp@4ax.com>
On Mon, 24 Aug 2009 08:41:06 +0200, Mart van de Wege <mvdwege@mail.com> wrote:
>sln@netherlands.com writes:
>
>> On Sun, 23 Aug 2009 22:22:19 -0500, Tad J McClellan <tadmc@seesig.invalid> wrote:
><snip>
>>>
>>>Show me a program where you pass an undefined filehandle to read
>>>and it dies...
>>>
>> use strict;
>> use warnings;
>>
>> my ($buf,$length) = ('',5);
>>
>> # Invoke error #2, FATAL error on read
>> my $fh;
>>
>> {
>> local $!;
>> my $status = eval { read ($fh, $buf, $length) };
>> $@ =~ s/\s+$//;
>> if ($@ || (!$status && $!)) {
>> print "Error in read: ". ($@ ? $@ : $! ). "\n";
>> }
>> }
>>
>> print "More code ...\n";
>>
>> __END__
>> c:\temp>perl ss.pl
>> Error in read: Can't use an undefined value as a symbol reference at ss.pl line
>> 13.
>
>Your program is not dying on an undefined filehandle. It is dying on an
>undefined scalar. This is not the same.
>
>Mart
Your wrong, its die'ing in runtime, function call 'read()'
-sln
------------------------------
Date: Mon, 24 Aug 2009 00:08:25 -0700
From: sln@netherlands.com
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <82f495poadotnovh0b17cpfp5ckvi6f1p4@4ax.com>
On Sun, 23 Aug 2009 23:46:06 -0700, Nathan Keel <nat.k@gm.ml> wrote:
>sln@netherlands.com wrote:
>
>>
>> In reality, you should never need to check the return value from
>> open(). If you can't program to that spec, you haven't been paid to
>> program. -sln
>
>To say one should never need to check the return value (rather than
>arguing about die'ing), just shows how unqualified you are as an
>alleged programmer. No one is suggesting to not check other things,
>but checking that a file opened is sometimes useful or needed. If you
>don't recognize or admit that, then you are a complete failure at
>simple programming logic.
Its too simple in that logic.
-sln
------------------------------
Date: Mon, 24 Aug 2009 00:29:44 -0700
From: sln@netherlands.com
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <v7g4955bhikijiepkgah0ijv3inhd3e11t@4ax.com>
On Mon, 24 Aug 2009 00:06:09 -0700, sln@netherlands.com wrote:
>On Mon, 24 Aug 2009 08:41:06 +0200, Mart van de Wege <mvdwege@mail.com> wrote:
>
>>sln@netherlands.com writes:
>>
>>> On Sun, 23 Aug 2009 22:22:19 -0500, Tad J McClellan <tadmc@seesig.invalid> wrote:
>><snip>
>>>>
>>>>Show me a program where you pass an undefined filehandle to read
>>>>and it dies...
>>>>
>>> use strict;
>>> use warnings;
>>>
>>> my ($buf,$length) = ('',5);
>>>
>>> # Invoke error #2, FATAL error on read
>>> my $fh;
>>>
>>> {
>>> local $!;
>>> my $status = eval { read ($fh, $buf, $length) };
>>> $@ =~ s/\s+$//;
>>> if ($@ || (!$status && $!)) {
>>> print "Error in read: ". ($@ ? $@ : $! ). "\n";
>>> }
>>> }
>>>
>>> print "More code ...\n";
>>>
>>> __END__
>>> c:\temp>perl ss.pl
>>> Error in read: Can't use an undefined value as a symbol reference at ss.pl line
>>> 13.
>>
>>Your program is not dying on an undefined filehandle. It is dying on an
>>undefined scalar. This is not the same.
>>
>>Mart
>
>Your wrong, its die'ing in runtime, function call 'read()'
>-sln
Furthermore, failed filehandle opens are valid and don't emit this error when
used in a read.
Go figure.. Just when you think you know it all
-sln
------------------------------
Date: Mon, 24 Aug 2009 09:38:19 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <86zl9pk6fo.fsf@gareth.avalon.lan>
sln@netherlands.com writes:
> On Mon, 24 Aug 2009 08:41:06 +0200, Mart van de Wege <mvdwege@mail.com> wrote:
>
>>sln@netherlands.com writes:
>>
>>> On Sun, 23 Aug 2009 22:22:19 -0500, Tad J McClellan <tadmc@seesig.invalid> wrote:
>><snip>
>>>>
>>>>Show me a program where you pass an undefined filehandle to read
>>>>and it dies...
>>>>
>>> use strict;
>>> use warnings;
>>>
>>> my ($buf,$length) = ('',5);
>>>
>>> # Invoke error #2, FATAL error on read
>>> my $fh;
>>>
>>> {
>>> local $!;
>>> my $status = eval { read ($fh, $buf, $length) };
>>> $@ =~ s/\s+$//;
>>> if ($@ || (!$status && $!)) {
>>> print "Error in read: ". ($@ ? $@ : $! ). "\n";
>>> }
>>> }
>>>
>>> print "More code ...\n";
>>>
>>> __END__
>>> c:\temp>perl ss.pl
>>> Error in read: Can't use an undefined value as a symbol reference at ss.pl line
>>> 13.
>>
>>Your program is not dying on an undefined filehandle. It is dying on an
>>undefined scalar. This is not the same.
>>
>>Mart
>
> Your wrong, its die'ing in runtime, function call 'read()'
> -sln
I'm not.
It's dying on the read, yes, but *not* on an undefined filehandle.
If you can't distinguish your referents from your references, you have
no business programming.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Mon, 24 Aug 2009 01:08:01 -0700
From: sln@netherlands.com
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <ith495h686m57lef05enseo4gtre4fkbqk@4ax.com>
On Mon, 24 Aug 2009 09:38:19 +0200, Mart van de Wege <mvdwege@mail.com> wrote:
>sln@netherlands.com writes:
>
>> On Mon, 24 Aug 2009 08:41:06 +0200, Mart van de Wege <mvdwege@mail.com> wrote:
>>
>>>sln@netherlands.com writes:
>>>
>>>> On Sun, 23 Aug 2009 22:22:19 -0500, Tad J McClellan <tadmc@seesig.invalid> wrote:
>>><snip>
>>>>>
>>>>>Show me a program where you pass an undefined filehandle to read
>>>>>and it dies...
>>>>>
>>>> use strict;
>>>> use warnings;
>>>>
>>>> my ($buf,$length) = ('',5);
>>>>
>>>> # Invoke error #2, FATAL error on read
>>>> my $fh;
>>>>
>>>> {
>>>> local $!;
>>>> my $status = eval { read ($fh, $buf, $length) };
>>>> $@ =~ s/\s+$//;
>>>> if ($@ || (!$status && $!)) {
>>>> print "Error in read: ". ($@ ? $@ : $! ). "\n";
>>>> }
>>>> }
>>>>
>>>> print "More code ...\n";
>>>>
>>>> __END__
>>>> c:\temp>perl ss.pl
>>>> Error in read: Can't use an undefined value as a symbol reference at ss.pl line
>>>> 13.
>>>
>>>Your program is not dying on an undefined filehandle. It is dying on an
>>>undefined scalar. This is not the same.
>>>
>>>Mart
>>
>> Your wrong, its die'ing in runtime, function call 'read()'
>> -sln
>
>I'm not.
>
>It's dying on the read, yes, but *not* on an undefined filehandle.
>
>If you can't distinguish your referents from your references, you have
>no business programming.
>
>Mart
I guess a filehandle has to be defined or its not a filehandle,
which is really a reference to GLOB which is undefined.
So the point is that thing passed to the slot called the FILEHANDLE in
the parameter list for read is undefined.
Good call, thanks for schooling me.
Anything else to point out before the real issue, IT DIES man??
Any business on that issue? Re-read the text, stop slurping crap
out of your navel!
-sln
------------------------------
Date: Mon, 24 Aug 2009 11:35:09 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <86skfhk10y.fsf@gareth.avalon.lan>
sln@netherlands.com writes:
> On Mon, 24 Aug 2009 09:38:19 +0200, Mart van de Wege <mvdwege@mail.com> wrote:
>
>>sln@netherlands.com writes:
>>
>>> On Mon, 24 Aug 2009 08:41:06 +0200, Mart van de Wege <mvdwege@mail.com> wrote:
>>>
>>>>sln@netherlands.com writes:
>>>>
>>>>> On Sun, 23 Aug 2009 22:22:19 -0500, Tad J McClellan <tadmc@seesig.invalid> wrote:
>>>><snip>
>>>>>>
>>>>>>Show me a program where you pass an undefined filehandle to read
>>>>>>and it dies...
>>>>>>
>>>>> use strict;
>>>>> use warnings;
>>>>>
>>>>> my ($buf,$length) = ('',5);
>>>>>
>>>>> # Invoke error #2, FATAL error on read
>>>>> my $fh;
>>>>>
>>>>> {
>>>>> local $!;
>>>>> my $status = eval { read ($fh, $buf, $length) };
>>>>> $@ =~ s/\s+$//;
>>>>> if ($@ || (!$status && $!)) {
>>>>> print "Error in read: ". ($@ ? $@ : $! ). "\n";
>>>>> }
>>>>> }
>>>>>
>>>>> print "More code ...\n";
>>>>>
>>>>> __END__
>>>>> c:\temp>perl ss.pl
>>>>> Error in read: Can't use an undefined value as a symbol reference at ss.pl line
>>>>> 13.
>>>>
>>>>Your program is not dying on an undefined filehandle. It is dying on an
>>>>undefined scalar. This is not the same.
>>>>
>>>>Mart
>>>
>>> Your wrong, its die'ing in runtime, function call 'read()'
>>> -sln
>>
>>I'm not.
>>
>>It's dying on the read, yes, but *not* on an undefined filehandle.
>>
>>If you can't distinguish your referents from your references, you have
>>no business programming.
>>
>>Mart
>
> I guess a filehandle has to be defined or its not a filehandle,
> which is really a reference to GLOB which is undefined.
> So the point is that thing passed to the slot called the FILEHANDLE in
> the parameter list for read is undefined.
>
Irrelevant. You're passing a scalar to read(), not a filehandle.
> Good call, thanks for schooling me.
So just admit you're wrong and shut up.
> Anything else to point out before the real issue, IT DIES man??
Sod off you whiner. Tad said that Perl doesn't die on an undefined
filehandle. Your example doesn't refute that. The real issue is that you
are *wrong*, and trying to avoid admitting that.
> Any business on that issue? Re-read the text, stop slurping crap
> out of your navel!
Learn to program before you open your mouth about the subject.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Mon, 24 Aug 2009 03:43:44 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Preventing lines from printing
Message-Id: <h6t29g$n42$2@reader1.panix.com>
In article <87ocq61b6b.fsf@quad.sysarch.com>,
Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
>
> TM> #! /usr/bin/perl -wan
> TM> BEGIN { $sum = 0; $count = 0; }
>
>no need to initialize those to 0 as += won't warn when adding to
>undef. same is true for ++ and .= .
I like explicit initialization to the correct value, even if the
default works the same way. I don't like touching undef (except with
defined, which doesn't really touch it), even in contexts where it
works.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 24 Aug 2009 00:27:57 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Preventing lines from printing
Message-Id: <87ocq5zvhu.fsf@quad.sysarch.com>
>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
TM> In article <87ocq61b6b.fsf@quad.sysarch.com>,
TM> Uri Guttman <uri@StemSystems.com> wrote:
>>>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
>>
TM> #! /usr/bin/perl -wan
TM> BEGIN { $sum = 0; $count = 0; }
>>
>> no need to initialize those to 0 as += won't warn when adding to
>> undef. same is true for ++ and .= .
TM> I like explicit initialization to the correct value, even if the
TM> default works the same way. I don't like touching undef (except with
TM> defined, which doesn't really touch it), even in contexts where it
TM> works.
do you also assign hash/array refs before you add things to them? the
above is the same thing, autovivification. this saves lots of dumb
boring newbie code that does it like other langs, check if initialized
to something and if not initialize, then mung it.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 24 Aug 2009 19:32:22 +1000
From: "Diamond, Mark" <dot@dot.dot>
Subject: Re: Preventing lines from printing
Message-Id: <h6tmn6$doa$1@news-01.bur.connect.com.au>
Many thanks to all who responded. I learned a lot of Perl in the process. In
responding to Alexander Bartolich I mentioned that his early post had
pointed me in the direction of my error. I had incorrectly assumed that
default must be to print something for each input line and that I needed to
supress printing. Silly assumption. I realised after reading AB's answer
that I was printing something accidentally when I did not intend to. ...
Leading me to a different post today ...
Mark
"Diamond, Mark" <dot@dot.dot> wrote in message
news:h6qobl$6is$1@news-01.bur.connect.com.au...
> Hello (I posted this in alt.comp.lang.perl but I think it should be here)
> ...
>
> I am processing multiple text files. There is a lot of pre-processing
> before
> the file-reading commences, then each file gets read (but I don't want to
> print any blank line) and then there is a lot of post-processing of each
> file. In AWK I had a BEGIN block, no print lines in the middle, and a very
> long END block. In Perl, I have
>
> pre-code
> while (<>) {
> lots of processing of file lines with only one wanted "print"
> }
> post-processing
>
> but I get a blank line output on any line that I don't actually do an
> explicit print for. I thought "perl -n" would give me what I need but it
> doesn't (of course) because of the wrapped "while(<>) { }" .
>
> Please ... what should I be doing?
>
> Mark
>
>
>
------------------------------
Date: Mon, 24 Aug 2009 19:45:35 +1000
From: "Diamond, Mark" <dot@dot.dot>
Subject: Printing only on a match
Message-Id: <h6tnft$ecd$1@news-01.bur.connect.com.au>
This post is prompted by having my earlier mistake ("Preventing lines from
printing 23/8/09) pointed out to me. My problem is now one of elegance
rather than failure.
I have
while (<>) {
.
.
($angle, $stage)= /^(\d\d)(\d+)/;
print "$angle $stage\n";
.
.
}
which prints something whether there is a match or not. I assume that I can
avoid the printing when there is no match by comparing $angle and $stage
with null strings, but please, what is the/a sensible/elegant way of
printing on a complete match and not printing on no match or only a partial
match?
Cheers,
Mark
------------------------------
Date: Sun, 23 Aug 2009 19:03:54 -0700
From: sln@netherlands.com
Subject: Re: windows one liner to output unix line feed
Message-Id: <s3s395h73t510pv6kbjjojhon5418hf4dq@4ax.com>
On Sun, 23 Aug 2009 08:54:40 +0200, Christian Winter <thepoet_nospam@arcor.de> wrote:
>sln@netherlands.com wrote:
>[...]
>> It really doesen't matter what the :crlf layer does in unix.
>> It only matters how the console device interprets CR's as a tty.
>> You can have a thousand CR's and one LF before you print and it will
>> still print on the next line (Mac may be different).
>
>I think you're mixing up two different things here, one is
>text file IO (and the way Perl implements it on different
>platforms) and the other is console IO, which would only
>apply when piping/directing to or from a perl script.
>
How could I mix that up. In my example I put the handle in binary
mode. The i/o layers don't care about the handle do they?
Nobodys going to seek the un-seekable. Likewise, the stream gets
a control character that happens to be 0x0a, a line-feed, apparently
free of i/o layer interaction.
Didn't you get that sense?
>> If his file eol is all CR's ala Mac, then he opened it without an eol
>> and processed the whole file as one line. Otherwise, a series of
>> text embedded with just CR's on a console where a CR is a control character,
>> will result in overwrites of the lines without LF's.
>
>And here you're mixing up Perl's behaviour for input line separators
>and output line separators too. Using the "-i" switch, there's no
>console involved, Perl simply opens a file and sequencially inserts
>what gets passed to print. If the file has been opened with a :crlf
>layer, this just means that any newlines encountered in the process
>are replaced by a sequence of carriage return plus newline.
>
And where did you get the notion I was talking about Perls notion
of line seperators or anything related to anything but BINARY output
on a handle ?
I know the layers of Perl better than you do by your response.
>What a console shows you when you cat the file contents is a very
>different thing.
>
I find this statement incredible.
>> If I had a unix machine I could try it out. It seems it would be a major
>> fopah if Perl didn't get the basic unix console correct, lol.
>
>Again, what's that got to do with a console? You're seriously getting
>off the track.
>
>-Chris
Chris, you should re-read what I wrote. I wasn't writing about Perl
at all. It was all about the device, it had nothing whatsoever to do with
Perl in the slighetest degree!
The output stream to the device was binary, had nothing to do with perlio
layers other than putting the stream in binary before delivering the data
which was odododoaoaododod and other combinations. Devices are themselves
independently act on binary control codes, and CR, LF, FF's are control codes
devices promote to a wide range of different, sometimes visual results, if
thats its nature.
-sln
------------------------------
Date: Sun, 23 Aug 2009 19:18:41 -0700
From: sln@netherlands.com
Subject: Re: windows one liner to output unix line feed
Message-Id: <ekt395lmile1t1hce2cron353hcb9uct6b@4ax.com>
On Sun, 23 Aug 2009 19:03:54 -0700, sln@netherlands.com wrote:
>On Sun, 23 Aug 2009 08:54:40 +0200, Christian Winter <thepoet_nospam@arcor.de> wrote:
>
>>sln@netherlands.com wrote:
>>[...]
>>> It really doesen't matter what the :crlf layer does in unix.
>>> It only matters how the console device interprets CR's as a tty.
>>> You can have a thousand CR's and one LF before you print and it will
>>> still print on the next line (Mac may be different).
>>
>>I think you're mixing up two different things here, one is
>>text file IO (and the way Perl implements it on different
>>platforms) and the other is console IO, which would only
>>apply when piping/directing to or from a perl script.
>>
>How could I mix that up. In my example I put the handle in binary
>mode. The i/o layers don't care about the handle do they?
>Nobodys going to seek the un-seekable. Likewise, the stream gets
>a control character that happens to be 0x0a, a line-feed, apparently
>free of i/o layer interaction.
>Didn't you get that sense?
>
>>> If his file eol is all CR's ala Mac, then he opened it without an eol
>>> and processed the whole file as one line. Otherwise, a series of
>>> text embedded with just CR's on a console where a CR is a control character,
>>> will result in overwrites of the lines without LF's.
>>
>>And here you're mixing up Perl's behaviour for input line separators
>>and output line separators too. Using the "-i" switch, there's no
>>console involved, Perl simply opens a file and sequencially inserts
>>what gets passed to print. If the file has been opened with a :crlf
>>layer, this just means that any newlines encountered in the process
>>are replaced by a sequence of carriage return plus newline.
>>
>And where did you get the notion I was talking about Perls notion
>of line seperators or anything related to anything but BINARY output
>on a handle ?
>I know the layers of Perl better than you do by your response.
>
>>What a console shows you when you cat the file contents is a very
>>different thing.
>>
>I find this statement incredible.
>
>>> If I had a unix machine I could try it out. It seems it would be a major
>>> fopah if Perl didn't get the basic unix console correct, lol.
>>
>>Again, what's that got to do with a console? You're seriously getting
>>off the track.
>>
>>-Chris
>
>Chris, you should re-read what I wrote. I wasn't writing about Perl
>at all. It was all about the device, it had nothing whatsoever to do with
>Perl in the slighetest degree!
>
>The output stream to the device was binary, had nothing to do with perlio
>layers other than putting the stream in binary before delivering the data
>which was odododoaoaododod and other combinations. Devices are themselves
>independently act on binary control codes, and CR, LF, FF's are control codes
>devices promote to a wide range of different, sometimes visual results, if
>thats its nature.
>
>-sln
In addition, I was giving examples suggesting that Perl did nothing wrong,
even if the filehandle (apparently not) is not open for binary output.
The suggestion is that the device could be reacting (normally) to embedded
CR's from a cross-platform, or who knows, some binary interaction, by the
user.
Or his device is in a mode that translates control characters differently.
Obviously, the way to debug is to inspect the file, inspect the device mode,
then make a determination. The way NOT to debug, is suspecting Perl a culprit
in something that would have showed up hundreds of thousands of times before
this.
But, apparently, to get the newbies all rieled up on a wild goose chase,
that is seemingly whats happening.
-sln
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2568
***************************************
