[18917] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 1112 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 11 18:10:43 2001

Date: Mon, 11 Jun 2001 15:10:21 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <992297421-v10-i1112@ruby.oce.orst.edu>
Content-Type: text

Perl-Users Digest           Mon, 11 Jun 2001     Volume: 10 Number: 1112

Today's topics:
    Re: is hash val an array or scalar? <ryantate@OCF.Berkeley.EDU>
    Re: is hash val an array or scalar? <ryantate@OCF.Berkeley.EDU>
    Re: is hash val an array or scalar? <bart.lateur@skynet.be>
    Re: is hash val an array or scalar? <ryantate@OCF.Berkeley.EDU>
    Re: is hash val an array or scalar? (Anno Siegel)
        Last Chance for Damian's Advanced OO Perl class <uri@sysarch.com>
        Limiting special characters <davsoming@lineone.net>
    Re: Limiting special characters (E.Chang)
    Re: Limiting special characters <pne-news-20010611@newton.digitalspace.net>
    Re: Limiting special characters <pne-news-20010611@newton.digitalspace.net>
    Re: Limiting special characters (Craig Berry)
    Re: Limiting special characters <davsoming@lineone.net>
    Re: Limiting special characters <davsoming@lineone.net>
    Re: MySQL or piped text (a bit OT) (Michel Dalle)
    Re: MySQL or piped text (a bit OT) <twanGEENSPAM@twansoft.com>
    Re: Net::IRC::DCC stopping transfer midway (Anno Siegel)
    Re: newbie question <jddp@tid.es>
    Re: put a block of HTML in my script <bart.lateur@skynet.be>
    Re: Script self-awareness in regards to location nobull@mail.com
    Re: Script self-awareness in regards to location <pne-news-20010611@newton.digitalspace.net>
    Re: Searching for a pattern starting from the end of a  <comdog@panix.com>
        Simplest code to test if web site is up? (B Wooster)
    Re: Simplest code to test if web site is up? <jblakey@frogboy.net>
    Re: Simplest code to test if web site is up? <pne-news-20010611@newton.digitalspace.net>
        sort on hash <jhall@ifxonline.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Mon, 11 Jun 2001 18:32:16 +0000 (UTC)
From: Ryan Travis Tate <ryantate@OCF.Berkeley.EDU>
Subject: Re: is hash val an array or scalar?
Message-Id: <9g32rg$1i91$1@agate.berkeley.edu>

Mark Jason Dominus <mjd@plover.com> wrote:
 | Hash values can't be arrays; they can only be scalars.  From the rest
 | of your post, it appears that some of your hash values are *references
 | to arrays*,

yes, this is correct. thanks for pointing out the distinction, if i
had made it earlier maybe i would have found the ref function on my
own. i plan to use it (ref) as you mentioned, thanks again.

cheers
r



------------------------------

Date: Mon, 11 Jun 2001 18:36:53 +0000 (UTC)
From: Ryan Travis Tate <ryantate@OCF.Berkeley.EDU>
Subject: Re: is hash val an array or scalar?
Message-Id: <9g3345$1i91$2@agate.berkeley.edu>

Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
 | Whether a subroutine returns an array or a list is a matter of
 | context, the sub doesn't have much say in that.  You could, of
 | course, return a plain scalar or an arrayref, depending.  But
 | that would only perpetuate the cumbersome distinction.

whether the sub is called in list context or not is immaterial in my
specific code. even if wantarray is false, i want to return a joined
list--a scalar--not the array itself. even if it is true, i still want
to return a scalar value.


 | There is even an official way to do this: See the ref function in
 | perldoc -f ref.  But I don't think you want to do that.

this is exactly what i want to do, actually. ;-)

 | If that's all, just deal with the scalars as one-element arrays.
 | join() does what you mean with a one-element list and returns the
 | single element unchanged.  That way your data could be uniformly
 | listrefs.

right, except i don't want to adapt all my data to this subroutine, i
want to adapt the subroutine to the data. not everything is a list,
and treating a scalar as an arrayref raises a warning (or exception or
something).

thanks anyway, i do appreciate your input.

cheers
r


------------------------------

Date: Mon, 11 Jun 2001 18:37:09 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: is hash val an array or scalar?
Message-Id: <ns3aitc29qnbvp65g39v47vigatig99479@4ax.com>

Ryan Travis Tate wrote:

>if the value corresponding to the key parameter is an array, i'd like
>the subroutine to return an array. if the keyed  value is a scalar,
>then a scalar should be returned. how can i do this?
>
>i have searched Deja and read my Camel, and the best i can come up
>with is to maybe run a regex on the scalar lookup, as in 
>return $hash{$key} unless $hash{$key} =~ m/^ARRAY\(/;
>return @{$hash{$key}};
>
>is there a better way to do this? some way to check the value type or
>to return the data in a type-agnostic way?

ref(). It will return nothing ("") if it's a plain scalar, but "ARRAY"
if it's an array ref (and "HASH" if it's a hash ref). If you're sure
there's nothing but scalars and array refs in there, just using ref() as
a boolean text will do.

	return ref($hash{$key})?@{$hash{$key}}:$hash{$key};

And there's nothing wrong with having a scalar (string) starting with
"ARRAY(".

-- 
	Bart.


------------------------------

Date: Mon, 11 Jun 2001 18:43:43 +0000 (UTC)
From: Ryan Travis Tate <ryantate@OCF.Berkeley.EDU>
Subject: Re: is hash val an array or scalar?
Message-Id: <9g33gv$1i91$3@agate.berkeley.edu>

Bart Lateur <bart.lateur@skynet.be> wrote a nice reply
Logan Shaw <logan@cs.utexas.edu> wrote a nice reply

thanks also bart and logan for your (swift) help ...



cheers
r


------------------------------

Date: 11 Jun 2001 18:49:53 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: is hash val an array or scalar?
Message-Id: <9g33sh$es3$2@mamenchi.zrz.TU-Berlin.DE>

[posting suoperceded]

According to Ryan Travis Tate  <ryantate@OCF.Berkeley.EDU>:
> i have a hash with values that are both arrays and scalars. i also
> have a subroutine that takes a single, arbitrary key and that,
> most of the time, will simply return the corresponding value from the
> hash.
> 
> if the value corresponding to the key parameter is an array, i'd like
> the subroutine to return an array. if the keyed  value is a scalar,
> then a scalar should be returned. how can i do this?

Whether a subroutine returns an array^W^W a scalar or a list is
a matter of context, the sub doesn't have much say in that.  You
could, of course, return a plain scalar or an arrayref, depending.
But that would only perpetuate the cumbersome distinction.

> i have searched Deja and read my Camel, and the best i can come up
> with is to maybe run a regex on the scalar lookup, as in 
> return $hash{$key} unless $hash{$key} =~ m/^ARRAY\(/;
> return @{$hash{$key}};
>
> is there a better way to do this? some way to check the value type or
> to return the data in a type-agnostic way?
 
There is even an official way to do this: See the ref function in
perldoc -f ref.  But I don't think you want to do that.

> i know type-checking is generally deprecated in perl, culturally if
> not technically. the context here is i have a subroutine doing lookups
> in a tied hash, coming up with a fallback if the lookup fails and then
> laying the data into the default val of an HTML textfield generated
> via CGI.pm. the scalar data i lay right in, the array data i will join
> before laying in. 
 
If that's all, just deal with the scalars as one-element arrays.
join() does what you mean with a one-element list and returns the
single element unchanged.  That way your data could be uniformly
listrefs.

> i'd like to be able to use the same subroutine
> whether i'm making a textfield for array or scalar data, but now i'm
> thinking about writing two different subroutines (my_textfield and
> my_textlistfield). that approach will actually give data type more
> prominence in my script, ironically, which is why i'd like to just put
> a type check right into the subroutine.

Well, see the way out?  Use lists for both cases.  Even if the single-
element case needs special treatment, you can always branch on the
number of elements.  You don't need type-checking to do that.

Anno



------------------------------

Date: Mon, 11 Jun 2001 21:41:04 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Last Chance for Damian's Advanced OO Perl class
Message-Id: <x7g0d6vgni.fsf@home.sysarch.com>


the advanced object oriented perl class in boston is almost full. it is
being taught by damian conway on tue-wed, july 10-11. for more info read
this page:

	http://www.sysarch.com/perl/OOP_class.html

there are 2 seats left open. if you want to attend this class you must
register soon or you won't be able to take it on the east coast until
next year.

uri

-- 
Uri Guttman  ---------  uri@sysarch.com  ----------  http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info:     http://www.sysarch.com/perl/OOP_class.html


------------------------------

Date: Mon, 11 Jun 2001 20:49:37 +0100
From: "David Soming" <davsoming@lineone.net>
Subject: Limiting special characters
Message-Id: <tia7qm8fjm8na9@corp.supernews.co.uk>

Hi,
I have a list of special characters in an if statement which I want to
disallow in my form:

if ($message =~ /(\$+|\?+|\|+|\(+|\)+|\[+|\]+|\{+|\}+|\^+|\*+|\.+|\<)/) {
   $errormessage = "Special caracters such as: ( $+ ) are forbidden. You
used one in the message field";
   &errorpage;
   die;
  }

Have I got it pretty much covered- any others worth including?
Also is it possible to limit the byte size and/or string length to prevent
malicious attacks?
Thanks for your thoughts.

--
David Soming
'Just a head-banger- doing what I do best'
______________




------------------------------

Date: Mon, 11 Jun 2001 20:12:47 GMT
From: echang@netstorm.net (E.Chang)
Subject: Re: Limiting special characters
Message-Id: <Xns90BDA5615A889echangnetstormnet@207.106.93.86>

"David Soming" <davsoming@lineone.net> wrote in
<tia7qm8fjm8na9@corp.supernews.co.uk>: 

> Hi,
> I have a list of special characters in an if statement which I want
> to disallow in my form:
[code snipped]
 > Have I got it pretty much covered- any others worth including?

The recommendation from CERT (see "How To Remove Meta-characters From 
User-Supplied Data In CGI Scripts" at 
http://www.cert.org/tech_tips/cgi_metacharacters.html) is to decide on 
a restricted set of characters that you will allow rather than try to 
anticipate all the ones that you need to remove.

> Also is it possible to limit the byte size and/or string length to
> prevent malicious attacks?

If you are CGI.pm to process your form input, you can set a maximum 
size on POSTings.  See http://stein.cshl.org/WWW/software/CGI/#dos in 
the codumentation.

-- 
EBC


------------------------------

Date: Mon, 11 Jun 2001 22:19:52 +0200
From: Philip Newton <pne-news-20010611@newton.digitalspace.net>
Subject: Re: Limiting special characters
Message-Id: <qf9aitkvp3hvnem9vhg5566h0ahkvnqv6k@4ax.com>

On Mon, 11 Jun 2001 20:49:37 +0100, "David Soming"
<davsoming@lineone.net> wrote:

> Hi,
> I have a list of special characters in an if statement which I want to
> disallow in my form:
> 
> if ($message =~ /(\$+|\?+|\|+|\(+|\)+|\[+|\]+|\{+|\}+|\^+|\*+|\.+|\<)/) {

If you just care whether any of those characters are seen, you can drop
the '+', since one question mark would (presumably) be as bad as
seventy-five question marks in a row. Also, since all your "special
characters" are, well, single characters, I would imagine a character
class would be more readable than lots of |'s and \'s:

    if ($message =~ /[$?|()\[\]{}^*.<]/) {

or even

    if ($message =~ tr/$?|()[]{}^*.<//) {

, using tr/// only for its counting properties.

> Have I got it pretty much covered- any others worth including?

That depends on what you're going to do with $message, doesn't it? For
example, if you want to stick it into a regular expression, then you may
wish to disallow characters which are special to the regex engine. If
you want to pass them to a shell commandline, you may with to disallow
characters which are special to the shell. If you want to write the
result as part of an HTML page, you may with to disallow characters
which are special in HTML. If you just want to write the string to a
file, then all characters are presumably valid.

So, what did you want to do with it that you thought excluding those
characters is a good idea?

Note: a better approach is probably to start of defining which
characters are safe, and then to disallow anything else, rather than
trying to come up with all possible "unsafe" characters and risk
forgetting one. So you might use:

    if ($message =~ /[^a-zA-Z0-9\n\t ]/) {

or

    if ($message =~ tr/a-zA-Z0-9\n\t //c) {

to disallow anything but letters, numbers, linefeed, tab, and space.

> Also is it possible to limit the byte size and/or string length to prevent
> malicious attacks?

Depends on where you get your string from. If it's from a form posted to
a CGI script, then $CGI::POST_MAX may be able to help you; see the CGI
documentation.

Cheers,
Philip
-- 
Philip Newton <nospam.newton@gmx.li>
That really is my address; no need to remove anything to reply.
If you're not part of the solution, you're part of the precipitate.


------------------------------

Date: Mon, 11 Jun 2001 22:21:01 +0200
From: Philip Newton <pne-news-20010611@newton.digitalspace.net>
Subject: Re: Limiting special characters
Message-Id: <90aait8grac2e6d1bu8qk9g4rdrpmt1m4b@4ax.com>

On Mon, 11 Jun 2001 22:19:52 +0200, Philip Newton
<pne-news-20010611@newton.digitalspace.net> wrote:

> Note: a better approach is probably to start of defining which
> characters are safe, and then to disallow anything else, rather than
> trying to come up with all possible "unsafe" characters and risk
> forgetting one.

See also E. Chang's post, which mentioned CERT's recommendation, which
is where I got the above from.

Cheers,
Philip
-- 
Philip Newton <nospam.newton@gmx.li>
That really is my address; no need to remove anything to reply.
If you're not part of the solution, you're part of the precipitate.


------------------------------

Date: Mon, 11 Jun 2001 20:53:21 -0000
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Limiting special characters
Message-Id: <tiabu1gks033d4@corp.supernews.com>

David Soming (davsoming@lineone.net) wrote:
: I have a list of special characters in an if statement which I want to
: disallow in my form:
: 
: if ($message =~ /(\$+|\?+|\|+|\(+|\)+|\[+|\]+|\{+|\}+|\^+|\*+|\.+|\<)/) {

Why match on all those one-or-more quantifiers?  One is enough to trigger
the condition, afer all.

Also, it's easier by far to do this using a character class rather than
alternation:

  if ($message =~ /([$?|()[\]{}^*.<])/) {

tr/// counting would be more efficient if you didn't need to report which
character had tripped the detector.

: Have I got it pretty much covered- any others worth including?

I usually prefer going at the problem from the other direction:  Determine
what the set of legal characters is, and test the string to make sure it
contains only those characters.  Otherwise you're left trying to enumerate
all the oddball characters, including non-printables and the like, which
is harder to do.

: Also is it possible to limit the byte size and/or string length to prevent
: malicious attacks?

Sure...just do something like

  die 'Go away HaX0R' if length $message > 1000;

-- 
   |   Craig Berry - http://www.cinenet.net/~cberry/
 --*--  "God becomes as we are that we may be as he is."
   |               - William Blake


------------------------------

Date: Mon, 11 Jun 2001 22:26:52 +0100
From: "David Soming" <davsoming@lineone.net>
Subject: Re: Limiting special characters
Message-Id: <tiadh11qngq048@corp.supernews.co.uk>

Thanks for the two links.
I agree it is a much better (safer) approach to specify what characters are
allowed as opposed to a long list of characters which are not. and as they
point out you could potentially and erroneously miss one or two!
However I'm new to perl (if it wasn't already obvious), and although I get
the gist of what its supposed to do - don't know how to implement the
example code from CERT into my program: Any quick solution available please
apart from reading up perldoc for a fortnight or more?

char   *percent_x(...)  ######No idea what this line is/does!        {
                {...}
            static char ok_chars[] = "1234567890!@%-_=+:,./\
        abcdefghijklmnopqrstuvwxyz\
        ABCDEFGHIJKLMNOPQRSTUVWXYZ";

                {...}

        for (cp = expansion; *(cp += strspn(cp, ok_chars)); /* */ ) #####Nor
this!
                *cp = '_';

                {...}


--
David Soming
'Just a head-banger- doing what I do best'
______________

> The recommendation from CERT (see "How To Remove Meta-characters From
> User-Supplied Data In CGI Scripts" at
> http://www.cert.org/tech_tips/cgi_metacharacters.html) is to decide on
> a restricted set of characters that you will allow rather than try to
> anticipate all the ones that you need to remove.
>
> > Also is it possible to limit the byte size and/or string length to
> > prevent malicious attacks?
>
> If you are CGI.pm to process your form input, you can set a maximum
> size on POSTings.  See http://stein.cshl.org/WWW/software/CGI/#dos in
> the codumentation.
>





------------------------------

Date: Mon, 11 Jun 2001 22:57:46 +0100
From: "David Soming" <davsoming@lineone.net>
Subject: Re: Limiting special characters
Message-Id: <tiafav7o8acd6b@corp.supernews.co.uk>



______________
"Philip Newton" <pne-news-20010611@newton.digitalspace.net> wrote in message
news:qf9aitkvp3hvnem9vhg5566h0ahkvnqv6k@4ax.com...
> On Mon, 11 Jun 2001 20:49:37 +0100, "David Soming"
> <davsoming@lineone.net> wrote:
>
> > Hi,
> > I have a list of special characters in an if statement which I want to
> > disallow in my form:
> >
> > if ($message =~ /(\$+|\?+|\|+|\(+|\)+|\[+|\]+|\{+|\}+|\^+|\*+|\.+|\<)/)
{
>
> If you just care whether any of those characters are seen, you can drop
> the '+', since one question mark would (presumably) be as bad as
> seventy-five question marks in a row. Also, since all your "special
> characters" are, well, single characters, I would imagine a character
> class would be more readable than lots of |'s and \'s:
>
>     if ($message =~ /[$?|()\[\]{}^*.<]/) {
>
> or even
>
>     if ($message =~ tr/$?|()[]{}^*.<//) {
>
> , using tr/// only for its counting properties.

Thanks- much easier!

>
> > Have I got it pretty much covered- any others worth including?
>
> That depends on what you're going to do with $message, doesn't it? For
> example, if you want to stick it into a regular expression, then you may
> wish to disallow characters which are special to the regex engine. If
> you want to pass them to a shell commandline, you may with to disallow
> characters which are special to the shell. If you want to write the
> result as part of an HTML page, you may with to disallow characters
> which are special in HTML. If you just want to write the string to a
> file, then all characters are presumably valid.
>
> So, what did you want to do with it that you thought excluding those
> characters is a good idea?
>
If I were a hacker breaking into my system I would know! but I'm not - so I
don't :-)
In other words Im not aware of what metacharacters to protect against.
I want  to write the result as part of an HTML page although '+' - I
appreciate is probably unnecessary and prefer the look of your simpler
method above- or better the solution below

> Note: a better approach is probably to start of defining which
> characters are safe, and then to disallow anything else, rather than
> trying to come up with all possible "unsafe" characters and risk
> forgetting one. So you might use:
>
>     if ($message =~ /[^a-zA-Z0-9\n\t ]/) {
>
> or
>
>     if ($message =~ tr/a-zA-Z0-9\n\t //c) {
>
> to disallow anything but letters, numbers, linefeed, tab, and space.
>
> > Also is it possible to limit the byte size and/or string length to
prevent
> > malicious attacks?
>
> Depends on where you get your string from. If it's from a form posted to
> a CGI script, then $CGI::POST_MAX may be able to help you; see the CGI
> documentation.
>
> Cheers,
> Philip
Thanks philip- some good info!




------------------------------

Date: Mon, 11 Jun 2001 19:59:38 GMT
From: michel.dalle@usa.net (Michel Dalle)
Subject: Re: MySQL or piped text (a bit OT)
Message-Id: <Kq9V6.28371$mR5.3259550@afrodite.telenet-ops.be>

In article <450aito12nhq1c9fr24490a8eogqlmfnfr@4ax.com>, Twan Kogels <twanGEENSPAM@twansoft.com> wrote:
[snip]
>Sound like the database is the choice for mine. Do you know if the
>connection times with perl dbi on a mysql is fast? Oh well, i think is
>should search google.com first before asking. Everybody who replied
>thanks for the support!
>
>Twan

Actually, I wouldn't put that much hope in reducing CPU load by
moving to an SQL database - at least not unless you change a
few other things as well.

If you switch to DBI access, you have to add the cost of
running the database, and the fact that you're connecting/dis-
connecting from the database for each request - which is
pretty inefficient.

From what you described, you have a fairly simple data model
(id, subject, message), so you won't really be taking advantage
of the fact that you can select efficiently on different criteria,
like date, author, thread, etc. with SQL.
An easier solution might be to simply split your file into a
(id,subject) file and separate (id,subject,message) files -
one per id, or one per x ids, or whatever.

But most likely, the biggest cost is not even in reading
or updating that one big file at all, but in launching a
separate process (CGI script) for each "message view".

You might consider using static pages for your messages
instead - that is after all the most efficient way to serve
webpages. Or, if you don't want to loose the flexibility of
generating pages on the fly, you should consider switching
to mod_perl, fastcgi, speedycgi, php, ... An additional
advantage there is that you can use persistent database
connections too, which makes using an SQL database
more attractive again.

In short, there's no single ideal solution - but you should
carefully think about what needs to be optimised first...
Switching databases might not be the most important
issue here.

HTH,

Michel.


------------------------------

Date: Mon, 11 Jun 2001 23:00:39 +0200
From: Twan Kogels <twanGEENSPAM@twansoft.com>
Subject: Re: MySQL or piped text (a bit OT)
Message-Id: <l9bait4gdjrjjfpls5es8ol8j02q8c2cpk@4ax.com>

On Mon, 11 Jun 2001 19:59:38 GMT, michel.dalle@usa.net (Michel Dalle)
wrote:


>of the fact that you can select efficiently on different criteria,
>like date, author, thread, etc. with SQL.
>An easier solution might be to simply split your file into a
>(id,subject) file and separate (id,subject,message) files -
>one per id, or one per x ids, or whatever.
>
>But most likely, the biggest cost is not even in reading
>or updating that one big file at all, but in launching a
>separate process (CGI script) for each "message view".
>
>You might consider using static pages for your messages
>instead - that is after all the most efficient way to serve
>webpages. 
<g> i just started that one week ago, its actually running (with
little bugs) on my local machine, i implented a javascript live
renderer (write html with javascript document.write()) so i could keep
control of the look of the page and get dynamic content with static
html pages.

>Or, if you don't want to loose the flexibility of
>generating pages on the fly, you should consider switching
>to mod_perl, fastcgi, speedycgi, php, ... An additional
>advantage there is that you can use persistent database
>connections too, which makes using an SQL database
>more attractive again.
Just readed article about mod_perl and it seems really good, it
integrates perl into the apache server. I'm hope my webmaster wants to
install it, although i need to change my scripts slightly then when i
understand it correct.

>
>In short, there's no single ideal solution - but you should
>carefully think about what needs to be optimised first...
>Switching databases might not be the most important
>issue here.
>
Thanks for the reply, i think i just finish my work on the static
pages feature and upload everything and the take a look at the CPU
load.

Twan


------------------------------

Date: 11 Jun 2001 18:35:56 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Net::IRC::DCC stopping transfer midway
Message-Id: <9g332c$es3$1@mamenchi.zrz.TU-Berlin.DE>

According to Weevil  <news@baxpace.com>:
> Hello,
> 
> Before I start, yes I am using Net::IRC. No I won't change module or write 
> my own. No I am not interested in any stupid suggestions like 'dont use 
> net::irc' or 'go to bed'.

Bad move, that intro.

Every Perl programmer with some experience, even everyone who has
followed this newsgroup for a few weeks, knows that Net::IRC has
a lot of problems, and that alternatives are available that deserve
consideration.  By dismissing this advice as stupid you have just
insulted the part of your readership that might be able to help you
most.

> Right, that done with here's the question:

Right.

Anno


------------------------------

Date: Mon, 11 Jun 2001 23:58:36 +0200
From: Juan Delgado <jddp@tid.es>
Subject: Re: newbie question
Message-Id: <3B253F0B.1E852E6B@tid.es>

But i have just installed 5.6.1 version and the warnings.pm file is in the
    /usr/local/lib/perl5/5.6.1
directory. It doesn't seem to be mixed. Is it correct to have a function like
this in that file:

sub import {
    shift;
    my $mask = ${^WARNING_BITS} ;
    if (vec($mask, $Offsets{'all'}, 1)) {
        $mask |= $Bits{'all'} ;
        $mask |= $DeadBits{'all'} if vec($mask, $Offsets{'all'}+1, 1);
    }
    ${^WARNING_BITS} = $mask | bits(@_ ? @_ : 'all') ;
}

Does {^ this make sense?, or could it be a transference problem. I don't
think it to be either but i'm quite lost in this perl world.

Lots of thanks
Juan

Anno Siegel wrote:

> According to Juan Delgado Díaz-Pache  <jddp@tid.es>:
> > Hi,
> >
> > I am new to this and using a commercial product i get this error:
> >
> > perl_eval_pv FAILED: syntax error at
> > /usr/local/lib/perl5/5.6.1/warnings.pm
> > line 306, near "{^"
> > syntax error at /usr/local/lib/perl5/5.6.1/warnings.pm line 311, near
> > "{^"
> > BEGIN failed--compilation aborted at /usr/local/lib/perl5/5.6.1/vars.pm
> > line 12.
> > BEGIN failed--compilation aborted at Perl/DmmPerl.pm line 7.
> >
> > I've edited the warnings.pm file and deleted the ^ chars and the error
> > disappear but i don't know if this is right or wrong, and i
> > am only putting the error of.
> >
> > Does anyone know what is happening?
>
> You are running an older version of Perl with warnings.pm in place.
> The ^ in ${^WARNING_BITS} is supposed to be there in warnings.pm,
> but it was a syntax error in earlier versions of Perl.  Also with
> earlier versions warnings.pm didn't exist, "use warnings" was dealt
> with internally.  It's probably worth a try to move warnings.pl
> out of the way and see if the error goes away.
>
> More importantly, you should check how this mixed installation
> happened and look for ways to undo its effect.
>
> Anno



------------------------------

Date: Mon, 11 Jun 2001 18:38:32 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: put a block of HTML in my script
Message-Id: <a34aits8at79i8dsodsg0jlnfrtnemnaop@4ax.com>

Anthony Peacock wrote:

>However, this is a Perl question not a sendmail question you would be
>better off asking this in the comp.lang.perl.misc newsgroup.

Sendmail? I've seen (and answered) this question in CIWAC.

-- 
	Bart.


------------------------------

Date: 11 Jun 2001 19:11:12 +0100
From: nobull@mail.com
Subject: Re: Script self-awareness in regards to location
Message-Id: <u9vgm23n0f.fsf@wcl-l.bham.ac.uk>

usted@cyberspace.org (dave) writes:

>    I was wondering if there is anyway that a script can know where it
> is (url/$0).

If it's a CGI script then this information is available as part of the
CGI API.  See the documentation of the Perl CGI module.

If it's not a CGI script the concept of URL does not apply.

>  I tried opening a socket and then getting the location
> or doing a lookup of localhost, but it always returns the local
> loopback.  Any ideas?

A lookup on localhost will always return localhost.

Remember that a machine may have serveral IP addresses.

If you open a socket to a remote address an then look at the local
address this will tell you the local address that is "nearest" to the
remote address you have tried.  The nearest address to loopback is
always loopback.

This has nothing to do with Perl.

Now, what is it you actually wanted to know?

-- 
     \\   ( )
  .  _\\__[oo
 .__/  \\ /\@
 .  l___\\
  # ll  l\\
 ###LL  LL\\


------------------------------

Date: Mon, 11 Jun 2001 22:07:50 +0200
From: Philip Newton <pne-news-20010611@newton.digitalspace.net>
Subject: Re: Script self-awareness in regards to location
Message-Id: <0s6aitgmhae1iin8ckbl4lhicsocq3dmkn@4ax.com>

On 11 Jun 2001 07:16:15 -0700, usted@cyberspace.org (dave) wrote:

> Hi,
>    I was wondering if there is anyway that a script can know where it
> is (url/$0).

The filesystem path? You should be able to use FindBin for that.

The IP address? If so, which IP address, for machines that have several?

Or what? (And why?)

Cheers,
Philip
-- 
Philip Newton <nospam.newton@gmx.li>
That really is my address; no need to remove anything to reply.
If you're not part of the solution, you're part of the precipitate.


------------------------------

Date: Mon, 11 Jun 2001 17:12:27 -0400
From: brian d foy <comdog@panix.com>
Subject: Re: Searching for a pattern starting from the end of a string????
Message-Id: <comdog-098899.17122711062001@news.panix.com>

In article <3B23908B.9B5808A4@aware.be>, pascal <pascal@aware.be> 
wrote:

> Bob Rock wrote:

> > is there a way to have Perl start searching for a given pattern from the end
> > of a string instead of the beginning of the same? If so could someone make
> > an example of the syntax to be used?

> why can't you put all the results in an array and then pop it?
> takes a lot of resources from your computer, but hey, who cares.

which results do you want to put in the array?

-- 
brian d foy <comdog@panix.com>
CGI Meta FAQ - http://www.perl.org/CGI_MetaFAQ.html
Troubleshooting CGI scripts - http://www.perl.org/troubleshooting_CGI.html



------------------------------

Date: 11 Jun 2001 11:35:58 -0700
From: b.wooster@usa.net (B Wooster)
Subject: Simplest code to test if web site is up?
Message-Id: <cb45ebcb.0106111035.34abf2a9@posting.google.com>

I've been looking at libwww and it can certainly
do what I need to - but is there some very simple
Perl code that can check if the web server at a
particular site is up?

I need this:

$site_is_up = &check_site("www.somesite.com");


I can use libwww to do a GET on http://www.somesite.com/
and if I get a valid page, I know the site is up and 
the web server is running, but can I do this some
other way, using standard Perl 5.004 libraries (so I don't
have to download any additional libraries)?

Another thing I considered (and rejected - for now):
1) call lynx -source, and check if a page got returned.
Or similarly, call some standard linux utility, to check
this.


------------------------------

Date: Mon, 11 Jun 2001 15:31:58 -0400
From: Jason Blakey <jblakey@frogboy.net>
Subject: Re: Simplest code to test if web site is up?
Message-Id: <J_8V6.248150$Z2.2855590@nnrp1.uunet.ca>

You could use the Expect.pm module, and see if you get a proper response on 
port 80...

Thanks,
jason



-- 

This email from jason blakey - jblakey@frogboy.net - http://www.frogboy.net
                 " The Luckiest Guy in the World "



------------------------------

Date: Mon, 11 Jun 2001 22:07:51 +0200
From: Philip Newton <pne-news-20010611@newton.digitalspace.net>
Subject: Re: Simplest code to test if web site is up?
Message-Id: <t08aito255ut6hiag8521019b1bf37lf16@4ax.com>

On 11 Jun 2001 11:35:58 -0700, b.wooster@usa.net (B Wooster) wrote:

> check if the web server at a particular site is up?

I presume you want to know whether the web server is serving pages (so
that a ping, for example, wouldn't help as it only tests the TCP/IP
stack and the firewalls in between you and the target host).

> I can use libwww to do a GET on http://www.somesite.com/

Or, better, a HEAD, which only returns the HTTP headers and not the
entire document.

> but can I do this some other way, using standard Perl 5.004 libraries

You could, but it probably wouldn't be much fun (get the IP address of
the host with gethostbyname, pack it, open a socket, speak HTTP over the
socket, analyse the response). Use libwww-perl; that's what it's there
for.

Oh, and Perl 5.004 is also slightly old. Is there a reason that prevents
you from upgrading to 5.005_03 or even 5.6.1?

Cheers,
Philip
-- 
Philip Newton <nospam.newton@gmx.li>
That really is my address; no need to remove anything to reply.
If you're not part of the solution, you're part of the precipitate.


------------------------------

Date: Mon, 11 Jun 2001 21:01:25 GMT
From: "John Hall" <jhall@ifxonline.com>
Subject: sort on hash
Message-Id: <FkaV6.41355$%a.2163841@news1.rdc1.sdca.home.com>


I want my array sorted by alpha, but it isn't;

@usrkeys = (sort { $a cmp $b} keys(%permdb) ) ;

Am I a big dummy?

http://moron.shutdown.com






------------------------------

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 1112
***************************************


home help back first fref pref prev next nref lref last post