Guardian Angel wrote:
>
> R. Joseph Newton wrote:
> >
> > Guardian Angel wrote:
>
> > > But now... i want to be more precise with my script.
> > > So i made 2 extra if loops, 1 is looking for errors, and if so, also
> > > check if there is no 127.0.0.x adres in it anymore (works so far :D)
> >
>
>
Guardian Angel wrote:
> On Mon, 2003-11-17 at 06:19, R. Joseph Newton wrote:
> > Guardian Angel wrote:
>
> > > But now... i want to be more precise with my script.
> > > So i made 2 extra if loops, 1 is looking for errors, and if so, also
> > > check if there is no 127.0.0.x adres in it anymore (w
On Sunday, Nov 16, 2003, at 21:22 US/Pacific, R. Joseph Newton wrote:
drieux wrote:
I on the other hand have had the unpleasantry of FORGETTING
that I was whacking new code in that was doing a 'select'.
So one solution is to make sure that IF you do a select that
you put things back where you fou
On Mon, 2003-11-17 at 06:19, R. Joseph Newton wrote:
> Guardian Angel wrote:
> > But now... i want to be more precise with my script.
> > So i made 2 extra if loops, 1 is looking for errors, and if so, also
> > check if there is no 127.0.0.x adres in it anymore (works so far :D)
>
> Whoa! This
"R. Joseph Newton" wrote:
> ...or better yet, to redo your code a little, and write to and read
> from explicitly-selected filehandles.
Duh. That should have been "explicitly-speciifed".
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Nov 16, R. Joseph Newton said:
>sometimes. The perfect setup for the great Perl anonymous block:
>
>{
>$| = 1;
> do stuff that really needs to be autoflushed
>} # Get things back to normal
I think you want a 'local' in front of that $| line.
{
local $| = 1;
# ...
}
drieux wrote:
> yes, in the sense that it comes in the section about
>
> select RBITS,WBITS,EBITS,TIMEOUT
>
> and as long as the person stays safely with the 'simpler'
> perl select, and does not wander off into having buffered
> and unbuffered file handles, then clearly it is "out of co
drieux wrote:
> I on the other hand have had the unpleasantry of FORGETTING
> that I was whacking new code in that was doing a 'select'.
>
> So one solution is to make sure that IF you do a select that
> you put things back where you found them, eg:
>
> my $oldfh = select($newfh);
>
Guardian Angel wrote:
>
> I was looking for the > and < operators. I had used them with backticks
> (but gave a error message, because it was a "greater then" value,
> because i left spaces like print $a > $b instead of print $a>$b
> But now... i want to be more precise with my script.
> So i
On Nov 16, Hacksaw said:
>The fact that select has two incompatible meanings in perl is a
>mistake. If I were going to rename them, I'd call the default output
>changing command defout or default_output. As for the C lib function,
>I'd call it readydesc or ready_descriptors.
I think 'select' is a
>So my intention was to finish off the general discussion
>of 'do you really need select' with that simple reminder
>that when one does need select, one also needs to do some
>basic defensive coding one place or the other.
This post goes a ways to showing why unthinking operator overloading
is a
--On Sunday, November 16, 2003 8:45 PM +0100 Guardian Angel
<[EMAIL PROTECTED]> wrote:
use strict; # Always
use warnings; # Usually (same as -w qualifier but portable)
i will do that, "use warnings;" gave me more (human readable)
errors, so better to understand for me.
Well, if it's human r
On Sunday, Nov 16, 2003, at 10:41 US/Pacific, Jeff 'japhy' Pinyan wrote:
[..]
And yes, DO remember the caveat at the end of the select
perldoc that notes:
WARNING: One should not attempt to mix buffered I/O
(like "read" or ) with "select", except as
permitted
On Sun, 2003-11-16 at 16:52, Rob Dixon wrote:
> Hi Sander. First of all, I guess this will feel like I'm ripping
> your code apart. Try to imagine me as your best-friend
> cardboard-cutout programmer with nothing but your interests
> at heart. :)
I'll do my best to see you as my best-friend, while
On Nov 16, drieux said:
> select FILEHANDLE
> select Returns the currently selected filehandle. Sets the
> current default filehandle for output, if FILEHANDLE
> is supplied. This has two effects: first, a "write"
> or a "print" without a filehan
On Sunday, Nov 16, 2003, at 07:53 US/Pacific, Hacksaw wrote:
[..]
If you were never going to do anything else in the while loop,
it could be this:
while () { print EL $_; }
I think select is one of the statements that you don't need
for most small projects. I have never used it in my 6 or
so years
Rob Dixon wrote:
> My code would look like
>
> use strict;
> use warnings;
>
> open ER, '/home/unicorn/Plscripts/error_log' or die $!;
> open EL, '> /home/unicorn/Plscripts/ERROR.LOG' or die $!;
>
> print while ;
>
> You write a darned good acorn! Oaks are next week. :)
Damn. And also
Rob Dixon wrote:
> > } select (STDOUT); #make sure STDOUT is normal again
>
> What for, if you're not going to use STDOUT again?
A better comment would have also said, "And anyway
STDOUT is still selected."
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [E
Sander:
I have an answer, and a comment:
The answer: select wants a filehandle, so line 7 wants to read
select EL;
The comment:
You are probably complicating things a great deal by using select.
#!/usr/bin/perl -w
open (ER, "/home/unicorn/Plscripts/ERROR.LOG"); #opening ERROR.LOG for writing
Hi Sander. First of all, I guess this will feel like I'm ripping
your code apart. Try to imagine me as your best-friend
cardboard-cutout programmer with nothing but your interests
at heart. :)
Few people know what to make of Perl the first time they see
it. People try to force it into either C or
On Nov 16, Sander said:
>open (ER,"/home/unicorn/Plscripts/error_log"); #opening error_log
>open (EL, "home/unicorn/Plscripts/ERROR.LOG"); #opening ERROR.LOG
I have a feeling you're missing the leading '/' for that second file.
You should never open a file without being sure it worked:
open F
21 matches
Mail list logo
