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)
> >
>
> > Whoa! This is not the way to get a programming job done. Rambling does not get
> > you there.
> > Before you can write effective code, you have to focus your thinking process.
> > Don't get
> > caught up in fascination with coding tricks. Look for tools to accomplish clearly
> > defined
> > purposes. Express those purposes, and the steps to achieve them, in plain
> > language.
> >
> > Most important, take a breath.
> >
>
> Uhm... lol... i get it. But this *is* working (although it will not be
> the best code you ever seen ;))
With this sort of comment I wouldn't be L'ing OL at this point. However,
'working', can be a Good Thing as long as you use it as a stepping-stone,
understand how it's working, and grow from there.
> Ofcourse i can better make a complete plan of what i want, but that is
> too much atm.
What I think others have been meaning is that you should start to think
'algorithmically'. If you never have an ATM at which point you can learn
to program then it will stay that way forever! If you just want a short
program 'right now' then it will stay that way. Your choice, but I can
see it's a difficult one to make without knowing the consequences.
> I have *no* experience with coding at all, and it's a bit overwhelming
> for now :) ( a lot of statements, loops, array's, hashes etc)
You bet - I'm not surprised!
> So i was just trying to make my scripts step by step more difficult, so
> i can understand *why* Perl is doing things, and what it is doing.
That sounds like a wise thought, and so a wise thing to say. But since
you can't see the ramp from where you're standing you can't accelerate
properly. I would wholeheartedly recommend Perl as a first language, but
you need an outside perspective to help. Otherwise you will be trying
different things endlessly and end up frustrated.
> That way i can better understand what happends, and then (ofcourse) I
> have to find out exactly what i want, and how i want it... but for now
> that is too much.
Just small tweak here. You will realise that a language relies a lot on
its users and the way they practise what they do. Your choice then,
in the end, has to be something to do also whith what others want and
how they want it. (If only to understand newgroups like this one!)
> So i prefer little parts (which i can understand) and then step by step
> learning more.
But the 'small parts' should be chosen carefully. Play for a /long/ time
with what you understand as being the language's core. Experiment with
things like incrementing all sorts of variables. Try daft things like
multiplying hashes. And explain to yourself why they do what they do.
> ie. i see a lot of ppl who start with (for me) heavy scripts (used with
> 2 or 3 modules) while they have not really a clue of what they are
> doing... copy/ paste will work, but it will definitly not *learn* to
> write code yourself :D
It's hard for people to know here what you need. Often people will need
a simple solution and know, after some thought, why it does what they need.
They will be enlightened! But many, like you, are searching with almost
no expectations. That sort of answer may me useless or even damaging to you,
and often what you will need is a correction of your preconceptions.
Don't use packages or modules at all if you're starting from scratch. Learn
the language in stead.
> And now i will take a deep breath.....aaahhhhhh (nice)
Phew! Me too!
But may I also point out what I've been talking about?
[snip]
>
> >
> > 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.
>
> 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.
Now here's where Perl splits people. It's more what would be called
'context-sensitive' than any other language that I know. That means that
it tries very hard to understand what you mean (and usually succeeds)
by similar and even identical contructs in different contexts. In your
example above, both
print $a > $b
and
print $a>$b
would result in what, presumably, you meant: i.e. '1' if the
test were true, or the null string, '', if it were false. But
there is also the <$a> operator which which perform a 'glob'
operation if $a is a text string or a readline() operation if
is a filehandle.
> 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)
> then i want to sort the ip's ....and that's what dazzling me now...
> This is what i want: I Look in the (newly) written error.log, and see
> immediatley that someone with ip 123.45.6.7 has tried 1x to login. But
> 123.45.6.8 has tried to login 50x in the last 6 days...
Here I will get into trouble, (if not before). Make all of your data
perfect and use no error handling until you have the 'perfect case'
working. 'use strict', 'use warnings' will give you all that you need
to get something basic running. Few people on this list know how to
handle quad-decimals without looking it up. Play with ordinary numbers
like, say, forty-two.
> Now my thought was that i made an array to put everything from while
> <ER>, and when it's an error message and *not* 127.0.0.x in the array,
> then sort, and put it in the error.log.... unfortunatly it's not
> working.... so i looked for the subroutines in Learning Perl... but i
> don't get it *how* you can get these values....
Imagine yourself a simpler situation. Get that going and then
elaborate it.
> #!/usr/bin/perl
> use strict;
> use warnings;
> open (ER, "</home/unicorn/Plscripts/error_log") || die "can't open ER,
> $!\n"; #opening error_log for ReadNow all the advice helped me out,
> open (EL, ">>/home/unicorn/Plscripts/error.log") || die "can't open EL,
> $!\n"; #opening ERROR.LOG for Write
My opinion is to always use 'or' instead of '||'. It's a lot more
readable, as well as being more likely to be what you mean.
> while (<ER>) { # as long as ER is open, read....
I pointed this out before. If you don't know what the construct means
then NEVER comment it wrongly. It's supposed to be understood, but
but obscure.
while (<ER>) { # Set $_ to readline(ER) and exit if $_ is undefined
:
}
The whole idea being that what you /wrote/ better explains what's happening
than your comment. You would be better off writing
while (<ER>) { # Read until EOF
:
}
Or better still
while (<ER>) {
:
}
(with the assumption that the adressee knows he is reading Perl)
[snip trailer]
I hope this helps!
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
