[22753] in Perl-Users-Digest
Perl-Users Digest, Issue: 4974 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon May 12 18:06:19 2003
Date: Mon, 12 May 2003 15:05:20 -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, 12 May 2003 Volume: 10 Number: 4974
Today's topics:
Re: 8255A Chip (Tim Shoppa)
A perl parsing question... (Jim Carter)
Re: A perl parsing question... <mbudash@sonic.net>
Re: A perl parsing question... <abigail@abigail.nl>
Re: A perl parsing question... <abigail@abigail.nl>
Re: A perl parsing question... <mbudash@sonic.net>
Re: Bloody Java Proselytisers!!! <cwilbur@mithril.chromatico.net>
Re: Bloody Java Proselytisers!!! <p.lord@russet.org.uk>
Re: Bloody Java Proselytisers!!! <cwilbur@mithril.chromatico.net>
Re: bootstrap <kalinabears@hdc.com.au>
CGI.pm buffer overflow security?? (Kenjis Kaan)
Re: changing the date <member17678@dbforums.com>
Re: check IP address <barryk2@SPAM-KILLER.mts.net>
Re: command interface (not a shell) <abuse@mweb.co.za>
Compiler perl <cfowler@linuxiceberg.com>
Re: Compiler perl <abuse@mweb.co.za>
Re: Compiler perl <cfowler@linuxiceberg.com>
Re: Compiler perl <abuse@mweb.co.za>
Re: Compiler perl <ddunham@redwood.taos.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 12 May 2003 06:40:06 -0700
From: shoppa@trailing-edge.com (Tim Shoppa)
Subject: Re: 8255A Chip
Message-Id: <bec993c8.0305120540.7c036ed1@posting.google.com>
Joona I Palaste <palaste@cc.helsinki.fi> wrote in message news:<b9m3eg$e26$1@oravannahka.helsinki.fi>...
> Herbert Andress <handress@spam.blokcck> scribbled the following
> on comp.lang.c:
> > Is it likely that a small picoJava II embedded system would include an
> > 8255 chip?
>
> What was... <looks at the crosspost list> oh, never mind.
This isn't the first time, either: a post to the same groups with the
same subject and body (but a different author) occurred in Mar 2002 as
well. A running joke? I don't get it...
Tim.
------------------------------
Date: 12 May 2003 12:20:14 -0700
From: carterave@yahoo.com (Jim Carter)
Subject: A perl parsing question...
Message-Id: <9c2a26b6.0305121120.7916ace3@posting.google.com>
Hi all,
I have an input file in which each line has two colons and some other
text. I want to discard all the text after the second colon (including
this second colon) in each line.
-----------------------------
The output should be:
TESTKEY1.1: This is the Testone
TESTKEY101: This is test numbertwo
TESTKEY3: Is this test
-----------------------------------
I have the below script:
************************
#! C:/perl/bin/perl
@array = <DATA>;
foreach (@array)
{
$_ =~ s/\w:\s+//g;
print $_;
}
__DATA__
TESTKEY1.1: This is the Testone: I am new to perl programming
TESTKEY101: This is test numbertwo: The reg eps are a bit confusing.
TESTKEY3: Is this test: Which is the good book for reg exps. This need
a lot of practice.
*****************************
How can get my desired output?
Thanks,
Jim.
------------------------------
Date: Mon, 12 May 2003 19:44:55 GMT
From: Michael Budash <mbudash@sonic.net>
Subject: Re: A perl parsing question...
Message-Id: <mbudash-0C548B.12445412052003@typhoon.sonic.net>
In article <9c2a26b6.0305121120.7916ace3@posting.google.com>,
carterave@yahoo.com (Jim Carter) wrote:
> Hi all,
>
>
> I have an input file in which each line has two colons and some other
> text. I want to discard all the text after the second colon (including
> this second colon) in each line.
>
> -----------------------------
> The output should be:
>
> TESTKEY1.1: This is the Testone
> TESTKEY101: This is test numbertwo
> TESTKEY3: Is this test
> -----------------------------------
>
>
> I have the below script:
>
> ************************
>
> #! C:/perl/bin/perl
> @array = <DATA>;
> foreach (@array)
> {
> $_ =~ s/\w:\s+//g;
one way:
s/^(.+:.+):.+$/$1/g;
another way, but you'll lose the trailing newline (no big):
s/:[^:]+$//g;
print "$_\n"; # add the newline back
> print $_;
> }
>
> __DATA__
> TESTKEY1.1: This is the Testone: I am new to perl programming
> TESTKEY101: This is test numbertwo: The reg eps are a bit confusing.
> TESTKEY3: Is this test: Which is the good book for reg exps. This need
> a lot of practice.
>
> *****************************
>
>
> How can get my desired output?
>
> Thanks,
> Jim.
--
Michael Budash
------------------------------
Date: 12 May 2003 19:58:18 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: A perl parsing question...
Message-Id: <slrnbbvv6q.f7.abigail@alexandra.abigail.nl>
Jim Carter (carterave@yahoo.com) wrote on MMMDXLI September MCMXCIII in
<URL:news:9c2a26b6.0305121120.7916ace3@posting.google.com>:
%% Hi all,
%%
%%
%% I have an input file in which each line has two colons and some other
%% text. I want to discard all the text after the second colon (including
%% this second colon) in each line.
Just say what you want to keep:
s/^([^:]*:[^:]*):.*/$1/;
What you want to keep is: from the beginning, zero or more times
something that's not a colon, then a colon, and then zero or more
times something that's not a colon. What follows, a colon, and then
the rest of the line, is what you delete.
Abigail
--
sub f{sprintf$_[0],$_[1],$_[2]}print f('%c%s',74,f('%c%s',117,f('%c%s',115,f(
'%c%s',116,f('%c%s',32,f('%c%s',97,f('%c%s',0x6e,f('%c%s',111,f('%c%s',116,f(
'%c%s',104,f('%c%s',0x65,f('%c%s',114,f('%c%s',32,f('%c%s',80,f('%c%s',101,f(
'%c%s',114,f('%c%s',0x6c,f('%c%s',32,f('%c%s',0x48,f('%c%s',97,f('%c%s',99,f(
'%c%s',107,f('%c%s',101,f('%c%s',114,f('%c%s',10,)))))))))))))))))))))))))
------------------------------
Date: 12 May 2003 20:37:13 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: A perl parsing question...
Message-Id: <slrnbc01fp.f7.abigail@alexandra.abigail.nl>
Michael Budash (mbudash@sonic.net) wrote on MMMDXLI September MCMXCIII in
<URL:news:mbudash-0C548B.12445412052003@typhoon.sonic.net>:
,, In article <9c2a26b6.0305121120.7916ace3@posting.google.com>,
,, carterave@yahoo.com (Jim Carter) wrote:
,,
,, > Hi all,
,, >
,, >
,, > I have an input file in which each line has two colons and some other
,, > text. I want to discard all the text after the second colon (including
,, > this second colon) in each line.
,, >
,, > -----------------------------
,, > The output should be:
,, >
,, > TESTKEY1.1: This is the Testone
,, > TESTKEY101: This is test numbertwo
,, > TESTKEY3: Is this test
,, > -----------------------------------
,, >
,, >
,, > I have the below script:
,, >
,, > ************************
,, >
,, > #! C:/perl/bin/perl
,, > @array = <DATA>;
,, > foreach (@array)
,, > {
,, > $_ =~ s/\w:\s+//g;
,,
,, one way:
,,
,, s/^(.+:.+):.+$/$1/g;
That would fail on the following lines:
foo::bar
:foo:bar
foo:bar:
foo:bar:baz:fnurd
All you know the lines contain colons and some other text - but you
don't know where that other text is, so you shouldn't assume that
text to be somewhere. Furthermore, you also shouldn't assume that
other text doesn't contain a colon. Your substitution deletes up to
the *last* colon, if there are at least two colons on the line.
Abigail
--
CHECK {print "another "}
END {print "Hacker\n"}
BEGIN {print "Just " }
INIT {print "Perl " }
------------------------------
Date: Mon, 12 May 2003 20:58:58 GMT
From: Michael Budash <mbudash@sonic.net>
Subject: Re: A perl parsing question...
Message-Id: <mbudash-DA4FF4.13585712052003@typhoon.sonic.net>
In article <slrnbc01fp.f7.abigail@alexandra.abigail.nl>,
Abigail <abigail@abigail.nl> wrote:
> Michael Budash (mbudash@sonic.net) wrote on MMMDXLI September MCMXCIII in
> <URL:news:mbudash-0C548B.12445412052003@typhoon.sonic.net>:
> ,, In article <9c2a26b6.0305121120.7916ace3@posting.google.com>,
> ,, carterave@yahoo.com (Jim Carter) wrote:
> ,,
> ,, > Hi all,
> ,, >
> ,, >
> ,, > I have an input file in which each line has two colons and some other
> ,, > text. I want to discard all the text after the second colon (including
> ,, > this second colon) in each line.
> ,, >
> ,, > -----------------------------
> ,, > The output should be:
> ,, >
> ,, > TESTKEY1.1: This is the Testone
> ,, > TESTKEY101: This is test numbertwo
> ,, > TESTKEY3: Is this test
> ,, > -----------------------------------
> ,, >
> ,, >
> ,, > I have the below script:
> ,, >
> ,, > ************************
> ,, >
> ,, > #! C:/perl/bin/perl
> ,, > @array = <DATA>;
> ,, > foreach (@array)
> ,, > {
> ,, > $_ =~ s/\w:\s+//g;
> ,,
> ,, one way:
> ,,
> ,, s/^(.+:.+):.+$/$1/g;
>
> That would fail on the following lines:
>
> foo::bar
> :foo:bar
> foo:bar:
> foo:bar:baz:fnurd
>
>
> All you know the lines contain colons and some other text - but you
> don't know where that other text is, so you shouldn't assume that
> text to be somewhere. Furthermore, you also shouldn't assume that
> other text doesn't contain a colon. Your substitution deletes up to
> the *last* colon, if there are at least two colons on the line.
>
>
>
> Abigail
of course.
however, the data may be tightly structured, where no such problems can
occur, i'm not going to offer my time for gratis delivering a solution
that accounts for every potential irregularity and/or anomaly that could
be encountered. so i made some assumptions.
if the o.p. can't take it from there, he can hire someone who can. then
the deliverable can be defined much more clearly.
--
Michael Budash
------------------------------
Date: Mon, 12 May 2003 14:12:57 GMT
From: Charlton Wilbur <cwilbur@mithril.chromatico.net>
Subject: Re: Bloody Java Proselytisers!!!
Message-Id: <87d6iofe0u.fsf@mithril.chromatico.net>
Phillip Lord <p.lord@russet.org.uk> writes:
> Personally I would argue that being restricted to one paradigm is
> less of a problem for a good programmer, as a good programmer should
> be able to translate their favourite idioms freely between
> paradigms.
Idioms don't translate freely between paradigms. That's what makes
them idiomatic. And while it's not a problem in the abstract to
translate between paradigms -- eh, let me use an example.
When I was an undergraduate, one of my fellow-students insisted on
implementing binary trees non-recursively. This is the model,
written using the recursive approach, in C-like pseudocode:
void inorder_traverse (node *start)
{
if (node->left)
inorder_traverse (node->left);
print_node (node->data);
if (node->right)
inorder_traverse (node->right);
}
As it turns out, to implement them non-recursively, you have to
maintain your own stack to preserve state: this is handled implicitly
by the recursive version, with the call stack serving the same
purpose. Writing a non-recursive version of this code is not trivial,
as my fellow-student found out -- and in fact, the problem is much
harder to solve iteratively than it is recursively.
So let us postulate two programming languages -- we'll call them F and
P. F only allows iterative programming; recursion is not allowed.
(Don't even think of functional programming or object orientation.) P
allows both iteration and recursion (as well as other things that we
won't go into.)
The set of knowledge required to use F effectively is less than the
set of knowledge required to use P effectively. Writers and
maintainers of F code do not need to understand recursion at all; the
language simply does not allow it.
Now, everything you can do in F you can do in P, plus a number of
other things. A good programmer can choose to write iteratively or
recursively, as the situation demands -- but this means that
maintainers also need to understand both iteration and recursion in
order to maintain the code.
"Ah," you say, "but a good programmer should be able to translate
their favourite idioms freely between paradigms." And yes, that is
the case -- but a 10-line recursive in P, trivial to debug, turns into
a 100-line program in F. If we accept the notion that the number of
bugs in an average program is likely to increase as the number of
lines in the program increases, that's a significant reason for the
good programmer to use P.
To take a more concrete example: consider trying to apply object
orientation to C. You can get a reasonable approximation of run-time
type inference, but it requires you to do all type checking by hand,
and the compiler offers you no help. It is obviously and
self-evidently true that a good programmer can do that, but it
requires an attention to detail. A good programmer would design a
tool to help him do it -- and lo, there are Objective-C and C++.
So, in short, I think your basic premise is valid -- that a good
programmer can work around differences in paradigms and idioms -- but
that it fails to take into account differences in productivity. If
there weren't value in different languages, we'd all be working in
FORTRAN and LISP, and we'd never have seen Algol, Simula, BASIC, C,
Smalltalk, C++, Objective-C, Eiffel, Perl, Visual Basic, Java, or PHP.
(Well, maybe there's something to be said for sticking to older
languages and paradigms....)
Charlton
------------------------------
Date: 12 May 2003 15:41:18 +0100
From: Phillip Lord <p.lord@russet.org.uk>
Subject: Re: Bloody Java Proselytisers!!!
Message-Id: <vfr874qlbl.fsf@rpc71.cs.man.ac.uk>
>>>>> "Charlton" == Charlton Wilbur <cwilbur@mithril.chromatico.net> writes:
Charlton> Phillip Lord <p.lord@russet.org.uk> writes:
>> Personally I would argue that being restricted to one paradigm is
>> less of a problem for a good programmer, as a good programmer
>> should be able to translate their favourite idioms freely between
>> paradigms.
Charlton> Idioms don't translate freely between paradigms. That's
Charlton> what makes them idiomatic.
My use of English here was poor.
A good programmer should be able to translate a unit of functionality
between the idioms of different languages. So while I can not
translate "pull your finger out", freely, I can say "get your ass into
gear", or "get your stick on the ice".
Charlton> When I was an undergraduate, one of my fellow-students
Charlton> insisted on implementing binary trees non-recursively.
There's always one isn't there....
Charlton> The set of knowledge required to use F effectively is less
Charlton> than the set of knowledge required to use P effectively.
Charlton> Writers and maintainers of F code do not need to
Charlton> understand recursion at all; the language simply does not
Charlton> allow it.
Charlton> Now, everything you can do in F you can do in P, plus a
Charlton> number of other things. A good programmer can choose to
Charlton> write iteratively or recursively, as the situation demands
Charlton> -- but this means that maintainers also need to understand
Charlton> both iteration and recursion in order to maintain the
Charlton> code.
Charlton> So, in short, I think your basic premise is valid -- that
Charlton> a good programmer can work around differences in paradigms
Charlton> and idioms -- but that it fails to take into account
Charlton> differences in productivity.
I think that your argument is cogent also, but it's flawed. I am
arguing that a limitations in a language can be a good thing. I am not
arguing that all limitations are good things however.
Any language needs to steer a course between expressivity, and
simplicity. Perl, C, are examples of "everything and the kitchen sink"
languages. They are very expressive, but extremely complex. Perl is
particularly so in this case, because as well as being semantically
complex (with several different ways to implement things), its also
syntactically complex (with several different ways to express
semantically identical constructs).
Now, of course, if you make a languages overly simple, then it's hell
to use, and the programmer ends up doing things in an extremely
complex way.
For example I wrote some XSLT a while back. In pseudocode I found
myself writing something like this....
sort( things, comparitor )
{
// do some sorting
// compare two objects
int result;
if( comparitor = "alphabetic" ){
result = compare_alphabetic( a, b );
}
if( comparitor = "numeric" ){
result = compare_numeric( a, b );
}
// and so on....
// do some more sorting
}
Dreadful eh? The problem is that XSTL does not provide first class
functions. So I had to write something as abysmal as this, to get
somewhere close to a polymorphic function.
Now, of course, this code is hard to read, to maintain, and not
extensible. In short, its terrible. But the language forced me into
it, honest guv!
Java does force the programmer to prefer one paradigm (object
orientation) over another. But, nowadays, OO is well known, fairly
well understood. A good programmer would, I would argue, not feel
overly limited by this (in the way that they would by lack of
recursion). And it makes it easier for less good programmers, who can
operate with one thing that they are familiar with. Obviously if the
less good programmers have never done OO before then they are going to
have difficulties, but it will probably take less time to learn
because of the relative simplicity.
There is a judgement call here. Simple, can become simplistic
easily. Expressive can become overly confused. My own judgement is
that perl has got it wrong. I learnt it, but gods it was an uphill
struggle, and there is still much perl out there that I have a hard
time understanding. Yes there are times that I miss the
expressivity. But almost only when I am writing code, not when I am
reading someone else's.
Phil
------------------------------
Date: Mon, 12 May 2003 17:27:53 GMT
From: Charlton Wilbur <cwilbur@mithril.chromatico.net>
Subject: Re: Bloody Java Proselytisers!!!
Message-Id: <87r874dqw7.fsf@mithril.chromatico.net>
Phillip Lord <p.lord@russet.org.uk> writes:
> Any language needs to steer a course between expressivity, and
> simplicity. [...] Now, of course, if you make a languages overly
> simple, then it's hell to use, and the programmer ends up doing
> things in an extremely complex way.
That's the crux of the problem.
> Java does force the programmer to prefer one paradigm (object
> orientation) over another. But, nowadays, OO is well known, fairly
> well understood. A good programmer would, I would argue, not feel
> overly limited by this (in the way that they would by lack of
> recursion). And it makes it easier for less good programmers, who
> can operate with one thing that they are familiar with.
Exactly.
The issue down at the bottom of it all is that this tradeoff --
expressivity versus simplicity -- comes out differently at different
skill levels. The toolset that's appropriate for an expert is not
appropriate for a beginner, and vice versa. But as an expert (or at
least an aspiring expert), I want the richest and most diverse set of
tools I can have: I don't want to be limited to OO, or indeed to any
approach. This is one thing that Perl gets right -- but then, I don't
think Perl is a good language for the mediocre to average programmer,
and I'm still finding corners of the language that I haven't yet
explored.
Charlton
------------------------------
Date: Tue, 13 May 2003 05:44:21 +1000
From: "Sisyphus" <kalinabears@hdc.com.au>
Subject: Re: bootstrap
Message-Id: <3ebffaa5$0$9409@echo-01.iinet.net.au>
"Anno Siegel" <anno4000@lublin.zrz.tu-berlin.de> wrote in message
news:b9nn67$oh0$1@mamenchi.zrz.TU-Berlin.DE...
> Sisyphus <kalinabears@hdc.com.au> wrote in comp.lang.perl.misc:
> > Hi,
> > I note that some modules (extensions) contain:
> > bootstrap This_Module;
> > while others contain:
> > bootstrap This_Module $VERSION;
> >
> > What determines whether the "$VERSION" needs to be bootstrapped ?
>
> The bootstrap function itself doesn't use the $VERSION argument.
> In fact, bootstrap() does nothing more than do some (quite a bit of)
> preparation, and then call a function all XS modules must by convention
> define. This function is called with the same parameter list as
> bootstrap() itself. What it does with its parameters is entirely up
> to the programmer, there is nothing that can be said in general.
>
The "programmer" being the person who writes the code that use's C::Z (not
the person who wrote C::Z). Right ?
This would mean that a module author's sole purpose in bootstrapping
"$VERSION" would be to provide the user with a bootstrap parameter that the
user could use (in whatever way the user wanted).
> > (I built the PAR module with Compress-Zlib-1.14 installed on my computer
and
> > it worked fine. I then updated Compress-Zlib to version 1.19. After
that,
> > whenever I run any pp-built executable, I get the fatal error
> > "Compress::Zlib object version 1.14 does not match bootstrap parameter
> > 1.19....".
>
> So apparently Compress::Zlib checks the version it is supposed to
> build against the version actually found. Seems reasonable.
>
> > One way to fix that is to recompile PAR.
>
> That would be the correct way.
>
> > As an alternative, I tried altering the bootstrap in Zlib.pm from:
> > bootstrap Compress::Zlib $VERSION;
> > to:
> > bootstrap Compress::Zlib;
> >
> > I then rebuilt the ("Hello world") executable with pp - but it produced
an
> > error when I ran the executable. It was difficult to tell just what that
> > error was because it also crashed the computer, and I didn't have time
to
> > read the error message. As a result of that crash I deduce that the
> > inclusion of "$VERSION" in the bootstrap command is of some
significance -
> > hence my question.)
>
> Well, it looks like the versions of Compress::Zlib are in actual
> fact incompatible. No use cheating...
>
Well ..... it's behaving as though C::Z is not *backward* compatible, and I
don't think that's the case.
I now think it might come down to the way the PAR author is (possibly
inadvertently) making use of that bootstrap parameter.
This annoying little quirk has been a feature of PAR for some time now on
Win32, but on other operating systems it's not an issue.
This will be fixed with the next release of PAR - and it's an area that I
didn't really want to pursue here. I was mainly wondering why "$VERSION" had
been bootstrapped in the first place.
I think you've answered that - it just remains to be seen if I've understood
the answer correctly :-)
Thanks Anno.
Cheers,
Rob
------------------------------
Date: 12 May 2003 14:59:09 -0700
From: tivolinewbie@canada.com (Kenjis Kaan)
Subject: CGI.pm buffer overflow security??
Message-Id: <6a8ba9f8.0305121359.4080d37f@posting.google.com>
As a user of the CGI.pm module, I am wondering if the module has any
builtin check against incoming parameter data?
my $cgiPtr = new CGI;
my $incomingParamData = $cgiPtr->param('SomeTextArea')
Does CGI.pm validate the data taht is coming up through 'SomeTextArea'
or not? or do we have to do the validation ourselves?
I am of course thinking of attacks such as buffer overflows. TIA
------------------------------
Date: Mon, 12 May 2003 18:00:58 +0000
From: Mario542 <member17678@dbforums.com>
Subject: Re: changing the date
Message-Id: <2869618.1052762458@dbforums.com>
Originally posted by Steffen Beyer
> "Mario542" wrote:
> >
> > Does anyone know if there is a way to change the date to the
> following
> > day after someone enters it in a web form? I'm trying to get
> info from a
> > date to another using the between command. If I enter 1.2.03 to
> 1.5.03
> > it gives me the total for 1.2.03 to 1.4.03 instead of 1.5.03
> because of
> > the between command. What I would like to do is, if someone
> enters
> > 1.5.03 I would like to change it to 1.6.03 before running the
> execute
> > command. The first date would be entered in $name and the second
> date
> > would be entered in $second. Here is my script.
> > Thanks,
> > Mario
>
> I'm not sure what you need, but you should probably have
> a look at Perl's extensive documentation:
>
> perldoc -q date
> perldoc -q yesterday
> perldoc perlfaq4
>
> Besides that, the module Date::Calc allows you to add
> a month, a day or whatever very easily:
>
> #!perl -w
>
> use strict;
> use Date::Calc qw(:all);
>
> my(@date) = (2003,4,17);
>
> my(@tomorrow) = Add_Delta_Days(@date, +1);
> my(@yesterday) = Add_Delta_Days(@date, -1);
> my(@nextmonth) = Add_Delta_YM(@date, 0,+1); # truncates day of
> month if necessary
> my(@nxtmonwrp) = Add_Delta_YMD(@date, 0,+1,0); # wraps into following
> month if necessary
>
> etc.
>
> (Truncation/wrapping occurs when the day of month, e.g. 31,
> does not exist in the month you end up with - e.g. February.
> Truncation simply sets the day of month to 28 or 29 instead
> (in this example), and wrapping would result in March 2nd or
> 3rd - depending on the resulting year being a leap year or not.)
>
> Hope this helps.
>
> Cheers,
> Steffen
Steffen,
after I change the date using
use Date::Calc qw(:all);
my(@date) = (2003,4,17);
my(@tomorrow) = Add_Delta_Days(@date, +1);
it looks like (2003 4 18) which works fine. Do you know if there is a
way to add periods to the date like 2003.4.18 so that it can be used in
a database query?? Thanks for all the help
--
Posted via http://dbforums.com
------------------------------
Date: Mon, 12 May 2003 08:20:09 -0500
From: Barry Kimelman <barryk2@SPAM-KILLER.mts.net>
Subject: Re: check IP address
Message-Id: <MPG.19295b83d37579249897c8@news.mts.net>
[This followup was posted to comp.lang.perl.misc]
In article <b9m6go$l1c$1@lust.ihug.co.nz>, Hugo (farmers@ihug.com.au)
says...
> Hi,
>
> I am trying to write a perl script to check if the ip address is match the
> one in a file.txt e.g. 192.12.2.1. The code I use is:
>
> if ($ARGV[0] != $newhash{$hostname}) {print "something here"}
>
> However, the code checks anything up to 192.1 and it doesn't matter what you
> type after that i.e. it says 192.12sadasdsadb is the same as 192.12.2.1
> ??????
>
> Can anyone fix this?
192.12.2.1 is not a valid numeric quantity, therefor you should use a
string comparison as follows :
if ($ARGV[0] ne $newhash{$hostname}) {print "something here"}
--
---------
Barry Kimelman
Winnipeg, Manitoba, Canada
email : bkimelman@hotmail.com
------------------------------
Date: Mon, 12 May 2003 20:44:07 +0200
From: "Nico Coetzee" <abuse@mweb.co.za>
Subject: Re: command interface (not a shell)
Message-Id: <pan.2003.05.12.18.44.06.592710@mweb.co.za>
If you were in a shell, you could execute many other programs/scrips, but
with the command interface, you can only execute what it let's you,
ussualy by means of a menu system, or simplified prompt.
Cheers
On Sun, 11 May 2003 22:08:44 +0000, Sam Jesse wrote:
> Hello
> I was reading the Description of cpan - easily interact with CPAN from the
> command line. it says This "script provides a command interface (not a
> shell) to CPAN.pm." sorry for the novice question. what is the differenc
> between a comand interface and a shell? is he talking about command
> interface on a C: prompt vs. shell on unix? I am very green in this thing
>
> Sam
--
Nico Coetzee
http://www.itfirms.co.za/
http://za.pm.org/
http://forums.databasejournal.com/
To the systems programmer, users and applications serve only to provide a
test load.
------------------------------
Date: Mon, 12 May 2003 10:42:08 -0400
From: Chris Fowler <cfowler@linuxiceberg.com>
Subject: Compiler perl
Message-Id: <1052750517.788059@minime.linuxiceberg.com>
I have configured perl using ./confgure.gnu --prefix=/usr
I want 'make install' to install in /tmp/root. When it
gets done, ther perl binary would be in /tmp/root/usr/bin/perl.
How can I get make install to do this and not try to install
in /usr? I've tried 'make prefix=/tmp/root install'
------------------------------
Date: Mon, 12 May 2003 20:39:35 +0200
From: "Nico Coetzee" <abuse@mweb.co.za>
Subject: Re: Compiler perl
Message-Id: <pan.2003.05.12.18.39.34.936@mweb.co.za>
You need to set this parameter during the configure stage:
./confgure.gnu --prefix=/tmp/root
or something similar. If you are on an RPM based system, like RedHat or
Mandrake, you can get the source RPM and do:
# rpmbuild --root /tmp/root --rebuild <perl-src-rpm>
OR, with the normal RPM:
# rpm -Uvh --root /tmp/root <perl-rpm(s)>
Cheers
On Mon, 12 May 2003 10:42:08 -0400, Chris Fowler wrote:
> I have configured perl using ./confgure.gnu --prefix=/usr
>
> I want 'make install' to install in /tmp/root. When it
> gets done, ther perl binary would be in /tmp/root/usr/bin/perl.
> How can I get make install to do this and not try to install
> in /usr? I've tried 'make prefix=/tmp/root install'
--
Nico Coetzee
http://www.itfirms.co.za/
http://za.pm.org/
http://forums.databasejournal.com/
To the systems programmer, users and applications serve only to provide a
test load.
------------------------------
Date: Mon, 12 May 2003 15:11:32 -0400
From: Chris Fowler <cfowler@linuxiceberg.com>
Subject: Re: Compiler perl
Message-Id: <1052766681.745450@minime.linuxiceberg.com>
Nico Coetzee wrote:
> You need to set this parameter during the configure stage:
>
> ./confgure.gnu --prefix=/tmp/root
The reason I want to use /tmp/root is so I can tar it up
for a distribution.
If I set the prefix to /tmp/root, then the perl binary will
look for modules in /tmp/root/usr/lib/perl5/5.8.0/....
I want to build for a prefix of /usr, but I want to instlal in
/tmp/root.
>
> or something similar. If you are on an RPM based system, like RedHat or
> Mandrake, you can get the source RPM and do:
>
> # rpmbuild --root /tmp/root --rebuild <perl-src-rpm>
>
> OR, with the normal RPM:
>
> # rpm -Uvh --root /tmp/root <perl-rpm(s)>
>
> Cheers
>
> On Mon, 12 May 2003 10:42:08 -0400, Chris Fowler wrote:
>
>> I have configured perl using ./confgure.gnu --prefix=/usr
>>
>> I want 'make install' to install in /tmp/root. When it
>> gets done, ther perl binary would be in /tmp/root/usr/bin/perl.
>> How can I get make install to do this and not try to install
>> in /usr? I've tried 'make prefix=/tmp/root install'
>
------------------------------
Date: Mon, 12 May 2003 22:15:16 +0200
From: "Nico Coetzee" <abuse@mweb.co.za>
Subject: Re: Compiler perl
Message-Id: <pan.2003.05.12.20.15.15.858193@mweb.co.za>
I suggest you ask in a unix group. Unfortunately I'm not 100% sure how you
would do this, but there must obviously be a way.
Cheers
On Mon, 12 May 2003 15:11:32 -0400, Chris Fowler wrote:
> Nico Coetzee wrote:
>
>> You need to set this parameter during the configure stage:
>>
>> ./confgure.gnu --prefix=/tmp/root
>
> The reason I want to use /tmp/root is so I can tar it up
> for a distribution.
>
> If I set the prefix to /tmp/root, then the perl binary will
> look for modules in /tmp/root/usr/lib/perl5/5.8.0/....
>
> I want to build for a prefix of /usr, but I want to instlal in
> /tmp/root.
>
>>
>> or something similar. If you are on an RPM based system, like RedHat or
>> Mandrake, you can get the source RPM and do:
>>
>> # rpmbuild --root /tmp/root --rebuild <perl-src-rpm>
>>
>> OR, with the normal RPM:
>>
>> # rpm -Uvh --root /tmp/root <perl-rpm(s)>
>>
>> Cheers
>>
>> On Mon, 12 May 2003 10:42:08 -0400, Chris Fowler wrote:
>>
>>> I have configured perl using ./confgure.gnu --prefix=/usr
>>>
>>> I want 'make install' to install in /tmp/root. When it
>>> gets done, ther perl binary would be in /tmp/root/usr/bin/perl.
>>> How can I get make install to do this and not try to install
>>> in /usr? I've tried 'make prefix=/tmp/root install'
>>
--
Nico Coetzee
http://www.itfirms.co.za/
http://za.pm.org/
http://forums.databasejournal.com/
To the systems programmer, users and applications serve only to provide a
test load.
------------------------------
Date: Mon, 12 May 2003 21:06:29 GMT
From: Darren Dunham <ddunham@redwood.taos.com>
Subject: Re: Compiler perl
Message-Id: <p1Uva.38$h76.6557935@newssvr13.news.prodigy.com>
Chris Fowler <cfowler@linuxiceberg.com> wrote:
> Nico Coetzee wrote:
>> You need to set this parameter during the configure stage:
>>
>> ./confgure.gnu --prefix=/tmp/root
> The reason I want to use /tmp/root is so I can tar it up
> for a distribution.
> If I set the prefix to /tmp/root, then the perl binary will
> look for modules in /tmp/root/usr/lib/perl5/5.8.0/....
> I want to build for a prefix of /usr, but I want to instlal in
> /tmp/root.
If you're using the normal Configure script, it asks where you want to
install the binaries, independent of where the configured prefix is.
--
Darren Dunham ddunham@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
------------------------------
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.
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 V10 Issue 4974
***************************************
