[15944] in Perl-Users-Digest
Perl-Users Digest, Issue: 3357 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jun 14 18:16:36 2000
Date: Wed, 14 Jun 2000 15:16:05 -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: <961020964-v9-i3357@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Wed, 14 Jun 2000 Volume: 9 Number: 3357
Today's topics:
Re: Dumb question.. How to prompt the user and get the (Philip 'Yes, that's my address' Newton)
Re: Dumb question.. How to prompt the user and get the (Bart Lateur)
Re: Dumb question.. How to prompt the user and get the <rootbeer@redcat.com>
Re: Dumb question.. How to prompt the user and get the <lr@hpl.hp.com>
Re: Dumb question.. How to prompt the user and get the (Bart Lateur)
Re: Dumb question.. How to prompt the user and get the <lr@hpl.hp.com>
Re: Dumb question.. How to prompt the user and get the (Bart Lateur)
Re: Easy CGI question (Eric Bohlman)
Re: Easy CGI question <flavell@mail.cern.ch>
Re: Easy CGI question (Bart Lateur)
Re: Easy CGI question <flavell@mail.cern.ch>
Re: Encrypting / decrypting. <godzilla@stomp.stomp.tokyo>
Re: Extract filename from path? (Craig Berry)
Re: Extract filename from path? <lr@hpl.hp.com>
Re: Extract filename from path? (Craig Berry)
Re: File I/O problems <pratickm@my-Deja.com>
Re: File I/O problems <rootbeer@redcat.com>
Re: funny Documentation?? <rootbeer@redcat.com>
Re: Gif creation on the fly aaronp243@my-deja.com
Re: grep - a beginner question (Helgi Briem)
Re: help - redefined subroutine warning (David Krainess)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 14 Jun 2000 16:16:05 GMT
From: nospam.newton@gmx.li (Philip 'Yes, that's my address' Newton)
Subject: Re: Dumb question.. How to prompt the user and get the input.
Message-Id: <3947a770.206399953@news.nikoma.de>
On Wed, 14 Jun 2000 15:41:21 +0200, "Matt King" <mattking@techie.com>
wrote:
> You mean section 5 of perlfaq8, not section 5 of the FAQ. Anyway, I already
> used this. I even posted it above. I _do not_ want to use add-ins/add-ons.
> If Perl can't do this nativly, then it's time to reinspect the code. I can't
> think of any programming language that does not have the ability to do it
> nativly.
ANSI C. K&R C. Pascal. Java. COBOL. FORTRAN.
Reading character-at-a-time is machine dependent -- hence,
machine-independent languages cannot include support for this.
getch() is an extension to ANSI C; Borland has it, probably Microsoft,
too. But it ain't ANSI. (And in Borland's Turbo C of fond memory, you
had to #include <conio.h>, which isn't an ANSI header, either.)
> This is, to me, a MAJOR weekness in Perl (the inability to preform
> simple basic tasks).
Perl can't draw lines and colour individual pixels, either -- that's a
pretty basic task, too, but a machine-dependent one.
> But if it doesn't have the basic functionality that other
> languages do, how can one defend it?
Name me a language which has this feature natively, according to that
language's standard, or by it's _de facto_ standard implementation.
Mucho bonus points if it's a portable languages, not something platform
specific ā la Visual Basic (or assembler).
> Does Perl have a native way to get a single key stroke without the use of
> additional modules, like the C getch() routine?
No, it has not. You have to resort to external methods (ioctl, stty,
POSIX, etc.).
> This is a simple question,
> and I'm only looking for a simple answer. Like: No, Perl can't handle
> something as basic as press any key to continue, or press Y/N to answer the
> questions.
No, TTBOMK, Perl cannot do this.
> Or, Yes, this is the way you would do it on Active Perl for
> Win32, note that it will not work on other platforms.
Don't know whether ActivePerl has some special trick up it's sleeve
(probably somewhere in the Win32 module if it exists). But it's not part
of core Perl.
Cheers,
Philip
--
Philip Newton <nospam.newton@gmx.li>
If you're not part of the solution, you're part of the precipitate.
------------------------------
Date: Wed, 14 Jun 2000 16:49:53 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: Dumb question.. How to prompt the user and get the input.
Message-Id: <3948b74e.884237@news.skynet.be>
Matt King wrote:
>If Perl can't do this nativly, then it's time to reinspect the code. I can't
>think of any programming language that does not have the ability to do it
>nativly.
>Does Perl have a native way to get a single key stroke without the use of
>additional modules, like the C getch() routine?
Neither can C.
--
Bart.
------------------------------
Date: Wed, 14 Jun 2000 10:24:14 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: Dumb question.. How to prompt the user and get the input.
Message-Id: <Pine.GSO.4.10.10006141016590.5301-100000@user2.teleport.com>
Please put your replies after the quoted text, not before. Thank you.
On Wed, 14 Jun 2000, Matt King wrote:
> > > without using any ad-ins, how can I get a single key stroke with
> > > Active Perl on a Windows platform?
> >
> > Does section five of the FAQ answer your question? Some of the suggested
> > ways use add-ons, but no ad-ins! :-)
> You mean section 5 of perlfaq8, not section 5 of the FAQ.
No, I man section five of the FAQ, also known as perlfaq5. It has these
questions:
How can I read a single character from a file? From the keyboard?
How can I tell if there's a character waiting on a filehandle?
But maybe you say that because section eight has these:
How do I do fancy stuff with the keyboard/screen/mouse?
How do I get one key from the terminal at a time, under POSIX?
> Anyway, I already used this. I even posted it above. I _do not_ want
> to use add-ins/add-ons.
Don't be silly: Your own code is an add-on. A module is merely an add-on
which has been written, debugged, and packed up for your convenience. You
may as well say that you don't want any of that fancy store-bought food
because you're going to eat raw dirt.
Go install a module. You'll feel better. :-)
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Wed, 14 Jun 2000 10:37:59 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: Dumb question.. How to prompt the user and get the input.
Message-Id: <MPG.13b162d22f71e0098ab73@nntp.hpl.hp.com>
In article <3947a770.206399953@news.nikoma.de> on Wed, 14 Jun 2000
16:16:05 GMT, Philip 'Yes, that's my address' Newton
<nospam.newton@gmx.li> says...
> On Wed, 14 Jun 2000 15:41:21 +0200, "Matt King" <mattking@techie.com>
> wrote:
> > You mean section 5 of perlfaq8, not section 5 of the FAQ. Anyway, I already
> > used this. I even posted it above. I _do not_ want to use add-ins/add-ons.
> > If Perl can't do this nativly, then it's time to reinspect the code. I can't
> > think of any programming language that does not have the ability to do it
> > nativly.
>
> ANSI C. K&R C. Pascal. Java. COBOL. FORTRAN.
>
> Reading character-at-a-time is machine dependent -- hence,
> machine-independent languages cannot include support for this.
>
> getch() is an extension to ANSI C; Borland has it, probably Microsoft,
> too. But it ain't ANSI. (And in Borland's Turbo C of fond memory, you
> had to #include <conio.h>, which isn't an ANSI header, either.)
...
> > Does Perl have a native way to get a single key stroke without the use of
> > additional modules, like the C getch() routine?
>
> No, it has not. You have to resort to external methods (ioctl, stty,
> POSIX, etc.).
I am seriously confused.
ANSI/ISO C has functions setvbuf() to control buffering of a stream, and
in particular to set no buffering. It has functions fgetc(), getc(),
and getchar() to read a single character from an input stream. All this
is specified and supported portably.
Yet you (and Bart Lateur in another post) insist that C doesn't have
this capability.
I am seriously confused.
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Wed, 14 Jun 2000 18:23:37 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: Dumb question.. How to prompt the user and get the input.
Message-Id: <3948ccab.6353669@news.skynet.be>
Larry Rosler wrote:
>Yet you (and Bart Lateur in another post) insist that C doesn't have
>this capability.
>
>I am seriously confused.
To quote a fine tutorial:
<http://www.cs.cf.ac.uk/Dave/C/node3.html#SECTION00326000000000000000>
Using Libraries
C is an extremely small language. Many of the functions of other
languages are not included in C. e.g. No built in I/O, string
handling or maths functions.
What use is C then?
C provides functionality through a rich set function libraries.
As a result most C implementations include standard libraries of
functions for many facilities ( I/O etc.). For many practical
purposes these may be regarded as being part of C. But they may vary
from machine to machine.
Point is: this person complained that if Perl doesn't have this
functionality, without help from external libraries, it's a very poor
language. Well, in C, it's in a library too, not in a core language. A
standard library, granted, but a library nevertheless.
--
Bart.
------------------------------
Date: Wed, 14 Jun 2000 12:15:25 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: Dumb question.. How to prompt the user and get the input.
Message-Id: <MPG.13b179a88432895098ab79@nntp.hpl.hp.com>
In article <3948ccab.6353669@news.skynet.be> on Wed, 14 Jun 2000
18:23:37 GMT, Bart Lateur <bart.lateur@skynet.be> says...
> Larry Rosler wrote:
>
> >Yet you (and Bart Lateur in another post) insist that C doesn't have
> >this capability.
> >
> >I am seriously confused.
>
> To quote a fine tutorial:
One can argue about that characterization. :-)
> <http://www.cs.cf.ac.uk/Dave/C/node3.html#SECTION00326000000000000000>
>
> Using Libraries
>
> C is an extremely small language. Many of the functions of other
> languages are not included in C. e.g. No built in I/O, string
> handling or maths functions.
>
> What use is C then?
>
> C provides functionality through a rich set function libraries.
>
> As a result most C implementations include standard libraries of
> functions for many facilities ( I/O etc.). For many practical
> purposes these may be regarded as being part of C. But they may vary
> from machine to machine.
Twaddle. If the libraries are indeed 'standard libraries' (by which he
should mean 'documented in the ANSI/ISO C Standard', though his
awareness of the Standard is limited to one off-hand sentence), they may
*NOT* vary from machine to machine, except if so documented.
> Point is: this person complained that if Perl doesn't have this
> functionality, without help from external libraries, it's a very poor
> language. Well, in C, it's in a library too, not in a core language. A
> standard library, granted, but a library nevertheless.
Twaddle. According to that definition, all the
keywords/operators/builtins documented in perlfunc aren't part of the
Perl language either.
This is in fact an implementation detail. Nothing precludes an
implementor of C from parsing a 'library function call' into inline
code, provided the semantics of a function call are preserved (single
evaluation of arguments; call by value). In fact, inlining is done all
the time.
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Wed, 14 Jun 2000 21:13:14 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: Dumb question.. How to prompt the user and get the input.
Message-Id: <3947f503.312578@news.skynet.be>
Larry Rosler wrote:
> According to that definition, all the
>keywords/operators/builtins documented in perlfunc aren't part of the
>Perl language either.
Who said it wasn't so.
This person made a lot of noise of needing a "use Foo::Bar;" in order to
get the functionality he wants. Well, in C you need a
"#include <stdio.h>" in order to get it to compile. Same thing.
--
Bart.
------------------------------
Date: 14 Jun 2000 15:05:32 GMT
From: ebohlman@netcom.com (Eric Bohlman)
Subject: Re: Easy CGI question
Message-Id: <8i86vs$1tr$3@slb6.atl.mindspring.net>
Dan Sugalski (dan@tuatha.sidhe.org) wrote:
: If your server preprocesses what you send and fixes up the line endings,
: great. If the data from your program gets sent out without any
: processing, then bare linefeeds are wrong.
The latter can *only* happen when the server is calling your program in
NPH mode. If not, your program is *not* talking directly (HTTP) to the
user agent; it's talking to the server (CGI) in a language that
resembles, *but is not identical to*, the language that the server speaks
to the user agent. This seems to be a major conceptual problem for lots
of people, even though the evidence that the two languages aren't
identical is trivially observable (in that HTTP headers always include a
status code like 200, whereas non-NPH CGI headers never do).
------------------------------
Date: Wed, 14 Jun 2000 17:04:21 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Easy CGI question
Message-Id: <Pine.GHP.4.21.0006141656300.26251-100000@hpplus03.cern.ch>
On Wed, 14 Jun 2000, Dan Sugalski wrote:
> This is incorrect.
Right, because it was a misrepresentation of what Eric Bohlman had
correctly stated. Bloody trolls.
> The headers sent to the browser from the server must
> have carraige return linefeed pairs to be correct, per the HTTP spec and
> RFCs.
Yes, but we're not (directly) discussing the HTTP network protocol:
we're discussing the CGI (software interface between CGI process and
web server).
> Many browsers are tolerant of this incorrect behaviour because so
> many servers to it, but it doesn't make things any more correct.
True, but this is irrelevant, since CGI processes don't talk to a
browser - they talk to a web server (HTTPD), which in turn talks to
the client (browser etc.).
> If your server preprocesses what you send and fixes up the line endings,
> great.
Please don't muddy the waters like this. The CGI is a formal
specification: it states (as clearly as we need for the purposes of
this discussion) what is required of the CGI process.
> This is not, however, a perl issue, so I'll leave it be.
But this is infuriating. If you insist on discussing the issue here
at all, you should still get your facts right. Otherwise you should
refer to hon. readers to the appropriate specifications and leave it
at that.
best regards
------------------------------
Date: Wed, 14 Jun 2000 16:54:36 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: Easy CGI question
Message-Id: <394ab8ad.1235098@news.skynet.be>
Alan J. Flavell wrote:
>Please don't muddy the waters like this. The CGI is a formal
>specification: it states (as clearly as we need for the purposes of
>this discussion) what is required of the CGI process.
So why is it currently still at the RFC *draft* status?
--
Bart.
------------------------------
Date: Wed, 14 Jun 2000 19:37:02 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Easy CGI question
Message-Id: <Pine.GHP.4.21.0006141922001.26251-100000@hpplus03.cern.ch>
On Wed, 14 Jun 2000, Bart Lateur wrote:
> >Please don't muddy the waters like this. The CGI is a formal
> >specification: it states (as clearly as we need for the purposes of
> >this discussion) what is required of the CGI process.
>
> So why is it currently still at the RFC *draft* status?
I don't know the answer to that. Is that issue germane to the point
that we were discussing, i.e the question of what is allowed as a
newline representation across the CGI.out interface? It's my
contention that the extant CGI specification(s) cover this issue in
sufficient detail for the purposes that were being argued - albeit the
original NCSA version of the specification is somewhat too platform-
specific.
If you want me to guess? It's not clear that the CGI specification
(unlike the HTTP specification, RFC2616) needs to be an Internet RFC,
since it is _not_ an Internet specification as such, i.e it does not
specify an interface to the Internet. Indeed, the only CGI
implementations I have ever come across have involved a CGI process
running on the same machine as the HTTPD, i.e the communication has
never been cross-architecture. Nevertheless I welcome the prospect of
it being codified as an IETF RFC, and Ken Coar seems to have done a
good job on it, modulo the odd detail remaining to be tidied up.
ttfn
------------------------------
Date: Wed, 14 Jun 2000 11:40:50 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Encrypting / decrypting.
Message-Id: <3947D1B2.4ED4E58A@stomp.stomp.tokyo>
Matt King wrote:
> Godzilla! Can you contact me outside of this ng?
> I'd like to discuss this encryption/decryption
> thing without everyone hammering us. You apear to be
> able to best answer my questions....
Within one of my subsequent articles to this
one of yours, I advised you to send me email
directly from your parent server, this is,
via a valid email address. Along with this
advice I graciously afforded an explanation
indicating a need to sort you out from the
long time regulars here who routinely and
frequently cause problems via anonymous
remailers, otherwords, trolling via fake
email addresses for concealment.
mkingtp
mattking
internet-free.de --> ifree.mixx.net --> techie.com --> inamecorp.com
You have made a freewill choice to send me
email via a fake email address, a remailer,
contrary to my polite request to not do this.
I have deleted your email unread and will
afford you no further help on this topic.
Godzilla!
------------------------------
Date: Wed, 14 Jun 2000 16:57:56 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Extract filename from path?
Message-Id: <skfeckb8is450@corp.supernews.com>
Henrik Jönsson (henrik.jonsson@se.adtranz.com) wrote:
: I think I found a simpler solution myself:
:
: sub basename {
: my ($path) = @_;
: my (@fileList);
:
: @fileList = split(/\\|\//, $path);
: @fileList = reverse @fileList;
:
: return $fileList[0];
: }
Reasonable, but easy to express more compactly:
sub basename {
return (split m!/|\\!, shift)[-1];
}
--
| Craig Berry - http://www.cinenet.net/users/cberry/home.html
--*-- "Beauty and strength, leaping laughter and delicious
| languor, force and fire, are of us." - Liber AL II:20
------------------------------
Date: Wed, 14 Jun 2000 10:27:18 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: Extract filename from path?
Message-Id: <MPG.13b1604fd88fc4ae98ab72@nntp.hpl.hp.com>
In article <skfeckb8is450@corp.supernews.com> on Wed, 14 Jun 2000
16:57:56 GMT, Craig Berry <cberry@cinenet.net> says...
> Henrik Jönsson (henrik.jonsson@se.adtranz.com) wrote:
> : I think I found a simpler solution myself:
> :
> : sub basename {
> : my ($path) = @_;
> : my (@fileList);
> :
> : @fileList = split(/\\|\//, $path);
> : @fileList = reverse @fileList;
> :
> : return $fileList[0];
> : }
>
> Reasonable, but easy to express more compactly:
>
> sub basename {
> return (split m!/|\\!, shift)[-1];
> }
Or even more efficiently, should that matter (as I posted before):
m![/\\]!
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Wed, 14 Jun 2000 20:25:52 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Extract filename from path?
Message-Id: <skfqigd0is482@corp.supernews.com>
Larry Rosler (lr@hpl.hp.com) wrote:
: In article <skfeckb8is450@corp.supernews.com> on Wed, 14 Jun 2000
: 16:57:56 GMT, Craig Berry <cberry@cinenet.net> says...
: > Reasonable, but easy to express more compactly:
: >
: > sub basename {
: > return (split m!/|\\!, shift)[-1];
: > }
:
: Or even more efficiently, should that matter (as I posted before):
:
: m![/\\]!
Yep. Also you can omit my explicit 'return', a habit of mine which I find
helps me eyeball-parse subs more easily.
--
| Craig Berry - http://www.cinenet.net/users/cberry/home.html
--*-- "Beauty and strength, leaping laughter and delicious
| languor, force and fire, are of us." - Liber AL II:20
------------------------------
Date: Wed, 14 Jun 2000 09:17:31 -0700
From: "pratickm " <pratickm@my-Deja.com>
To: "comp.lang.perl.misc@list.deja.com" <comp.lang.perl.misc@list.deja.com>
Subject: Re: File I/O problems
Message-Id: <EMPLDFIKMDEIGBAA@my-deja.com>
Hello,
>> open(INFILE,"<$file");
>
>You should ALWAYS check for the success of an open() request.
The code was snipped for brevity.
I *am* checking for file existence and state (-e and -w).
>> $num=<INFILE>;
>
>That should read one 'line' from the file (i.e., up to and including the
>contents of $/, which is "\n" by default) into $num.
It does.
I seriously don't know what was wrong with the code.
I played around with it a bit, and now it is working.
I can read the file using <> as well as read.
>> The only syntax that is working is:
>> while($num=<INFILE>)
>> {
>> last;
>> }
>That too should read one 'line' from the file into $num, and exit the
>loop.
That is the workaround I was using.
Now the normal read and <> are working.
I was hoping someone can give me a clue as to why it was not working earlier.
Maybe the phase of the moon :-O
However, now I am having problems opening the file in write mode.
I am trapping the return value from open, but it is not displaying anything.
Code follows:
use CGI;
$creator=CGI::new();
print $creator->header();
print $creator->start_html(
-title=>'File opening modes',
-bgcolor=>'pink');
$file="e:\\inetpub\\wwwroot\\cgi-bin\\counter.txt";
if(-e "$file")
{
print "$file exists";
}
else
{
print "$file does not exist";
}
if(-w "$file")
{
print "$file is writable";
}
else
{
print "$file is not writable;"
}
$i=open(MYFILE,">$file");
print "i is: $i<br>";
print MYFILE ("test");
close MYFILE;
print $creator->end_html();
Can anyone help.
And thanks for the advice.
Really appreciated :-))
Regards,
Pratick
--== Sent via Deja.com http://www.deja.com/ ==--
Before you buy.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 14 Jun 2000 10:56:50 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: File I/O problems
Message-Id: <Pine.GSO.4.10.10006141051110.5301-100000@user2.teleport.com>
On Wed, 14 Jun 2000, pratickm wrote:
> >> open(INFILE,"<$file");
> >
> >You should ALWAYS check for the success of an open() request.
>
> The code was snipped for brevity.
> I *am* checking for file existence and state (-e and -w).
That doesn't mean that the open will succeed! Even when your script is
"just an example" (and perhaps especially in that case!) you should
_always_ check the return value after opening a file.
> However, now I am having problems opening the file in write mode.
> I am trapping the return value from open, but it is not displaying anything.
> $i=open(MYFILE,">$file");
> print "i is: $i<br>";
Well, of course it isn't! It'll be true upon success, and false upon
failure. False values aren't very informative, and the true value isn't
much better. How about this, although I wouldn't leave it in any
real-world program:
if ( open(MYFILE, ">$file") ) {
$i = "success";
} else {
$i = "failed to open '$file' for output: $!";
}
print "i is: $i<br>\n";
To be sure, you should entity-escape a string used for HTML output, but
I'll leave that for you to add later. :-)
Cheers!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Wed, 14 Jun 2000 10:05:09 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: funny Documentation??
Message-Id: <Pine.GSO.4.10.10006141002360.5301-100000@user2.teleport.com>
On Tue, 13 Jun 2000, Mike Engan wrote:
> This is an example where I am trying to set the STDOUT to be used by
> the system or exec. But the system call dumps to the server tty. not
> the client tty, and I would think, and want it to do.
> select($client); ### this sets my socket to the client
> *STDOUT = $client; ### as the default out, then I set
> ### STDOUT to the same file handle
I don't think that'll do it. Try duping the filehandle instead - see the
docs for open(). The child process will (normally) inherit filehandles 0,
1, and 2, not whichever ones Perl is using for STDIN, STDOUT, and STDERR,
although those would normally be the same.
Good luck with it!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Wed, 14 Jun 2000 15:15:32 GMT
From: aaronp243@my-deja.com
Subject: Re: Gif creation on the fly
Message-Id: <8i87i1$vjk$1@nnrp1.deja.com>
In article <8i7tvu$nt8$1@nnrp1.deja.com>,
phool@my-deja.com wrote:
> How to creat 2d graph using GifGraph perl module? Any other solution
for
> plotting 2d graph in perl. I want to write a cgi program which takes
> data from a data file and plot a graph in any image format.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
GifGraph will no loger work. Use PNGgraph. It is better. You need to
get the gd libraries (from freshmeat.net), then you will need GD (from
search.cpan.org) and then PNGgraph (again from cpan). I forgot if there
are any other dependancies along the way. But that should do the trick!
--Aaron
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 14 Jun 2000 16:31:51 GMT
From: helgi@NOSPAMdecode.is (Helgi Briem)
Subject: Re: grep - a beginner question
Message-Id: <3947b2ed.5750648@news.itn.is>
On Tue, 13 Jun 2000 20:40:09 -0500, karlh <karlh@midco.net>
wrote:
>I am trying to learn how to use grep in a Perl program and have written
>the following to experiment with.
>
>@array = ("Bob Stands Tall", "Sarah Sits Still", "Mary Runs Slowly");
>
>print "Search for: ";
>$search = <>;
>chomp $search;
>
>@arrayout = grep($_ = $search, @array);
You may want that line to read:
@arrayout = grep(/$search/, @array);
------------------------------
Date: Wed, 14 Jun 2000 15:25:31 GMT
From: davidkrainess@yahoo.com (David Krainess)
Subject: Re: help - redefined subroutine warning
Message-Id: <8F5352626davidkrainessyahooco@38.8.213.2>
bill.kemp@wire2.com (W Kemp) wrote in
<960972513.1587.0.nnrp-10.c3ad6973@news.demon.co.uk>:
>on the risk of insulting intelligence....
>
>Doesn't mod_perl always give this warning if you update an existing
>mod_perl script (ie Apache::Registry, not a mod_perl module used more
>directly) without restarting apache?
>
>Does the warning stop happening if you leave it alone at run through
>the site a few times? preferably in httpd -X mode.
>
>
First off, I just installed ModPerl for the first time yesterday, so I
don't know much about it.
Actually, I restarted apache (my first instinct), and the problem was still
there. I suspect ModPerl is not stopped when httpd is killed (perhaps some
directive is needed to kill ModPerl when Apache goes down) and causing the
problem.
If I preload the Apache::Registry (i.e. PerlHandler +Apache::Registry) the
problem disappears. I don't really understand why (I'm a little over my
head now), but it works.
------------------------------
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 3357
**************************************
