[7673] in Perl-Users-Digest
Perl-Users Digest, Issue: 1299 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Nov 11 04:45:08 1997
Date: Tue, 11 Nov 97 01:00:33 -0800
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 11 Nov 1997 Volume: 8 Number: 1299
Today's topics:
Re: "perl aware" vi editor? twod@not.valid
Re: Alternatives to CGI.pm (was Re: Continuations in pe (William R. Ward)
Re: Alternatives to CGI.pm (was Re: Continuations in pe <ajh@rtk.com>
Re: An excellent example of perl madness (or "split stu <wtansill@erols.com>
Re: Block comments in Perl? (Gabor)
Re: Block comments in Perl? (brian d foy)
Can I use a path with "use" or how can I use "use Symbo crr026@email.mot.com
Re: CPAN confusion <qdtcall@esb.ericsson.se>
Re: exec. external shell prog (Tad McClellan)
Foo - Bar <ged@fortec.tuwien.ac.at>
Re: header files for scripts run from procmail? <doug@tc.net>
Re: header files for scripts run from procmail? (William R. Ward)
Re: header files for scripts run from procmail? <Steve_Kilbane@cegelecproj.co.uk>
Re: How do I create a random number with Perl? <petri.backstrom@icl.fi>
Killing a child process (SiberTanrI)
Re: NCSA Httpd Error 500 <webmaster@fccj.cc.fl.us>
Re: newbie having trouble with install <youngej@magpage.com>
Re: ODBC and Apostrophe <Steve_Kilbane@cegelecproj.co.uk>
Re: Passing Variables <myleslawrence@email.msn.com>
Re: Passing Variables <markm@nortel.ca>
Re: Unix to Windows ODBC database? <rothd@roth.netX>
Re: URL encoded <petri.backstrom@icl.fi>
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 11 Nov 1997 06:28:28 GMT
From: twod@not.valid
Subject: Re: "perl aware" vi editor?
Message-Id: <648tuc$qej$1@vnetnews.value.net>
: Does anyone know what a "perl aware" vi editor is?
Bit of a vague question, so I'll assume that you are looking for a vi-like
editor that is aware of the PERL syntax in that it does auto-indentation and
formatting.
I'm not sure if any of the newer vi-like programs such as 'vim' (which claims
'an interface to Perl' - www.halcyon.com/gvr/vim.html) or 'elvis' (not sure
of URL other than ftp://ftp.cs.pdx.edu/pub/elvis/README.html) offer the
functionality that you require, but maybe give them a look.
Some developers, myself included, have been known to prefer emacs (or Xemacs)
and it's almost limitless functionality - perl-mode, syntax by colour/font,
brace matching by highlighting.
Emacs is available from your friendly neighbourhood GNU archive (www.gnu.org/
order/ftp.html will get you a list of ftp sites); Xemacs is available
from www.xemacs.org. Xemacs has emacs at it's core but has a better GUI IMHO.
If your OS can handle emacs - it's got a fairly substantial footprint wrt
disk space and memory usage when compared to vi - I'd look at using that for
your PERL coding. GNU is fully customisable and extensible so if the current
functionality doesn't fit your needs then it's possible to customise as
required.
(X)emacs also has a vi-mode should you require it :)
IAP
--
In an attempt to reduce junk email I use an invalid 'From' address.
My correct email address can be determined by replacing 'not.valid' with
'value.net'
------------------------------
Date: 10 Nov 1997 21:14:24 -0800
From: hermit@cats.ucsc.edu (William R. Ward)
Subject: Re: Alternatives to CGI.pm (was Re: Continuations in perl?)
Message-Id: <waa3el4811r.fsf@ese.UCSC.EDU>
"Aaron Harsh" <ajh@rtk.com> writes:
> I R A Aggie wrote in message <-0211971244150001@aggie.coaps.fsu.edu>...
> >In article <878450119.324524@ridge.spiritone.com>, "Aaron Harsh"
> ><ajh@rtk.com> wrote:
> >
> >+ Binding a perl object to a Web page seems straightforward. Getting the
> >+ results is straightforward. The difficult part seems to be saving state
> >+ between invocations (both variables, and position inside the program).
> >
> >Maybe I don't understand, but doesn't CGI.pm already do some of this?
>
> I think CGI.pm does a great job at a lot of this stuff.
>
> But as an example of something that's just beyond the scope of CGI.pm,
> consider:
>
> - Keeping a database or statement handle between invocations
If it's just a matter of conveying a string (or something that can be
mapped into one) from one page to the next, use a hidden field.
> - Maintaining position in a file handle
You could save the position in a hidden field (it's just a number) and
the seek it on the next page.
> - Preserving child processes (e.g., a pipe'd file handle)
That one would require a persistent server with some kind of IPC.
> Plus there's the problem of a program losing its current position, which
> seems to be just as big an issue.
Hidden fields can eliminate this issue if used carefully.
> I know that mod_perl can help with some of this stuff, but only in specific
> cases (I can't depend on the same httpd processing being called each time).
You shouldn't expect mod_perl to give you anything more than CGI does,
except with better performance.
> Anyway, it sounds like the thing to do is to have a process for each session
> running on the server side, and have CGI scripts which do nothing but
> communicate with the persistent processes.
I think you could probably do better than that by having a single
daemon that all sessions connect to, using a session ID to tell it
which session is which (and said session ID being carried along from
page to page in hidden fields), that handles child processes or
network connections. The bulk of the processing can stay in the CGI
script.
--Bill.
[posted and mailed]
--
William R Ward Bay View Consulting http://www.bayview.com/~hermit/
hermit@bayview.com 1803 Mission St. #339 voicemail +1 408/479-4072
hermit@cats.ucsc.edu Santa Cruz CA 95060 USA pager +1 408/458-8862
------------------------------
Date: Mon, 10 Nov 1997 23:20:28 -0800
From: "Aaron Harsh" <ajh@rtk.com>
Subject: Re: Alternatives to CGI.pm (was Re: Continuations in perl?)
Message-Id: <6490sg$s1v$1@brokaw.wa.com>
I'm amazed at how little anyone else seems to notice this problem (assuming
it's not just my imagination). Am I just missing some crucial piece.
Before I responsd to William's post I think I should mention that I think
CGI.pm is a good thing, I use it myself, and it's one of the few pieces of
software I use that I don't curse at. I think a better subject for this
thread might be 'Alternatives to traditional CGI programming'.
Anyway, William had some good ideas that I think I should respond to. For
reference, I'd like to present a little snippet of something resembling perl
code. I'm sorry it's large, but I think that's necessary to make my point.
The snippet presumes the existence of a sub called 'show_form' that yields
an HTML form to the HTTP server, causes the script to sleep until another
request is made and returns in a hash reference any input the user made on
the form:
my $customer_info;
my @ordered_items; # Array of references to hashes that describe items
ordered
my $database_handle = init_database_handle();
for (;;) {
show_form("intro.html");
my $response;
do {
$response = get_next_product($database_handle, \@ordered_items);
} while ( $response->{-action} !~ /^(DONE|CANCEL)$/i );
if ( $response->{-action} eq "DONE" ) {
unless defined($customer_info) {
$response = get_customer_info($database_handle);
}
unless defined($customer_info->{-credit_card_no}) {
$response = get_credit_card_info($database_handle, $customer_info);
}
add_order($database_handle, $customer_info, \@ordered_items);
}
}
sub get_next_product {
my ( $database_handle, $orders_ref ) = @_;
my $response = show_form("choose_product.html");
return $response if $response->{-action} !~ /^(DONE|CANCEL)$/i;
my $product_info = lookup_product($database_handle,
$response->{-product_id});
$response = show_form("choose_qty.html",
-product_id => $product_info->{-product_id},
-description => $product_info->{-description},
-price => $product_info->{-price});
push(@$orders, { $response->{-product_id}, $response->{-qty}})
if ( $response ne "FORGET IT" );
return $response;
}
sub get_customer_info { ... }
sub get_credit_card_info { ... }
The example is not particularly complex. I've noticed that CGI applications
don't seem to get particularly tricky though (at least from an end-user's
standpoint), so it might be a typical example.
I agree the code is pretty ugly, but notice that:
1. The control flow is obvious. You can look at the code and tell which
HTML files are called, and in which order they're called (except for the
fact that some of it is hidden behind subroutines). In a traditional CGI
application, trying to examine the sequence of forms would involve browsing
through the HTML files one at a time, building a mental linked list of
possiblities.
2. Subroutines split apart related sections of the code. In particular the
get_next_product routine actually groups together two forms which are
related. I'm sure you _could_ do this in a traditional CGI app (just like
you _could_ have an array of arrays in perl 4), but I doubt the flow of the
code would resemble the flow of the application.
3. Some of these routines could (and should) be in libraries. In a
traditional CGI app, each HTML page points to its successor, and so isn't
really conducive to reuse. Of course, you _could_ stick the code in a
library, and pass the sub as a parameter the URL that the form should post
to, but...
I agree that this entire application could be stored in one CGI script that
passes its state along between forms. I imagine this script would look like
an ever-more-complicated state machine, I agree that someone coulde make it
work. But programming a state machine isn't nearly as straightforward as
writing linear code.
Imagine what the program would like if it was written as a traditional CGI
application. If someone has a reasonable implementation, I'd love to see
it. Let's assume that we're using mod_perl and can keep the database handle
around between invokations, although that technique won't scale up to
handles to cursors (for instance).
Anyway, in response to William:
William R. Ward wrote in message ...
>"Aaron Harsh" <ajh@rtk.com> writes:
>> But as an example of something that's just beyond the scope of CGI.pm,
>> consider:
>>
>> - Keeping a database or statement handle between invocations
>If it's just a matter of conveying a string (or something that can be
>mapped into one) from one page to the next, use a hidden field.
>
>> - Maintaining position in a file handle
>You could save the position in a hidden field (it's just a number) and
>the seek it on the next page.
>> - Preserving child processes (e.g., a pipe'd file handle)
>That one would require a persistent server with some kind of IPC.
>> Plus there's the problem of a program losing its current position, which
>> seems to be just as big an issue.
>Hidden fields can eliminate this issue if used carefully.
My response to all these is: Yes we can (and do) program like this, but we
could be a lot more productive if we could program in a linear fashion.
>> I know that mod_perl can help with some of this stuff, but only in
specific
>> cases (I can't depend on the same httpd processing being called each
time).
>You shouldn't expect mod_perl to give you anything more than CGI does,
>except with better performance.
Agreed. I only mentioned this to cut off any replies about mod_perl saving
.
>> Anyway, it sounds like the thing to do is to have a process for each
session
>> running on the server side, and have CGI scripts which do nothing but
>> communicate with the persistent processes.
>
>I think you could probably do better than that by having a single
>daemon that all sessions connect to, using a session ID to tell it
>which session is which (and said session ID being carried along from
>page to page in hidden fields), that handles child processes or
>network connections. The bulk of the processing can stay in the CGI
>script.
If by 'better' you mean 'would cut down on overhead on the server', I agree
completely. The 'better' I'm looking for, though, is 'would increase my
productivity'.
I would never write an application as a sequence of 7 files that exec each
other based on user input, or that use a state-machine to control a linear
sequence of actions, or that rebuild the contents of their memory every
iteration of a for loop -- it would be amazingly unproductive. But this is
exactly what I have to do when I program a CGI app.
Anyway, enough of my whining. Is anyone actually interested in a module for
doing what I've been talking about? Does anyone have any reasons why such a
thing would have problems?
Implementing a 'show_form' routine doesn't sound too tricky, but is it
enough? This seems like a nice weekend project unless I'm missing something
big.
I'm anxiously awaiting your responses
Aaron Harsh
ajh@rtk.com
------------------------------
Date: Tue, 11 Nov 1997 00:07:24 -0500
From: "William B. Tansill, III" <wtansill@erols.com>
Subject: Re: An excellent example of perl madness (or "split stupidity")
Message-Id: <3467E80C.1FB6@erols.com>
Ilya Zakharevich wrote:
>
> In article <EJ8L49.D2x@world.std.com>,
> Andrew M. Langmead <aml@world.std.com> wrote:
> > Gary Howland <ghowland@hotlava.com> writes:
> > split /PATTERN/,EXPR,LIMIT
> >
> > split /PATTERN/,EXPR
> >
> > split /PATTERN/
> >
> > So any of your examples without a pattern as the first argument to
> > split is WRONG. If someone taught you that split divides by a string
> > instead of a regular expression, they were WRONG.
>
> Which should not imply that split would not take a string as a first
> argument.
>
> Ilya
It's not implied -- the Camel book is very clear that PATTERN is to
contain a regex (page 229). Prior to that, the book explains in detail
what constitutes a regex and how one is formed.
--
How do I set my laser printer to "stun"?
------------------------------
Date: 11 Nov 1997 02:57:52 GMT
From: gabor@vinyl.quickweb.com (Gabor)
Subject: Re: Block comments in Perl?
Message-Id: <slrn66fi1o.n2k.gabor@vinyl.quickweb.com>
In article <35744.4279846065luutrangeocitiescom@207.217.245.11>, Luu Tran wrote:
>Hi,
>
>This is dumb but how do I do block comments in Perl (5.003)? perlsyn says C
>style /* */ block comment is out, so how?
>
>tia
>
>-- luu
how about
if(0) {
stuff i want to block, should still be valid code, of course
}
if you want multiline comments
# just use
# a bunch
# of hash marks
# on multiple lines
gabor.
--
Down that path lies madness. On the other hand, the road to hell is
paved with melting snowballs.
-- Larry Wall in <1992Jul2.222039.26476@netlabs.com>
mharris@gov.on.ca he, he, he
------------------------------
Date: Tue, 11 Nov 1997 01:39:31 -0500
From: comdog@computerdog.com (brian d foy)
Subject: Re: Block comments in Perl?
Message-Id: <comdog-ya02408000R1111970139310001@news.panix.com>
In article <slrn66fi1o.n2k.gabor@vinyl.quickweb.com>, gabor@vinyl.quickweb.com (Gabor) wrote:
>In article <35744.4279846065luutrangeocitiescom@207.217.245.11>, Luu Tran wrote:
>>This is dumb but how do I do block comments in Perl (5.003)? perlsyn says C
>>style /* */ block comment is out, so how?
>if(0) {
> stuff i want to block, should still be valid code, of course
>}
why would you want to do soemthing like that, which really isn't a
comment at all? use the built in commenting features of plain old
documentation:
=head1 this section is ugly
lots of lines of code here are ignored by the interpreter, unlike
some other suggestions
=cut
--
brian d foy <comdog@computerdog.com>
NY.pm - New York Perl M((o|u)ngers|aniacs)* <URL:http://ny.pm.org/>
CGI Meta FAQ <URL:http://computerdog.com/CGI_MetaFAQ.html>
------------------------------
Date: Mon, 10 Nov 1997 22:29:54 -0600
From: crr026@email.mot.com
Subject: Can I use a path with "use" or how can I use "use Symbolic_linked_module" with taint checking?
Message-Id: <879219431.31343@dejanews.com>
Hi!
I want to add my lib directories to the @INC array in a generic way. What
I've done is put these statements
BEGIN {
push @INC, "/usr/local/me/my_lib/Perl";
}
in a file called init.pm in that same directory (i.e.
/usr/local/me/my_lib/ Perl). In my working directory
(/usr/local/me/code/Perl), I placed a symbolic link to the init.pm file.
Thus, in all my scripts, I can use a "use init", to update the @INC
array.
However when I turn on taint checking (perl -T), this doesn't work. I
can't use "use ../../lib/Perl/init" either. Can some kind soul help me
overcome this problem?
Best regards,
Ramesh
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
------------------------------
Date: 11 Nov 1997 09:49:41 +0100
From: Calle Dybedahl <qdtcall@esb.ericsson.se>
Subject: Re: CPAN confusion
Message-Id: <iszpnbizmi.fsf@godzilla.kiere.ericsson.se>
Kermit Tensmeyer <kermit@ticnet.com> writes:
> At work I sit behind a firewall. I can browse the CPAN site all I want
> with a browser, but the CPAN module can not connect unless the perl
> is socksified.
Wrong. Perl (and the CPAN module) can use the same proxy server your
browser uses. And while the NT Perl port I have installed on our WinDD
machine is too old to have the CPAN module included, it does have
IO::Socket, so I can see no reason why the CPAN module shouldn't work there.
--
Calle Dybedahl, UNIX Sysadmin
qdtcall@esavionics.se http://www.lysator.liu.se/~calle/
------------------------------
Date: Mon, 10 Nov 1997 22:56:57 -0600
From: tadmc@flash.net (Tad McClellan)
Subject: Re: exec. external shell prog
Message-Id: <pio846.a84.ln@localhost>
Matthias Bodenbinder (mbod@chem.ubc.ca) wrote:
: I am a complete novice to perl and I have a problem executing gnuplot
: from within a perl script (Linux, perl 5.003).
: The perl script generates a gnuplot file 'foo'. This file can be processed
: from gnuplot without error message when I invoke gnuplot from the
: commandline:
: $ gnuplot foo
: gnuplot then generates a postscript file 'out.eps'. Unfortunately this
: does not work when I invoke gnuplot from within my perl script. There are
: no error messages (I use 'perl -w') and there is no 'out.eps' file. I
: have tried a couple of different ways:
: `gnuplot foo`;
Don't use that one.
Backticks are for capturing the _output_ of commands. You don't want to
capture the output, since it will put it in th out.eps file for you.
: system( "gnuplot foo" );
: system( "gnuplot", "foo" );
Either of those should work the same as the command line (provided your
script is executed by a user that can get it to run from the command line)
system() is used for running a command and getting the return value.
: gnuplot is executed and 'foo' is read (when I change the name gnuplot
: complains about a wrong filename). But there is no way I can get the
: 'out.eps' file.
: What is going wrong?
I dunno.
See if gnuplot will give you a clue.
Have a look at what return value you are getting from gnuplot:
$ret = system( "gnuplot foo" );
die "gnuplot returned ", $? >> 8 if $ret;
Does the user that this script runs as have permissions to create a file
in the current directory?
--
Tad McClellan SGML Consulting
tadmc@flash.net Perl programming
Fort Worth, Texas
------------------------------
Date: Tue, 11 Nov 1997 08:57:58 -0800
From: Georg Edelmayer <ged@fortec.tuwien.ac.at>
Subject: Foo - Bar
Message-Id: <34688E96.274F@fortec.tuwien.ac.at>
Hi all!
This might be out of subject (and if it is, please ignore this posting)
but as one who is not a -programmer- but interested in programming i
once again found 'foo' and 'bar' mentioned in some examples.
I realise that nearly every programming language manual or doc or
whatever uses foo and bar when explaining code.
Like 'hello world' is the first thing everyone codes ;-)
So can any of you tell me where this names come from?
It could be any names, so why foo and bar?
Thanks in advance
Georg
------------------------------
Date: 10 Nov 1997 23:24:39 -0500
From: Douglas McNaught <doug@tc.net>
To: Doug Jacobs <djacobs@tsoft.com>
Subject: Re: header files for scripts run from procmail?
Message-Id: <m2oh3st5vb.fsf@ono.tc.net>
[mailed and posted]
Doug Jacobs <djacobs@tsoft.com> writes:
[Arrrggh! Format your posts with <75 chars/line, please!]
> I'm developing a number of scripts to be run through procmail
> (eg. if the recipe matches, kick off this script and feed the
> message into it.)
>
> Because these scripts use many common libraries, variables, and
> other things, I tried to create a file with these common things,
> then "require" them in each script - a sort of header file for PERL
> if you will.
A fine idea.
[snip snip snip--my, you're verbose!]
> However,
> Procmail seems unable to find the header file even though it is in
> one of the directories listed in its PATH variable.
What makes you think PATH has anything to do with it?
Well, OK. It's a semi-logical conclusion to draw. It's wrong,
though. From 'man perlrun':
-Idirectory
Directories specified by -I are prepended to the
search path for modules (@INC), and also tells the C
preprocessor where to search for include files. The
C preprocessor is invoked with -P; by default it
searches /usr/include and /usr/lib/perl.
So you want to add the directory where your require'd file lives to
@INC. There are may ways to do it. The best, in any semi-modern
Perl, is the 'lib' pragma:
# put this in each script that needs your lib
use lib '/path/to/my/perllibdir';
require 'mylib.pl';
You might consider writing your lib as a module for syntactic and
namespace cleanliness. See 'man perlmod' for copious details.
Best o' luck, and happy hacking!
-Doug
--
sub g{my$i=index$t,$_[0];($i%5,int$i/5)}sub h{substr$t,5*$_[1]+$_[0],1}sub n{(
$_[0]+4)%5}$t='encryptabdfghjklmoqsuvwxz';$c='fxmdwbcmagnyubnyquohyhny';while(
$c=~s/(.)(.)//){($w,$x)=g$1;($y,$z)=g$2;$w==$y&&($p.=h($w,n$x).h($y,n$z))or$x==
$z&&($p.=h(n$w,$x).h(n$y,$z))or($p.=h($y,$x).h($w,$z))}$p=~y/x/ /;print$p,"\n";
------------------------------
Date: 10 Nov 1997 21:23:18 -0800
From: hermit@cats.ucsc.edu (William R. Ward)
Subject: Re: header files for scripts run from procmail?
Message-Id: <waazpnc6m2g.fsf@ese.UCSC.EDU>
Doug Jacobs <djacobs@tsoft.com> writes:
> I'm developing a number of scripts to be run through procmail (eg. if the
> recipe matches, kick off this script and feed the message into it.)
>
> Because these scripts use many common libraries, variables, and
> other things, I tried to create a file with these common things,
> then "require" them in each script - a sort of header file for PERL
> if you will.
Good idea. While you're at it, make it a Perl module.
DJacobs::Procmail or something.
> The "header" file works fine when the script the command line,
> however when Procmail kicks it off, things go awry (it can't find
> the header file.) When I copy the header file into the scripts,
> they run fine when either I run them from the command prompt or
> through Procmail. The downside of this is when I change something
> that was in the "header" file, I need to change it in all the files
> - a bit tedious and error-prone as these scripts are used on a
> couple of different accounts. This was also why I wanted a "header"
> file so badly - only 1 source to change, and everyone's happy. I'm
> trying to figure out what is so different about running a script
> with the "header" file from the command line vs. Procmail and am not
> having much luck. I have set up my Procmail-rc file with as much
> information for its environment as possible, including the path for
> the directory with all the scripts in it. However, Procmail seems
> unable to find the header file even though it is in one of the
> directories listed in its PATH variable.
Read about @INC in the perlvar manpage (type "perldoc perlvar").
Basically it is a search path that require and use look in for files
to be included. You need to tell Perl to add the directory where your
"header" file is located to @INC. The obvious way is this:
unshift (@INC, "/home/djacobs/lib");
or equivalent. However Perl 5 provides a niftier way of doing this
(as with most things):
use lib qw(/home/djacobs/lib);
Simply put that in your Perl scripts before they "require" or "use"
the "header" file, and you should have no trouble with it.
BE VERY CAREFUL when writing code of this type, though! Keep in mind
that someone could potentially send you e-mail that might exploit bugs
in your scripts to execute commands (or Perl code), or to find out
more about your system for breaking in. I suggest you use perl with
tainting for this (#!/usr/local/bin/perl -T). Using -w (extended
syntax warnings) might be a good idea as well.
--Bill.
[posted and mailed]
--
William R Ward Bay View Consulting http://www.bayview.com/~hermit/
hermit@bayview.com 1803 Mission St. #339 voicemail +1 408/479-4072
hermit@cats.ucsc.edu Santa Cruz CA 95060 USA pager +1 408/458-8862
------------------------------
Date: Tue, 11 Nov 1997 08:39:31 GMT
From: Steve Kilbane <Steve_Kilbane@cegelecproj.co.uk>
Subject: Re: header files for scripts run from procmail?
Message-Id: <bb7cd$8271f.2b8@news.cegelecproj.co.uk>
In article <3467d677.0@news.tsoft.net>, Doug Jacobs <djacobs@tsoft.com> writes:
> Because these scripts use many common libraries, variables, and other things,
> I tried to create a file with these common things, then "require" them in each
> script
Fair enough, although making them into a module would be nicer. :-)
> when Procmail kicks it off, things go awry (it can't find the header file.) [...]
> However, Procmail seems unable to find the header file even though it is in
> one of the directories listed in its PATH variable.
require searches @INC, which is set from -I switches, not from the
environment. Alternatively, you could have:
use lib '/your/scripts/here';
in each of your scripts.
--
<Steve_Kilbane@cegelecproj.co.uk> - All opinions are mine alone.
Kilbane's law of integration: standardise on protocols and file
formats, and the applications take care of themselves.
------------------------------
Date: Mon, 10 Nov 1997 13:55:06 +0200
From: Petri Backstrom <petri.backstrom@icl.fi>
Subject: Re: How do I create a random number with Perl?
Message-Id: <3466F61A.35A@icl.fi>
Eric Phillips wrote:
>
> Hello all, I have a question about Perl. I am no expert, just an amateur,
> so please explain in detail.
You don't need to be a expert. You just need to know
how to read the free, on-line Perl documentation that
comes with every proper Perl distribution kit.
> How do I create a random number with Perl, so it can be use later in the
> script?
Look up the rand() function in the Perl documentation
(in the perlfunc part).
I also suggest you read the Perl Frequently Asked
Questions (FAQ) list from beginning to end.
The latest docs, etc., you can find via
http://www.perl.com
regards,
...petri.backstrom@icl.fi
ICL Data Oy
Finland
------------------------------
Date: 11 Nov 1997 05:15:13 GMT
From: sibertanri@aol.com (SiberTanrI)
Subject: Killing a child process
Message-Id: <19971111051500.AAA20822@ladder02.news.aol.com>
A Perl script makes a system call to invoke another
tool. While this child is running, the user tries to stop
the execution of the Perl script using ^c. How do we kill
the child process, too, since ^c is only detected by the
parent?
An example will be appreciated.
------------------------------
Date: Mon, 10 Nov 1997 22:43:26 -0500
From: "Bill Jones" <webmaster@fccj.cc.fl.us>
Subject: Re: NCSA Httpd Error 500
Message-Id: <3467d537.0@usenet.fccj.cc.fl.us>
What does your error.log really say?
Have you tried using the -w option?
Have you tried using CGI.pm, instead of CGI-LIB.pl?
cgi-lib.pl is not '-w' safe. Many different things happen during a CGI run
than would happen during a command line run.
devesh wrote in message <646e8e$m45$1@goanna.cs.rmit.edu.au>...
>Hi,
. I am using cgi-lib.pl library.
>Even the simple code like this gives the same error
>-----
>#!/usr/bin/perl
>require ("cgi-lib.pl");
>&ReadParse (*input);
>print &PrintHeader;
>print <<"end";
> <HTML><BODY>blah blah blah</BODY></HTML>
>end
>-----
>I am using NCSA httpd version 1.5.1
>
>
>Any suggestions????
>
>Thanxs,
>devesh
>
>--
>
>**********************************************
>devesh Jain
>13/150 alma rd.
------------------------------
Date: 11 Nov 1997 05:43:26 GMT
From: Ed Young <youngej@magpage.com>
To: David Storrs <dstorrs@crossover.com>
Subject: Re: newbie having trouble with install
Message-Id: <648r9u$lo5$0@204.179.92.191>
Perl is usually run from the command line. Try:
perl -d somescript.pl
Read about the debugger in the Camel book, the documentation included
with the distribution, or by typing 'h' on any perl debugger line. It's
sort of primative after GUI debuggers, but quite good, useful, and
useable...
David Storrs wrote:
>
> I've just started learning Perl, so I downloaded the Win32
> version for W95 (the 312 build from CPAN). It self-extracted very
> nicely, it ran its own installer very nicely, everything was great.
>
> The problem lies in running it. DblClicking the "Perl.exe"
> file brings up a DOS-style window which seems to happily ignore all
> input, or else give a warning message. I can run it from a DOS shell,
> but then any error messages get spewed out and scroll off screen. I
> tried redirecting them to a file with:
> perl -w somescript.pl > results.txt
> but that didn't accomplish anything. I was sort of hoping that there
> was a nice, friendly, "type-a-line-watch-it-be-interpreted" sort of
> interactive thing here somewhere, but I am obviously missing
> something. Could anyone tell me what blazingly obvious fact I have
> overlooked so that I can use Perl on my Windoze platform?
------------------------------
Date: Tue, 11 Nov 1997 08:30:59 GMT
From: Steve Kilbane <Steve_Kilbane@cegelecproj.co.uk>
Subject: Re: ODBC and Apostrophe
Message-Id: <bb7cd$81e3b.3b@news.cegelecproj.co.uk>
In article <slrn66eq7k.sq1.wkc@amanda.dorsai.org>, wkc@dorsai.org (Wesley) writes:
> Replace all of the ' with '' works. It's a SQL thing. s/'/''/g becomes a
> standard line in all my sql lines.
I missed the original post, so I don't know which ODBC interface
the poster's using, but if it's DBI, then they should be quoting
strings using the quote() method:
my $dbh = DBI->connect(...);
$field = $dbh->quote($field);
my $sth = $dbh->prepare("SELECT * FROM table WHERE col = $field");
Note that quote() is supposed to escape quotes itself, and is supposed
to wrap the result in the required quotes too, so you'd use
$field, rather than '$field'.
--
<Steve_Kilbane@cegelecproj.co.uk> - All opinions are mine alone.
Kilbane's law of integration: standardise on protocols and file
formats, and the applications take care of themselves.
------------------------------
Date: Mon, 10 Nov 1997 21:12:43 -0800
From: "Myles Lawrence" <myleslawrence@email.msn.com>
Subject: Re: Passing Variables
Message-Id: <uMiPC$l78GA.319@upnetnews03>
OK I'll try this but I'm not 'system'ing the second script. I'm <form
action=script.pl>. Would this make a difference.
Myles
Pete Barker wrote in message ...
>In article <un5iAcM78GA.244@upnetnews03>,
>myleslawrence@email.msn.com (Myles Lawrence) wrote:
>
>> I tried this under NT and nothing. Is there and equivalent to
>the $ENV
>> variables?
>> myleslawrence@msn.com
>> Mark Mielke wrote in message ...
>> >Dale Chavez <dale@horizonint.com> writes:
>> >
>>
>>
>>
>>
>
>With a little adjustment, Mark's scripts worked under NT for me...
>
>Script A (a.pl)
>---------------
>$ENV{COMMAND} = "Be Happy!";
>system "PERL b.pl";
>
>Script B (b.pl)
>---------------
>print $ENV{COMMAND},"\n";
>
>Under NT4, system "b.pl" would work assuming file associations are
>setup ok, but under NT 3.51, you need to prefix with PERL to
>explicitly tell the command interpreter the program to run.
>
>Regards,
>
>Pete Barker
>P.S. Please remove on.maps. to mail me.
>
------------------------------
Date: 11 Nov 1997 03:03:17 -0500
From: Mark Mielke <markm@nortel.ca>
Subject: Re: Passing Variables
Message-Id: <lq1g1p3amd6.fsf@bmerhe83.nortel.ca>
"Myles Lawrence" <myleslawrence@email.msn.com> writes:
> OK I'll try this but I'm not 'system'ing the second script. I'm <form
> action=script.pl>. Would this make a difference.
> Myles
Using normal HTML, the proper way to communicate data across "forms" is
via the: <input type=hidden name=Stuff value="Some Stuff"> tag. You would
read the "Stuff" field through your CGI the same way you might read any
other input field. This is now more a CGI question than a perl question.
hope this helps...
mark
-- _________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Northern Telecom Ltd. |
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | Box 3511, Station 'C' |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, ON K1Y 4H7 |
markm@nortel.ca / al278@freenet.carleton.ca |_______________________|
------------------------------
Date: 11 Nov 1997 06:18:36 GMT
From: "Dave Roth" <rothd@roth.netX>
Subject: Re: Unix to Windows ODBC database?
Message-Id: <01bcee69$bbaa53d0$0dbc4acf@main2>
Alex Panagides <alex@inova.net> wrote in article
<34674F81.3247@inova.net>...
> What is required (Perl speaking) to access a MS Access database from a
> Unix box? I have the DBI-0.90 module installed. Anything else?
You will need an Access ODBC driver. If you can find one for Unix
let me know! ;)
dave
--
================================================================
Dave Roth ...glittering prizes and
Roth Consulting endless compromises, shatter
rothd@roth.nXeXt the illusion of integrity
My email address is disguised to fool automailers. Remove the
X's to send me email.
****************************************************************
Use of this message or email address for commercial purposes
(including "junk" mailings) is strictly prohibited and protected
under current international copyright laws and United States
Code, Title 47, Chapter 5, Subchapter II.
------------------------------
Date: Mon, 10 Nov 1997 14:00:56 +0200
From: Petri Backstrom <petri.backstrom@icl.fi>
Subject: Re: URL encoded
Message-Id: <3466F778.1A0D@icl.fi>
Andrew Nicholson wrote:
>
> Using a Content-type of applications/x-www-form-urlencoded, new lines
> are coded as %0D%0A. I find little decipherable documentation dealing
> with this particularity. Can anybody provide the ascii translation for
> these charectors. For that matter, how about all charectors with an
> ascii value less than 32 on you typical home PC?
Carriage return (CR) and Linefeed (LF) a.k.a. "\r" and "\n".
Note than on some platforms (notably MS-DOS/Windows), these
are used as line/record terminator characters, but usually
one codes it with just "\n" and the underlying run-time
library writes it out as a CR/LF pair (and vice versa
when reading a file).
regards,
...petri.backstrom@icl.fi
ICL Data Oy
Finland
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
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.misc (and this Digest), send your
article to perl-users@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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 1299
**************************************
