[15747] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 3160 Volume: 9

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu May 25 11:05:31 2000

Date: Thu, 25 May 2000 08:05:17 -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: <959267116-v9-i3160@ruby.oce.orst.edu>
Content-Type: text

Perl-Users Digest           Thu, 25 May 2000     Volume: 9 Number: 3160

Today's topics:
        [ANNOUNCE] DBD::RAM 0.07 <jeff@vpservices.com>
    Re: Array Question (Lou Hevly)
        Attempt to free unreferenced scalar albert_wuersch@my-deja.com
    Re: Basic scripting question (Paul David Fardy)
    Re: Can't Knit Two Files Together <dan@tuatha.sidhe.org>
        CGI browser detection tiddlerdeja@my-deja.com
    Re: CGI browser detection (Bart Lateur)
    Re: CGI browser detection <tony_curtis32@yahoo.com>
    Re: CGI browser detection <Andreas.Kutschera2@bln.siemens.de>
    Re: CGI browser detection <randy@theoryx5.uwinnipeg.ca>
    Re: CGI browser detection <vandemen@yahoo.com>
    Re: cgi name-value pairs , special characters <flavell@mail.cern.ch>
        Directories created with the "nobody" username <ncharette@earthlink.net>
    Re: Directories created with the "nobody" username <jad9@po.cwru.edu>
    Re: email poser <bmb@dataserv.libs.uga.edu>
    Re: How to COPY a website (Malcolm Hoar)
        Is anything planned re: Perl error reporting? ajmayo@my-deja.com
    Re: Listing installed packages? <Andreas.Kutschera2@bln.siemens.de>
    Re: Listing installed packages? <jboesNOjbSPAM@qtm.net.invalid>
    Re: LWP::Simple problem <harley@cookspecialty.com>
    Re: LWP::Simple problem <rcorfiel@lucent.com>
    Re: LWP::Simple problem <rcorfiel@lucent.com>
    Re: Mysql Perl DBI/DBD <pvsubramanian@email.msn.com>
    Re: Newbie-- Sendmail <camerond@mail.uca.edu>
        Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)

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

Date: Thu, 25 May 2000 06:34:11 -0700
From: Jeff Zucker <jeff@vpservices.com>
Subject: [ANNOUNCE] DBD::RAM 0.07
Message-Id: <5kaX4.56979$g41.2379916@news-west.usenetserver.com>

A new version of DBD::RAM is ready and has been uploaded to CPAN.  It is
also available at

    http://www.vpservices.com/jeff/programs/dbd-ram.html

This is a major version with many changes and additions.  If you are at
all interested in the module,  please upgrade.

This module allows you to treat Perl data structures and many kinds of
files as databases and to access them via DBI and SQL commands including
the ability to search and sort on a flexible range of criteria as well
as ability to insert, delete and modify records and tables.  You do not
need an rdbms system or separate server to work with these databases. 
Supported file types include fixed-width record files, XML files, many
kinds of "delimited" files (Comma Separated Values, Tab and Pipe
"delimited" files, Name=Value .ini files, etc.), and user defined files
which can contain data structured in almost any format.  Support is also
included for MP3 music libraries and for accessing files remotely via
HTTP or FTP.

Changes to the current version include:

* Greatly expanded support for XML and for User-Defined formats

* Added export() method to allow saving tables directly to disk 
  files in many formats including CSV, Fixed-width and XML

* Expanded capabilities of continous file access with catalog()

* Added remote-file support via LWP for additional file formats

* Added ability to specify alternate field and record separator
  patterns

* Added convenience names TAB and PIPE to support shortcuts for 
  tab and pipe "delimited" files.

* Modified and standardized the import() syntax

* Greatly expanded POD documentation

Enjoy, and please send me your comments/suggestions/gripes, etc.

-- 
Jeff






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

Date: Thu, 25 May 2000 13:47:06 GMT
From: lou@visca.com (Lou Hevly)
Subject: Re: Array Question
Message-Id: <392d3d04.15249464@news.wanadoo.es>

Larry Rosler <lr@hpl.hp.com> wrote:

>Any string can be used as a hash key.  In the hash-index context or on 
>the left side of a =>, a string (bareword) that looks like an identifier 
>will be auto-quoted.

I think this might need to be emmended to "an *ASCII* string that
looks like an identifier". Even using locale, I've found that Perl
won't auto-quote non-ASCII characters in hash keys:

#!/usr/bin/perl -w
use strict;
use POSIX;
use locale;
POSIX::setlocale(POSIX::LC_ALL, "catalan");

my %hash = (València => 'Universitat de València');
print for keys %hash;
----
Unrecognized character \350 at C:\www\perl\modules\posix\locale.pl
line 7.

Quoting 'València' corrects the problem.

-- 
All the best,
Lou Hevly
lou@visca.com
http://www.visca.com


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

Date: Thu, 25 May 2000 14:01:59 GMT
From: albert_wuersch@my-deja.com
Subject: Attempt to free unreferenced scalar
Message-Id: <8gjbob$8go$1@nnrp1.deja.com>

context:
killing a child as a consequence of an alarm timeout. But before,
a USR1 Signal is sent to itself. Under solaris perl5.6.0 the code:
local $SIG{ALRM} = sub { kill 'USR1', $$; exit(0);};
rises the message:
'Attempt to free unreferenced scalar'

BUT doing the same like this:
local $SIG{ALRM} = sub { kill 'USR1', $$; kill 'KILL', $$;};
rises no message.

Does anybody know what's wrong the way I use exit? Thanks for any Help.
Albert Wuersch


Sent via Deja.com http://www.deja.com/
Before you buy.


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

Date: 25 May 2000 14:15:23 GMT
From: pdf@morgan.ucs.mun.ca (Paul David Fardy)
Subject: Re: Basic scripting question
Message-Id: <8gjchr$2j2$1@coranto.ucs.mun.ca>

"Godzilla!" <godzilla@stomp.stomp.tokyo> writes:
> On strict and warnings, yes, for me they are but an annoyance.
> However, as I have said before, this is not to discount their
> value but rather to point to how they sometimes mislead or fail.
> My preference, needing reliability, is to code in my own warnings
> and error bail outs during testing. I trust my code and trust my
> errors. I do not trust pragma hints.  Someone else wrote those,
> someone I don't know and don't know of his or her skill and
> intent.

Then why are you using Perl at all?!  The same people that wrote and/or
vetted those very useful diagnostics you distrust, are the same people
that wrote and/or vetted the rest of the Perl compiler and (post-compile)
interpreter.  Even more people have contributed to the Perl standard
modules: have you replaced the entire set with your own code, so you
can trust that?  Have you replaced Perl's executable with one you
wrote yourself?

Ahah!  We have it!  The beast is running its own Perl, one that it
wrote itself and so can trust.  Of course, the rest of us have seen
enough to know that its code can't be trusted, even if we didn't know
its "perl" was broken (e.g. it doesn't support "perl -ne").

Paul Fardy (japh)
-- 
Paul David Fardy             | Computing and Communications
Systems Administrator        | Memorial University of Newfoundland
e-mail: pdf@mun.ca           | St. John's, NF  A1C 5S7     CANADA


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

Date: Thu, 25 May 2000 14:28:13 GMT
From: Dan Sugalski <dan@tuatha.sidhe.org>
Subject: Re: Can't Knit Two Files Together
Message-Id: <1MaX4.93427$hT2.386622@news1.rdc1.ct.home.com>

The man who would be Gojira <godzilla@stomp.stomp.tokyo> wrote:

> Some thoughts on this and please correct me
> if I am offbase.

Just as an advanced warning, you very much are mistaken in your
assumptions of what's going on.

> I am thinking along the line
> of what an F operator does during a file open,
> and applying this, perhaps incorrectly, to the
> mechanics of file opening. When Perl opens a 
> file for a read, its contents are dumped into
> the core process. Use of 'while' causes Perl 
> to mechanically split the file apart into single 
> lines, then read them into program processing, 
> one at time. Later, a program reassembles those
> lines. Seems, in many but not all circumstances,
> slurp would be more efficient by not forcing
> Perl to mechanically dissect a file for one
> line at a time input, if I have this mechanical
> process understood correctly.

You haven't. The <> operator reads in line by line (or record by record,
if you've set $/ to record-read mode). It must, of course--the individual
elements of an array read in like:

  @foo = <FH>;

are lines, just the same as you get reading them via:

  while (<FH>) {
  }

They'd have to be, otherwise the program would function differently
depending on whether you read in the data line by line or in one slurp.

> If not, it does seem if Perl holds a file
> open, reading it one line at time while
> processing is taking place, there might
> be some risk in having a file open longer
> than needed?
 
No. The risk is the same. Your exposure is greater, but the risk is
identical.

> This would be circumstances
> for using lock / unlock as opposed to
> what some say, "Always use lock / unlock."

I say always use lock. If you're reading in a file that someone else might
be changing, then lock it. Always. Otherwise you may get crap data. If
your data is important enough to use, it's important enough to protect. If
it's not important enough to protect then you might as well just generate
random characters.

> I should qualify, I really know very little
> about the deep dark hidden secrets of the
> actual 'mechanics' of Perl within core. 

There aren't any. The code's not particularly simple, but neither has
anyone made any attempts to hide anything. Diving into the core code's not
a bad thing to do.

> I am surmising based on what I have read 
> over years pertaining to this notion.

Bad. Very bad. In general you (this is the generic you, rather than a
specific you) shouldn't do this. Humans inevitably make assumptions (and
I'm working on my assumption that you're human, despite the e-mail
address, as very few giant fire-breathing lizards post to Usenet) but you
should *not* put forth those assumptions as fact. You (this is the
specific you now) may well have been misled by other people doing this.

> I was told, more like 'commanded' to use
> while instead of slurping. This seems a
> bit irrational for a data base file well
> under one kilobyte, or even ten kilobytes.
> Might be slurp is faster for smaller files?

It may (and this is a *big* may) use less wall time, depending on the load
on the system. It will use more CPU time, however. For files of that size
you're operating pretty much completely out of OS and stdio buffers,
though, so odds are you'll actually run slower in both wall and CPU time.

> I understand your point on large files. If
> you are opening megabyte files, it would
> make sense to pull it in, a little at time,
> if this is actually what takes place, in
> a mechanical sense.

It is what happens.

> I don't benchmark

You should, definitely before making pronouncements of efficiency or
quality to the public. The Benchmark module is your friend here--it makes
benchmarking most things easy.

> but slurping seems to be
> a lot less effort, less coding, along with 
> less risk involved than using 'while'

Ummm... you're proposing this:

	@foo = <FH>;
	foreach my $line (@foo) {
	}

is less coding than this:

	while (my $line = <FH>)  {
	}

I think I'm missing something. If you're talking about this sort of thing:

	@foo = <FH>;
	for ($index = 0; $index < $#foo; $index++) {
	  my $line = $foo[$index];
	}

Then I'll *definitely* disagree. 

> which 
> can lead to a theoretical infinite loop, if 
> a slight syntax error is made. Slurping and
> a foreach tends to avoid this risk.

While with a filehandle won't lead to an infinite loop--it can't. Sure
some syntax errors may lead to program misbehaviour, but that's always the
case. That's why we all debug our programs before releasing them for use,
right? :)

> In an
> overall viewpoint, I suspect slurping is
> most appropriate for correct circumstances,
> as is 'while' for correct circumstances.

Sure. But I was only addressing this one particular circumstance. In this
case, file-slurp's decidedly suboptimal.

> To promulgate absolute non-use of slurp,
> seems very poor advice.

You're way over-generalizing here. Slurping in a file you'll be processing
line-by-line is a waste, and should be avoided, which is what I said. If
you'll be operating on the file in other ways (using the data multiple
times, skipping around a bunch, stuff like that) then slurping makes the
programming easier and less error prone. (Possibly faster too)

					Dan


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

Date: Thu, 25 May 2000 13:39:36 GMT
From: tiddlerdeja@my-deja.com
Subject: CGI browser detection
Message-Id: <8gjael$7fv$1@nnrp1.deja.com>

I'd like to use Perl for a CGI script which would detect the type of
browser a request has been made from and then return an apporpriate
response.

E.g. If I get a request from IE5 I'd like to return HTML
If I get a request from a WAP browser, I'd like to return WML.

Any information greatly appreciated.


Sent via Deja.com http://www.deja.com/
Before you buy.


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

Date: Thu, 25 May 2000 14:09:48 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: CGI browser detection
Message-Id: <393333a5.11263085@news.skynet.be>

tiddlerdeja@my-deja.com wrote:

>I'd like to use Perl for a CGI script which would detect the type of
>browser a request has been made from and then return an apporpriate
>response.
>
>E.g. If I get a request from IE5 I'd like to return HTML
>If I get a request from a WAP browser, I'd like to return WML.
>
>Any information greatly appreciated.

Check the value of $ENV{HTTP_USER_AGENT} in your script.

Both Netscape and Internet Explorer claim to be "Mozilla". MSIE 5 even
claims to be a Mozilla v.4. You definitely need to interpret the data
between parantheses. But that gets too far off-topic for this newsgroup.

-- 
	Bart.


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

Date: 25 May 2000 09:23:46 -0500
From: Tony Curtis <tony_curtis32@yahoo.com>
Subject: Re: CGI browser detection
Message-Id: <87zopehfnx.fsf@limey.hpcc.uh.edu>

>> On Thu, 25 May 2000 13:39:36 GMT,
>> tiddlerdeja@my-deja.com said:

> I'd like to use Perl for a CGI script which would detect
> the type of browser a request has been made from and
> then return an apporpriate response.

See "perldoc CGI", look for the user_agent() method.

> E.g. If I get a request from IE5 I'd like to return HTML
> If I get a request from a WAP browser, I'd like to
> return WML.

Browsers often lie though.  Some might even try not to
identify themselves.  Spam harvesters might pretend to be
Netscapes.   So while you can check for the agent's ID
don't forget it might be wrong.  Nor indeed, forget a
catchall for "other" browsers.

hth
t



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

Date: 25 May 2000 16:41:28 +0200
From: Andreas Kutschera <Andreas.Kutschera2@bln.siemens.de>
Subject: Re: CGI browser detection
Message-Id: <8gje2o$vh5$1@de1bc6hd.bln.siemens.de>

tiddlerdeja@my-deja.com writes:

>I'd like to use Perl for a CGI script which would detect the type of
>browser a request has been made from and then return an apporpriate
>response.

>E.g. If I get a request from IE5 I'd like to return HTML
>If I get a request from a WAP browser, I'd like to return WML.

>Any information greatly appreciated.

This is not a perl question, it's a CGI question.
As the CGI-Programmer's FAQ (http://www.webthing.com/tutorials/cgifaq.html)
tells you, just use the Environment variable HTTP_USER_AGENT
-- 
Andreas Kutschera, Siemens Business Services DS,     Tel. 030/386-28089
Nonnendammallee 101, D-13629 Berlin                  Fax  030/386-22934
email: Andreas.Kutschera2@bln.siemens.de
Hi, non-Spammers: My email address does NOT contain digits!


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

Date: 25 May 2000 14:46:58 GMT
From: Randy Kobes <randy@theoryx5.uwinnipeg.ca>
Subject: Re: CGI browser detection
Message-Id: <8gjed2$afo$1@canopus.cc.umanitoba.ca>

In comp.lang.perl.misc, tiddlerdeja@my-deja.com wrote:
> I'd like to use Perl for a CGI script which would detect the type of
> browser a request has been made from and then return an apporpriate
> response.

> E.g. If I get a request from IE5 I'd like to return HTML
> If I get a request from a WAP browser, I'd like to return WML.

Hi,
   With the necessary caveats mentioned in the other responses,
you may want to check out the HTTP-BrowserDetect distribution,
under $CPAN/authors/id/L/LH/LHS/ - this can also parse some
additional information from the browser that may be useful to you.

best regards,
randy kobes



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

Date: Thu, 25 May 2000 23:07:35 +0800
From: "Aaron" <vandemen@yahoo.com>
Subject: Re: CGI browser detection
Message-Id: <B3bX4.4339$c5.6855@newsfeeds.bigpond.com>

Best way I have seen for Browser Detection is an ASP(Active Server Pages)
module called "Browser Hawk" http://www.cyscape.com/products

Probably only viable for Win32 although ASP for Unix is now available
somewhere.

Definetely worth a look in my opinion ASP does a few things better then Perl
can and vice-versa using both can make life a lot easier.

Cheers

Aaron
<tiddlerdeja@my-deja.com> wrote in message
news:8gjael$7fv$1@nnrp1.deja.com...
> I'd like to use Perl for a CGI script which would detect the type of
> browser a request has been made from and then return an apporpriate
> response.
>
> E.g. If I get a request from IE5 I'd like to return HTML
> If I get a request from a WAP browser, I'd like to return WML.
>
> Any information greatly appreciated.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.




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

Date: Thu, 25 May 2000 15:33:05 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: cgi name-value pairs , special characters
Message-Id: <Pine.GHP.4.21.0005251531240.10338-100000@hpplus01.cern.ch>

On 25 May 2000, Eric Bohlman wrote:

> : <a href="dd.pl?n=21&c=AIDS/HIV&s=c">.
> 
> That's an invalid URL.  You need to escape the slash.  Use URI::Escape.

It's also an invalid HREF attribute value.  You need to HTML-ify the
ampersands.



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

Date: Thu, 25 May 2000 14:23:18 GMT
From: "Norm" <ncharette@earthlink.net>
Subject: Directories created with the "nobody" username
Message-Id: <qHaX4.2287$Q46.59071@newsread2.prod.itd.earthlink.net>

I have a script that creates directories for a web base application as
needed.

The problem is that those newly created directories get the username and
group name "nobody".

When I try to access information contained in those "nobody" directories
from a web browser it cannot be accessed or in some occasions I get a server
error.

Is there a way to code the directory creation in the Perl script to avoid
that perhaps by providing a username other than nobody or is this a server
configuration issue?

Oh mighty please give me a light as it is mighty dark in here!

Thank you,

Norm





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

Date: Thu, 25 May 2000 10:29:53 -0500
From: "John A. Dutton" <jad9@po.cwru.edu>
Subject: Re: Directories created with the "nobody" username
Message-Id: <392D46F1.72891493@po.cwru.edu>

Norm wrote:

> I have a script that creates directories for a web base application as
> needed.
>
> The problem is that those newly created directories get the username and
> group name "nobody".
>

You need to run Apache (which I assume you're using) as user www - in my
httpd.conf, I have two lines:

User www
Group #-1

That should do it for ya.

John



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

Date: Thu, 25 May 2000 10:59:01 -0400
From: Brad Baxter <bmb@dataserv.libs.uga.edu>
Subject: Re: email poser
Message-Id: <Pine.GSO.4.21.0005251057520.22571-100000@dataserv.libs.uga.edu>

On Thu, 25 May 2000, Elaine Ashton wrote:

> in article hhWW4.86486$h01.625659@news1.rdc1.mi.home.com, Clinton A. Pierce
> at clintp@geeksalad.org quoth:
> 
> > BTW, if you're a spammer: I hate you and you can die a slow, miserable death
> > and your unburied corpse can rot in a tropical sunshine while being eaten by
> > mongrel rabid dogs with tapeworms.
> 
> /me makes a note to make sure not to send clint more than 2 copies of any
> given email :) btw - I think maggots would pick the bones clean as tapeworms
> are parasites who feed on live hosts, not corpses.....
> 

"This is not spam."
       --spam

-- 
Brad



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

Date: Thu, 25 May 2000 12:58:53 GMT
From: malch@malch.com (Malcolm Hoar)
Subject: Re: How to COPY a website
Message-Id: <392d238a$0$220@nntp1.ba.best.com>

In article <0001bd14.ae6829a2@usw-ex0105-037.remarq.com>, CptLogic <chrisNOchSPAM@logitools.com.invalid> wrote:

>Hell, if you're still worried about it, you can ask the
>administrator of the caching site, or the guy sucking your site
>to please not do it. You may be surprised how compliant and nice
>they'll be about it.

Since a significant proportion of them are spammers scavaging
for e-mail addresses, I'm sure they'll be very "nice" about
adding your return address to their lists. 

>Chris. Who thinks that wget is a fantastic server migration
>tool.

It's a terrible tool if you have any SSI's, CGI's or other
forms of dynamic content etc. Personally, I'd say that 'tar'
was a fantastic server migration tool.

-- 
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar           "The more I practice, the luckier I get". |
| malch@malch.com                                     Gary Player. |
| http://www.malch.com/               Shpx gur PQN.                |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


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

Date: Thu, 25 May 2000 14:37:14 GMT
From: ajmayo@my-deja.com
Subject: Is anything planned re: Perl error reporting?
Message-Id: <8gjdqo$a6g$1@nnrp1.deja.com>

I am mightily impressed with Perl 5.6.0. The addition of Unicode is a
really excellent idea. I am wondering, though, how much longer it will
be before Perl error reporting gets overhauled. I have raised this
issue before but gotten an oddly unsympathetic response.

Specifically, it seems logical to simply report the line number in
error on the basis that you can just fire up vi and go to the line, so
that's what Perl does. Unfortunately this breaks down utterly and
completely when you deal with dynamically evaluated code, especially
code that is being created server-side in a Web environment. The 'line
number' is often meaningless, making it painful in the extreme to track
down the problem. If the evaluated code is at all complex (e.g when
using mod_perl) then debugging reduces to desk checking for syntax
errors and the inclusion of print statements. Surely we don't need to
go back 40 years to debug Perl code!

I believe Perl desperately needs contextual error reporting (at least
during the compile phase), similar to that provided by most compilers
and interpreters. Such as

use strict 'vars';
print $foo+1;
      ^ undeclared variable $foo

Consider the rather silly mistake made in this snippet of code

eval("print 1; .
"print 2;");

which results in the following

syntax error at err.pl line 2, near ""print"
  (Might be a runaway multi-line "" string starting on line 1)
Can't find string terminator '"' anywhere before EOF at err.pl line 2.

Now this is a silly example but in the real world tracking down that
sort of silly mistake in complex code, with dynamically evaluated code
that might well come from a web server, makes for a real hassle.

Whereas if Perl could report

eval("print 1; .
                 ^ missing string terminator
"print 2;");

then I submit finding this sort of thing would be a good deal easier.
I appreciate that Perl tried hard to explain its thinking here, but
imagine that this evaluated code was buried deep inside a whole bunch
of inter-module calls and so on. Now those line numbers become pretty
meaningless, so finding the error becomes much harder.

Since most other compilers and interpreters report errors in context,
why must Perl continue to be so different?. What do other people
think?. Is there any possibility Perl error reporting might be changed
in the foreseeable future?


As a comparison, let's let the Sun Java compiler loose on code with a
similar error

class hello {
public static void main(String[] args)
	{
	String s;
	s = "hello +
		"goodbye";
	}
}

as you see, the string is unterminated in the same way as it was with
the Perl code. And the compiler reports:-

test1.java:5: String not terminated at end of line.
        s = "hello +
            ^
test1.java:6: ';' expected.
                "goodbye";
^
2 errors

See what I mean. You get the same behaviour from the reference
Javascript compiler, too. Why must Perl march to the beat of a
different drum?



Sent via Deja.com http://www.deja.com/
Before you buy.


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

Date: 25 May 2000 16:38:07 +0200
From: Andreas Kutschera <Andreas.Kutschera2@bln.siemens.de>
Subject: Re: Listing installed packages?
Message-Id: <8gjdsf$vg3$1@de1bc6hd.bln.siemens.de>

Hardy Merrill <hmerrill@my-deja.com> writes:

>Is there a way to list all the "non"-standard(packages from CPAN that
>are not part of standard Perl distribution) Perl packages that are
>installed on your system?

Sure, use the CPAN module. An interactive way is
perl -MCPAN -e shell
cpan> autobundle

takes a snapshot of your system and puts it in
$CPAN::Config->{cpan_home}/Bundle
Okay, so it also includes standard modules, just grep -v them :-)
read the CPAN manpage, it might help.

AFAIK, there is no way to tell if a module came with the standard
distribution, since they are _modules_ and perl should be able to run
without them (they're just there because just about everybody wants
them :-)

ciao
-- 
Andreas Kutschera, Siemens Business Services DS,     Tel. 030/386-28089
Nonnendammallee 101, D-13629 Berlin                  Fax  030/386-22934
email: Andreas.Kutschera2@bln.siemens.de
Hi, non-Spammers: My email address does NOT contain digits!


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

Date: Thu, 25 May 2000 07:53:08 -0700
From: Mur <jboesNOjbSPAM@qtm.net.invalid>
Subject: Re: Listing installed packages?
Message-Id: <065beec0.6117f382@usw-ex0106-046.remarq.com>

In article <8gj6rf$4ql$1@nnrp1.deja.com>, Hardy Merrill
<hmerrill@my-deja.com> wrote:
>Is there a way to list all the "non"-standard(packages from
CPAN that
>are not part of standard Perl distribution) Perl packages that
are
>installed on your system?


Here's a handy tool that will let you look over the list of
installed ("in the path") modules as well as other information,
using your browser (so it's not as useful if you are at a
command prompt):

http://cgi.resourceindex.com/detail/03915.html



Jeff Boes//ICQ=3394914//Yahoo!=jeffboes//AOL IM=jboes
  //home=jboes@qtm.net//professional=mur@consultant.com

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!



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

Date: Thu, 25 May 2000 08:52:17 -0400
From: "Harley" <harley@cookspecialty.com>
Subject: Re: LWP::Simple problem
Message-Id: <8gj7ip$mng$1@tikehau.netreach.net>


> Smells like a firewall. Do you need to set up LWP to use a proxy, perhaps?
> Maybe you didn't need that last week, but maybe you do today. :-)

I have the same issue except I need to specifiy a user name and password to
get outside of the proxy for HTTP requests.  I read a bunch on LWP and proxy
but did not see anywhere to specifiy credentials to get outside of the
firewall.  Does LWP have a way to do this?  Thanks, harley.




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

Date: Thu, 25 May 2000 14:42:52 +0100
From: Richard Corfield <rcorfiel@lucent.com>
Subject: Re: LWP::Simple problem
Message-Id: <392D2DDC.8FE2FC35@lucent.com>

Richard Corfield wrote:
> 
> Hi,
> 
> I thought I would quickly write a short, simple bit of code this morning that
> reads URLs from a text file and then retrieves the web pages. I've done this
> before using:
> 
> $content = get $URL ;
> 
> ..and it worked fine then. However I ran into problems in that this time it
> wasn't retrieving the (different) web pages.


This seems to work for redirecting to the webpage that called the CGI for anyone
who's interested:

use LWP::UserAgent;

$ua = new LWP::UserAgent;
$ua->proxy(http  => 'http://proxy.server:8080') ; # Obviously yours might not be
8080

print "Content-Type: text/html\n\n";

$url = 'http://www.yahoo.com/'  # etc. etc.

my $req = new HTTP::Request ('GET', $url);
$page = $ua->request($req)->as_string;

$page =~ s/^.*<HTML/<HTML/si ;  # chopping off headers (there's prob. a better
way)

print $page;



Richard


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

Date: Thu, 25 May 2000 14:46:58 +0100
From: Richard Corfield <rcorfiel@lucent.com>
Subject: Re: LWP::Simple problem
Message-Id: <392D2ED2.153411A3@lucent.com>

Harley wrote:
> 
> > Smells like a firewall. Do you need to set up LWP to use a proxy, perhaps?
> > Maybe you didn't need that last week, but maybe you do today. :-)
> 
> I have the same issue except I need to specifiy a user name and password to
> get outside of the proxy for HTTP requests.  I read a bunch on LWP and proxy
> but did not see anywhere to specifiy credentials to get outside of the
> firewall.  Does LWP have a way to do this?  Thanks, harley.


Take a look at this: 

http://www.xray.mpe.mpg.de/mailing-lists/libwww-perl/1997-11/msg00082.html

A possible solution??

Richard


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

Date: Thu, 25 May 2000 06:27:56 -0700
From: "P.V.Subramanian" <pvsubramanian@email.msn.com>
Subject: Re: Mysql Perl DBI/DBD
Message-Id: <#lXXM0kx$GA.320@cpmsnbbsa09>

Hi Jeff,

    That worked. Thanks a lot.

PV

Jeff Zucker <jeff@vpservices.com> wrote in message
news:392CC220.B2A7990@vpservices.com...
> "P.V.Subramanian" wrote:
> >
> > Hi,
> >     I have
> >                 Perl:                     Active state perl 5.005_03
binary
> > build 522
> >                MySQL server    3.22.34 build for Win95/Win98
> >                PC                        Intel Pentium 133Mhz    running
> > Windows 98
> >  My question is where to get the Perl DBI and PerlDBD for mysql and  how
to
> > install in the PC.
>
> Your version of activePerl came with a program called PPM (perl package
> manager) and instructions on how to use it.  In most cases "ppm install
> DBI" and "ppm install DBD-mysql" should be all you need to do.  That
> will download and install the modules for you.  If it doesn't, looup up
> the documentation on PPM to see what you might need to tweak.
>
> --
> Jeff




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

Date: Thu, 25 May 2000 09:24:27 -0500
From: Cameron Dorey <camerond@mail.uca.edu>
Subject: Re: Newbie-- Sendmail
Message-Id: <392D379B.EAF4AB0D@mail.uca.edu>

Agi wrote:
> 
> Hello,theres
>   I want to sent a HTML file to someone using Perl.
>   Which module can achieve my goal ??
> 
>   ps.I'm new in Perl.

Are you working on Windows, as your headers suggest? If so, just read
the Activestate FAQ about sending mail from Winxx.

Finding the FAQ ->**on your hard disk through the start menu**<- will
help you infinitely more than just getting a quick answer to this
specific question.

Cameron


-- 
Cameron Dorey
Associate Professor of Chemistry
University of Central Arkansas
Phone: 501-450-5938
camerond@mail.uca.edu


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

Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.

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 V9 Issue 3160
**************************************


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