[8301] in Perl-Users-Digest
Perl-Users Digest, Issue: 1918 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Feb 17 09:07:29 1998
Date: Tue, 17 Feb 98 06:00:57 -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, 17 Feb 1998 Volume: 8 Number: 1918
Today's topics:
Re: "undef" and Inititializing .. <rjk@coos.dartmouth.edu>
Re: <$x> OK but <$_[0]> NOT?!! <rjk@coos.dartmouth.edu>
Re: ? Regular Expressions ? (Sitaram Chamarty)
Re: A Pubilc Apology. (Chip Salzenberg)
Finding name of current directory in Perl <john.mcgoldrick@isocor.ie>
Free XXX Accounts Today!! bacnrukq@funny.net
Re: HELP ODBC sql stmt failing when using WHERE LIKE <metcher@spider.herston.uq.edu.au>
Re: HELP! My ISP claims that Perl access is a serious (Troy Denkinger)
New Perl module makes some functions run faster mjd-perl-memoize@plover.com
Pipes, open(), and errors (was Re: PGP - Perl puzzle) <rjk@coos.dartmouth.edu>
print Location: + frames?? <Henningsen@ith.se>
Re: Quick Reg Expression help (Martien Verbruggen)
Re: script won't run...displays script text (Martien Verbruggen)
some thoughts on RTFM/FAQ/newbies/moderated uri@sysarch.com
T.H.I.N.G.Y. [was: Being Nice 2 Nice Beings [Was: Readi <dha@panix.com>
Re: The Young Man and the Beach <dformosa@st.nepean.uws.edu.au>
Urgent help requiredon Perl and Flocking <iol@bom3.vsnl.net.in>
Re: WANTED UK PEARL SCRIPT PROGRAMER (Martien Verbruggen)
What does this mean? (James L. Taylor)
Re: what is exaclty the "_" Variable ?!?! <tchrist@mox.perl.com>
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 17 Feb 1998 00:52:06 -0500
From: Chipmunk <rjk@coos.dartmouth.edu>
Subject: Re: "undef" and Inititializing ..
Message-Id: <34E9258A.87C77D52@coos.dartmouth.edu>
Greg Bacon wrote:
>
> I was surprised to find that
>
> #! /usr/bin/perl -w
>
> $foo += 42;
> print "$foo\n";
>
> $bar .= "yo mama so fat";
> print "$bar\n";
>
> doesn't emit any warnings. Nonetheless, you still see the behavior.
It's so you can do things like this:
my @words = qw(foo bar foo);
my %words;
foreach (@words) {
$words{$_}++;
}
instead of this:
my @words = qw(foo bar foo);
my %words;
foreach (@words) {
if (defined $words{$_}) {
$words{$_}++;
} else {
$words{$_} = 1;
}
}
--
_ / ' _ / rjk@coos.dartmouth.edu
( /)//)//)(//)/( chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
------------------------------
Date: Tue, 17 Feb 1998 01:13:51 -0500
From: Chipmunk <rjk@coos.dartmouth.edu>
To: Keith Kong <kkong@ece.ucdavis.edu>
Subject: Re: <$x> OK but <$_[0]> NOT?!!
Message-Id: <34E92AA4.8E1216BE@coos.dartmouth.edu>
[posted and mailed]
Keith Kong wrote:
>
> Does anyone have a perl4 explanation for why using $x in place of
> $_[0] works? Is $_[0] somehow "less" of a scalar variable than $x?
Presumably, $x is a 'scalar variable', and $_[0] is an 'element of an array'.
It appears to be a design flaw in the dual purpose of <>.
--
_ / ' _ / rjk@coos.dartmouth.edu
( /)//)//)(//)/( chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
------------------------------
Date: 17 Feb 1998 05:32:55 GMT
From: sitaram@diac.com (Sitaram Chamarty)
Subject: Re: ? Regular Expressions ?
Message-Id: <slrn6ehm7u.cmb.sitaram@ltusitaram.diac.com>
On Mon, 16 Feb 1998 11:03:13 -0500, Bob Sparks <Sparks@Sourceworks.com> wrote:
>First of all Man is a most antiquated method of providing documentation. How
[lots of anti-manpage tirade snipped]
>To all the RFM posters we are sorry your dad beat you as a child try some of
>the alt.abuse groups to vent your self. Use that incredible talent of yours
>to provide clever tools to help the challenged newbie.
First of all, all Perl docs come on the form of POD, not man. POD
is embedded within the source code to maximise the chances of the
docs being kept uptodate with changes in functionality.
Second, the standard Perl distrib comes with:
pod2html pod2latex pod2man pod2text
So you already have an HTML converter there. And then some (a
LaTeX typeset printout of a man page - hardcopy for reading on the
bus or something - is a pleasure to read!)
Believe me: perl people know more than most how to "work smarter,
not harder". You obviously havent read about the three virtues of
a programmer in the Camel :-)
------------------------------
Date: Tue, 17 Feb 1998 06:14:49 GMT
From: chip@mail.atlantic.net (Chip Salzenberg)
Subject: Re: A Pubilc Apology.
Message-Id: <6cba09$2pu$1@cyprus.atlantic.net>
According to Russ Allbery <rra@stanford.edu>:
>Chip Salzenberg <chip@mail.atlantic.net> writes:
>> Any newsreader worth the bits it's recorded on has a search feature.
>> For example, in trn, I say:
>
>> /salzenberg/a
>> /chip@/a
>
>$salzenberg = 1; # this line is here so that Chip will read my question
No problem. Flattery has its uses. :-)
--
Chip Salzenberg - a.k.a. - <chip@pobox.com>
"Hoist the failure sails, men! We're goin' home!" // MST3K
-> Ask me about Perl training and consulting <-
Like Perl? Want to help out? The Perl Institute: www.perl.org
------------------------------
Date: Tue, 17 Feb 1998 09:21:06 GMT
From: "John McGoldrick" <john.mcgoldrick@isocor.ie>
Subject: Finding name of current directory in Perl
Message-Id: <EoInKB.L24@isocor.com>
Hi,
This sounds like a simple problem but I haven't been able to solve
it. How do I find the name of the current working directory in Perl. I need
to execute a program in another directory so before I chdir I need to
remember the name of the current dir, this is because the current dir
contains a file which needs to be passed to the program I want to run.
I'd appreciate any thoughts on this; is it a security issue?
John.
------------------------------
Date: 17 Feb 1998 06:22:26 GMT
From: bacnrukq@funny.net
Subject: Free XXX Accounts Today!!
Message-Id: <6cbab2$1d5$10@excalibur.cc.boun.edu.tr>
http://www.angelfire.com/la/packratee/index.html
I just learned...
This is a Limited Time Offer!
FREE MEMBERSHIPS TODAY!!!
I've set up a link so you can
GET ONE WHILE ITS STILL FREE!!!
------------------------------
Date: Tue, 17 Feb 1998 16:35:55 +1100
From: Jaime Metcher <metcher@spider.herston.uq.edu.au>
Subject: Re: HELP ODBC sql stmt failing when using WHERE LIKE
Message-Id: <34E921BB.BE7A3A92@spider.herston.uq.edu.au>
This actually has nothing to do with perl, although one might be
forgiven for thinking it has. There are two differences between running
this query from perl and running it within Access. The first is perl
(and modules), and the second is the ODBC driver. Your problem is with
the ODBC driver.
Last time I tried this, I found that:
1. Access will only accept single quoted strings in ODBC SQL statements
(actually, this is part of the SQL standard). Access is more (and
misleadingly) forgiving in interactive mode.
2. Unless there's been an upgrade since last November, MS's ODBC drivers
don't support
wildcards in LIKE. In effect, LIKE is the same as =. If you hear any
differently, let me know.
Jaime Metcher
mashton@4all.com wrote:
>
> would appreciate any help on figuring out why this SQL statement fails.
>
> Env is NT4.0, Perl 5.003, using Win32::ODBC, and Access 97.
>
> Here is the statement: SELECT access_date, Count(*) AS Hits,
> Sum(Elapsed_time)/1000 AS [Total Elapsed Time], Sum(Bytes_in) AS [Total
> In], Sum(Bytes_out) AS [Total Out FROM access_log WHERE (Target like
> "*4all*") GROUP BY access_date;
>
> And here is the Error code:
>
> [-3100] [1] [0] "[Microsoft][ODBC Microsoft Access 97 Driver] Expression
> cannot be used with the LIKE predicate. in query expression '(Target
> alike `*4all*`)'."
>
> target is a defined field. If I remove the WHERE clause it runs fine. If
> I run it as a query within Access it runs fine.
>
> Any help or input would be appreciated.
>
> Thx, Mike
>
> -------------------==== Posted via Deja News ====-----------------------
> http://www.dejanews.com/ Search, Read, Post to Usenet
------------------------------
Date: Mon, 16 Feb 1998 07:10:29 GMT
From: troy@whadda.com (Troy Denkinger)
Subject: Re: HELP! My ISP claims that Perl access is a serious security risk!
Message-Id: <6cbdbe$8v3$1@hirame.wwa.com>
In article <tgooding-ya023580001602982113120001@news2.ibm.net>, tgooding@millcomm2.com (Tom Gooding) wrote:
[snip]
>security. It seems possible for me to allow perl to a user, but then you
>must make sure your password is indeed secure, and that you are liable for
>any actions taken from your account.
[snip]
The guy's willing to do you the favor of giving you access
if you'll comply with what I think are minimal requirements.
You're your not willing to do the two things he asks, then
you don't deserve the access - regardless of whether he's
being paranoid or not.
He's running a business. It's his job to be paranoid if he
feels that protects his clients.
Are his feelings justified? Who knows. We have no idea
how his systems are configured.
Regards,
Troy Denkinger
------------------------------
Date: 17 Feb 1998 02:11:30 -0500
From: mjd-perl-memoize@plover.com
Subject: New Perl module makes some functions run faster
Message-Id: <6cbd72$crs$1@monet.op.net>
Keywords: Burmese, bronchus, hidden, soup
My new `Memoize' module may make some Perl functions faster. It does
this by invisibly attaching a cache to the front of the function. If
you call the function twice with the same arguments, the result is
looked up in the cache and returned immediately, instead of being
computed all over again.
Full details, documentation, and distribution:
http://www.plover.com/~mjd/perl/Memoize/
Documentation also attached below:
* [1]NAME
* [2]SYNOPSIS
* [3]DESCRIPTION
* [4]DETAILS
* [5]OPTIONS
+ [6]INSTALL
+ [7]NORMALIZER
+ [8]TODISK
* [9]CAVEATS
* [10]TO DO
* [11]AUTHOR
_________________________________________________________________
NAME
Memoize - Make your functions faster by trading space for time
_________________________________________________________________
SYNOPSIS
use Memoize;
memoize('slow_function');
slow_function(arguments); # Is faster than it was before
_________________________________________________________________
DESCRIPTION
`Memoizing' a function makes it faster by trading space for time. Here
is an example. Consider the Fibonacci sequence, defined by the
following function:
# Compute Fibonacci numbers
sub fib {
my $n = shift;
return $n if $n < 2;
fib($n-1) + fib($n-2);
}
This function is very slow. Why? To compute fib(14), it first wants to
compute fib(13) and fib(12), and add the results. But to compute
fib(13), it first has to compute fib(12) and fib(11), and then it
comes back and computes fib(12) all over again even though the answer
is the same. And both of the times that it wants to compute fib(12),
it has to compute fib(11) from scratch, and then it has to do it again
each time it wants to compute fib(13). This function does so much
recomputing of old results that it takes a really long time to
run---fib(14) makes 1,200 extra recursive calls to itself, to compute
and recompute things that it already computed.
This function is a good candidate for memoization. Whenever a memoized
function computes a result, it saves the result in a table. Then, if
you ask the function to do the same work later, it just gives you the
answer that was in the table, instead of computing it all over again.
This module will automatically memoize functions for you. For example,
if you memoize the `fib' function above, it will compute fib(14)
exactly once, the first time it needs to, and then save the result in
a table. Then if you ask for fib(14) again, it gives you the result
out of the table. While computing fib(14), instead of computing
fib(12) twice, it does it once; the second time it needs the value it
gets it from the table. It doesn't compute fib(11) four times; it
computes it once, getting it from the table the next three times.
Instead of making 1,200 recursive calls to `fib', it makes 15. This
makes the function about 150 times faster.
You could do the memoization yourself, by rewriting the function, like
this:
# Compute Fibonacci numbers, memoized version
{ my @fib;
sub fib {
my $n = shift;
return $fib[$n] if defined $fib[$n];
return $fib[$n] = $n if $n < 2;
$fib[$n] = fib($n-1) + fib($n-2);
}
}
Or you could use this module, like this:
use Memoize;
memoize('fib');
# Rest of the fib function just like the original version.
This makes it easy to turn memoizing on and off.
_________________________________________________________________
DETAILS
This module exports exactly one function, memoize. The rest of the
functions in this package are None of Your Business.
You should say
memoize(function)
where function is the name of the function you want to memoize, or a
reference to it. memoize returns a reference to the new, memoized
version of the function.
If function was the name of a function, then memoize hides the old
version and installs the new memoized version under the old name, so
that &function(...) actually invokes the memoized version.
_________________________________________________________________
OPTIONS
There are some optional options you can pass to memoize to change the
way it behaves a little. To supply options, invokdle memoize like
this:
memoize(function, { TODISK => filename,
NORMALIZER => function,
INSTALL => newname
});
Each of these three options is optional; you can include some, all, or
none of them.
_________________________________________________________________
INSTALL
If you supply a function name with INSTALL, memoize will install the
new, memoized version of the function under the name you give. For
example,
memoize('fib', INSTALL => 'fastfib')
installs the memoized version of fib as fastfib; without the INSTALL
option it would have replaced the old fib with the memoized version.
_________________________________________________________________
NORMALIZER
Suppose your function looks like this:
# Typical call: f('aha!', A => 11, B => 12);
sub f {
my $a = shift;
my %hash = @_;
$hash{B} ||= 2; # B defaults to 2
$hash{C} ||= 7; # C defaults to 7
# Do something with $a, %hash
}
Now, the following calls to your function are all completely
equivalent:
f(OUCH);
f(OUCH, B => 2);
f(OUCH, C => 7);
f(OUCH, B => 2, C => 7);
f(OUCH, C => 7, B => 2);
(etc.)
However, unless you tell Memoize that these calls are equivalent, it
will not know that, and it will compute the values for these
invocations of your function separately, and store them separately.
To prevent this, supply a NORMALIZER function that turns the program
arguments into a string in a way that equivalent arguments turn into
the same string. A NORMALIZER function for f above might look like
this:
sub normalize_f {
my $a = shift;
my %hash = @_;
$hash{B} ||= 2;
$hash{C} ||= 7;
join($;, $a, map ($_ => $hash{$_}) sort keys %hash);
}
Each of the argument lists above comes out of the normalize_f function
looking exactly the same, like this:
OUCH^\B^\2^\C^\7
memoize knows that if the normalized version of the arguments is the
same for two argument lists, then it can safely look up the value that
it computed for one argument list and return it as the result of
calling the function with the other argmuent list, even if the
argument lists look different.
_________________________________________________________________
TODISK
TODISK means that the memo table should be saved to disk so that it
will persist between invokations of your program. If you use this
option, future runs of your program will get immediate benefit from
the results computed by earlier runs. A useful use of this feature:
You can construct a batch program that runs in the background and
populates the memo table, and then when you come to run your real
program the memoized function will be screamingly fast because al lits
results have been precomputed. Or you would be able to do this, if
TODISK were implemented, which it presently isn't. But it will be.
Some day.
_________________________________________________________________
CAVEATS
Memoization is not a cure-all:
* __Do not memoize a function whose behavior depends on program
state other than its own arguments, such as global variables, the
time of day, or file input. These functions whill not produce
correct results when memoized. For a particularly easy example:
sub f {
my $i = <STDIN>;
chomp $i;
$i;
}
This function takes no arguments, and as far as Memoize is
concerned, it always returns the same result. Memoize is wrong, of
course, and the memoized version of this function will read STDIN
once to get a string from the user, and it will return that same
string every time you call it after that.
* __Do not memoize a function with side effects.
sub f {
my ($a, $b) = @_;
my $s = $a + $b;
print "$a + $b = $s.\n";
}
This function accepts two arguments, adds them, and prints their
sum. Its return value is the numuber of characters it printed, but
you probably didn't care abuot that. But Memoize doesn't
understand that. If you memoize this function, you will get the
result you expect the first time you ask it to prnit the sum of 2
and 3, but subsequent calls will return the number 11 (the return
value of print) without actually printing anything.
* __Do not memoize a function that returns a data structure that is
modified by its caller.
Consider these functions: getusers returns a list of users
somehow, and then main throws away the first user on the list and
prints the rest:
sub main {
my $userlist = getusers();
shift @$userlist;
foreach $u (@$userlist) {
print "User $u\n";
}
}
sub getusers {
my @users;
# Do something to get a list of users;
\@users; # Return reference to list.
}
If you memoize getusers here, it will work right exactly once. The
reference to the users list will be stored in the memo table. main
will discard the first element from the referenced list. The next
time you invoke main, Memoize will not call getusers; it will just
return the same reference to the same list it got last time. But
this time the list has already had its head removed; main will
erroneously remove another element from it. The list will get
shorter and shorter every time you call main.
_________________________________________________________________
TO DO
* __There should be an unmemoize function.
* __We should extend the benchmarking module to allow
timethis(main, MEMOIZED => [ suba, subb ])
What would this do? It would time main three times, once with suba
and subb unmemoized, twice with them memoized.
Why would you want to do this? By the third set of runs, the memo
tables would be fully populated, so all calls by main to suba and
subb wuold return immediately. You would be able to see how much
of main's running time was due to time spent computing in suba and
subb. If that was just a little time, you would know that
optimizing or improving suba and subb would not have a large
effect on the performance of main. But if there was a big
difference, you would know that suba or subb was a good candidate
for optimization if you needed to make main go faster.
* __There was some other stuff, but I forget.
* __Maybe a tied-hash interface to the memo-table, which a hook to
automatically populate an entry if no value is there yet?
_________________________________________________________________
AUTHOR
Mark-Jason Dominus ([12]mjd-perl-memoize@plover.com), Plover Systems
co.
See [13]The Memoize.pm Page for news and upgrades.
References
1. http://www.plover.com/~mjd/perl/Memoize/doc.html#NAME
2. http://www.plover.com/~mjd/perl/Memoize/doc.html#SYNOPSIS
3. http://www.plover.com/~mjd/perl/Memoize/doc.html#DESCRIPTION
4. http://www.plover.com/~mjd/perl/Memoize/doc.html#DETAILS
5. http://www.plover.com/~mjd/perl/Memoize/doc.html#OPTIONS
6. http://www.plover.com/~mjd/perl/Memoize/doc.html#INSTALL
7. http://www.plover.com/~mjd/perl/Memoize/doc.html#NORMALIZER
8. http://www.plover.com/~mjd/perl/Memoize/doc.html#TODISK
9. http://www.plover.com/~mjd/perl/Memoize/doc.html#CAVEATS
10. http://www.plover.com/~mjd/perl/Memoize/doc.html#TO_DO
11. http://www.plover.com/~mjd/perl/Memoize/doc.html#AUTHOR
12. mailto:mjd-perl-memoize@plover.com
13. http://www.plover.com/~mjd/perl/Memoize/
------------------------------
Date: Tue, 17 Feb 1998 00:44:57 -0500
From: Chipmunk <rjk@coos.dartmouth.edu>
To: Ignacio Bustamante <iggiebee@rhpworld.org>
Subject: Pipes, open(), and errors (was Re: PGP - Perl puzzle)
Message-Id: <34E923DC.C0D84929@coos.dartmouth.edu>
[posted and mailed]
Ignacio Bustamante wrote:
>
> However, I have used all the methods, you explained to no avail, since
> there are no errors produced.
>
> Salve J Nilsen wrote:
> >
> > And then, Ignacio suddenly uttered...
> > [...]
> > 4. open(FOO,"|bar baz) || die 'could not open: '.$!; ... Always!
>From Programming Perl, 2 ed., pg 342, Pipes:
Be careful to check the return values of both open and close. (If you're
writing to a pipe, you should also be prepared to handle the PIPE signal,
which is sent to you if the process on the other end dies before you're
done sending to it.) The reason you need to check both the open and the
close has to do with an idiosyncrasy of UNIX in how piped commands are
started up. When you do the open, your process forks a child process that
is in charge of executing the command you gave it. The fork(2) system call,
if successful, returns immediately within the parent process, and the
parent script leaves the open function successfully, even though the child
process may not have even run yet. By the time the child process actually
tries to run the command, it's already a separate scheduled process. So if
it fails to execute the command, it has no easy way to communicate the fact
back to the open statement, which may have already exited successfully in
the parent. The way the disaster is finally communicated back to the parent
is the way that any other disaster in the child process is communicated back:
namely, the exit status of the child process is harvested by the parent
process when it eventually does a wait(2) system call. But this happens in
the close function, not the open function. And that's why you have to check
the return value of your close function. Whew.
--
_ / ' _ / rjk@coos.dartmouth.edu
( /)//)//)(//)/( chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
------------------------------
Date: Tue, 17 Feb 1998 10:13:40 +0100
From: Jesper Henningsen <Henningsen@ith.se>
Subject: print Location: + frames??
Message-Id: <34E954C4.4038@ith.se>
Hi all!
Does anybody know how to link a print "Location: (URL)" to another
frame?
I have no idea how to do that.. and I can't find any related docs on it
on the www either, so any help would be great!
Thanx!
Jesper Henningsen
------------------------------
Date: 17 Feb 1998 04:55:33 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: Quick Reg Expression help
Message-Id: <6cb585$6ik$1@comdyn.comdyn.com.au>
In article <Zena_Goddess_Of_Fire-1602982130530001@magmysmac.lfc.edu>,
Zena_Goddess_Of_Fire@mindless.com (Mike Binkley) writes:
> For example, given the string: "This is a string of characters"
>
> if I searched for "is", I would want back "is is a string of characters"
my $string = "This is a string of characters";
# get everything after the first 'is'
$string =~ /(is.*)$/;
print $1, "\n";
> effects. So I though that:
>
> @tokens = split (/ /, $tokens)
>
> should have exactly the same effect, but it doesn't always seem to work.
> Particularly, it has a tendency to put an null character in the first
> space in the array.
You read the documentation, but maybe not all of it:
perldoc -f split
As a special case, specifying a PATTERN of space (C<' '>) will split on
white space just as split with no arguments does. Thus, split(' ') can
be used to emulate B<awk>'s default behavior, whereas C<split(/ /)>
will give you as many null initial fields as there are leading spaces.
A split on /\s+/ is like a split(' ') except that any leading
whitespace produces a null first field. A split with no arguments
really does a C<split(' ', $_)> internally.
So what you want is
@tokens = split(' ', $tokens);
> And on an unrelated note...is there a good way to access the indices of an
> array that I'm traversing with a foreach loop? or should I just use a for
> loop?
Just use a for like loop:
for (0 .. $#tokens)
{
# $_ is the index here
print $tokens[$_];
}
> Also, if such a method exists, would I run into trouble using it with
> nested loops?
Probably. Just use loop variables, it will make it more readable anyway:
for my $i (0 .. $#tokens)
{
print $tokens[$i];
}
Martien
--
Martien Verbruggen |
Webmaster www.tradingpost.com.au | That's not a lie, it's a terminological
Commercial Dynamics Pty. Ltd. | inexactitude.
NSW, Australia |
------------------------------
Date: 17 Feb 1998 04:36:19 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: script won't run...displays script text
Message-Id: <6cb443$6f4$1@comdyn.comdyn.com.au>
In article <34E8FEA2.C7D140F1@uslink.net>,
SmallWorks <gameday@uslink.net> writes:
> how do i make my perl script run?
http://www.perl.com/CPAN/doc/FAQs/cgi/idiots-guide.html
http://www.perl.com/CPAN/doc/FAQs/cgi/perl-cgi-faq.html
and configure your web server to recognise the thing as a CGI. Or
place it in a directory that is configured to contain CGI scripts.
Contact your ISP to find out if you're allowed to run CGI at all, and
if so, how. etc.. etc..
In other words: This has NOTHING to do with perl.
> I'm using cgi-lib.pl with require "cgi-lib.pl"; in the script...
bad, bad, bad. You should use CGI.pm.
Martien
--
Martien Verbruggen |
Webmaster www.tradingpost.com.au | If it isn't broken, it doesn't have
Commercial Dynamics Pty. Ltd. | enough features yet.
NSW, Australia |
------------------------------
Date: 17 Feb 1998 01:35:25 -0500
From: uri@sysarch.com
Subject: some thoughts on RTFM/FAQ/newbies/moderated
Message-Id: <x7lnvakac2.fsf@sysarch.com>
some background...
i am a professional software engineer with 8 years of perl experience. i
taught myself the language from the camel books (pink and blue) since
that is how i learn, by reading reference manuals. i also went (at my
own expense since i am a consultant) to the first perl conference since
i wanted to be there. i met tom christiansen at a Q&A and he wasn't too
rude in person :-). so i have a lot invested in the perl community.
i have also been using the net since 1974 and usenet for many years andi
have seen both grow and change beyond belief.
now, on to my speech,
many newsgroups have gone to moderated (or the new usenet II) since they
got overwhelmed with spam and newbies. c.l.p.m (among many others) is a
very difficult terrain to navigate now with all of the clueless
questions and useless postings. but we have to figure out some way to
make this work or it will go further into the hell it is descending. so
here are some thoughts:
a year or so ago, i posted to this group after a long abscence. i
received an autoresponded message telling me to make sure i read the
FAQ's and such before i wasted bandwidth on the net. it was funny,
someone with my experience reading that, but i understood where it came
from. why not have that working again for all new posters. how to
maintain the database of who has posted is an issue. this is where a
moderated group would come in. if your question didn't pass muster, you
would at least be pointed to the FAQ. maybe a simple system could parse
the question and even point to the best section of the FAQ. now that
perl.com is fast and stable, the actual URL should be used.
netiquette issues abound in all groups and need to be addressed across
the board. unfortunately with the size and growth of the net it may be
(is) impossible. i agree ALL browsers and ISP's should point/subscribe
the newbies to the comp.answers and other fundamental groups. the
browser help systems should address netiquette issues more including
formatting (word wrap), proper subjects, appropriate groups,
etc. suggestions for better browsers should be put out by the ISP's and
not let IE (spit!) or netscape be the only choices for newsreaders.
tom's expression of anger at micro$hit is justified in my opinion (ask
me about my personal corporate rape by those lying schmucks), but that
rampage last week was too much and fun at the same time. he can't add
killfile entries faster than newbies join the net. he will eventually
join larry in staying out of the group. it would be shame to lose
another guru. this is the best reason for a moderated group.
we should keep c.l.p.m for the newbies but as it has been said, as you
learn from the group you should throw something back. you not so newbies
(but were just months ago) help out the fresh ones. then the more
experienced can help you out. then the gurus can help out folks like
me. maybe a level of experience header is needed? i don't think it could
be made standard on the net but maybe for this group. say all postings
could have a standard (for this group) header or string with a level of
experience or question difficulty. obviously it could be forged but they
could be killfiled. maybe the honor system could work if we start it and
treat it fairly. you would look at postings of levels below you and try
to answer them as you climb the levels yourself. this would still work
best in a moderated group but the moderation would only weed out the
forgers and liars, not all newbie questions. they would still get
answered but by the appropriate users. if a posting did not have a level
header at all, it would be rejected with an autoresponder message
telling them what to do. this could even work for an unmoderated group
if the autresponding system were put back in. remember, the great rabbi
hillel said, "i learn much from my teachers, more from my peers and the
most from my students". let's apply that to this group and show the rest
of usenet how to do it (very hopeful and wishful thinking).
The mini FAQ should be sent out more often, maybe every other day since
we get such a large number of newbies. it should point to all the right
URL's, groups and FAQ's. it should cover some c.l.p.m netiquette
including the level idea (if adopted) and other info like that CGI
problems don't belong here, unless they are perl code issues and not web
issues.
maybe perl itself could be more helpful. perl -w could print out the URL
of the FAQ/miniFAQ if it detects a common error. also if any syntax
errors come up it should mention -w and/or the FAQ or the documents on
that system. since it is compiled for that system, it should have the
correct path to the docs, and a listing of the tools to print and search
them. i don't know that the binary versions of perl (for the non-unix
systems) have the documents in well known paths or that the binary knows
where they are.
i do have a problem with all of the "programmers" out there. i totally
agree with the philosophy that programming is easier and harder than it
is made out to be. simple programming (print "hello, world!\n") is very
easy. module development and such can be very hard and needs years of
experience to do it right (right being my definition, of course). it is
a pyramid of skills out there with thousands of newbies getting their own
web page, hearing about CGI and HTML programming :-) and then about this
amazing language, perl which does all the CGI for you! and is easy to
boot :-) ! so we get flooded with foolish and repeated questions and the
signal to noise ratio tends towards zero. perl made itself too easy to
start and like all programming, it is too hard to be great.
regarding the OS, i agree with tom again that unix is the only choice
for development (and even desktop like i do). most of the newbie
questions seem to come from non-unix boxes, though i have seen some from
users in colleges or web sites hackers who are over there heads with
unix AND perl. pc's (piece of crap is my definition) are end user
'systems' (i use THAT word very lightly) which unfortunately have some
development tools on it, including perl which confuses the issue. most
of the newbies use it (or macs which my wife uses) and don't understand
what they don't know (like a congenitally blind man not getting
color). so it is useless to flame them (however good it might feel), for
they know not what they have signed on to (bill's death ride). but since
they have the volume (in sound and numbers) they are a farce (sic) to be
reckoned with (until bill bites the big one which will be in my
lifetime). one idea is to make perl not available on pc's anymore (tell
activestate) but that won't stop the polluting tide. so we have to come
up with some accommodation.
so to end this quiet and long flame, please stop flaming newbies
immediately. let others try to answer their questions or just
autorespond with the FAQ URL. get the miniFAQ out more often and reply
to the newbies directly with it. let's talk about the honor level system
and maybe push the moderated group again. but most of all let's get this
group back to a functional and useful state like it was when larry was
still involved. i miss his daily wit and insight.
uri
--
Uri Guttman SYStems ARCHitecture and Software Engineering
uri@sysarch.com Have Perl, Will Hack
http://www.sysarch.com "Your Web Specialist"
(617) 643-7504 x*2 FAX: (617) 643-2710 These ARE the opinions of Sysarch!
------------------------------
Date: 17 Feb 1998 02:11:36 -0500
From: David Adler <dha@panix.com>
Subject: T.H.I.N.G.Y. [was: Being Nice 2 Nice Beings [Was: Reading The FAQ's etc.: a teacher's perspective...]
Message-Id: <vx9sopi66zd.fsf_-_@panix.com>
Jaime Metcher <metcher@spider.herston.uq.edu.au> writes:
> This might be an appropriate place to cast my vote for Tom Phoenix for
> the "c.l.p.m Timely, Helpful Information - Nice Guy of the Year" award
> (THINGY). His posts are often a model of brevity and helpfulness, and I
> can't remember any (explicit) RTFM's from him.
Seconded! TomP is truly one of the most important resources we have
here on clpm.
Hey, maybe we should start putting together nominations for special
awards to be given out at the next perl conference:
Best Kermit the Frog impression - Randal Schwartz
Best programming language - Larry Wall for Perl
Best (or, at least, first) Perl user group - ny.pm.org
Hey, we can delegate this to Tom Phoenix... he's got nothing else to
do right? :-)
--
David H. Adler - <dha@panix.com>
"The perversity of the Universe tends towards a maximum."
------------------------------
Date: 17 Feb 1998 08:12:50 GMT
From: ? the platypus {aka David Formosa} <dformosa@st.nepean.uws.edu.au>
Subject: Re: The Young Man and the Beach
Message-Id: <887703128.331831@cabal>
In <6cank9$l2i$2@client3.news.psi.net> abigail@fnx.com (Abigail) writes:
[...]
>I guess you have the legal right to post. But noone has the right to
>get his/her question answered,
Thay don't even have the right to be propergated off your ISP's server.
--
Please excuse my spelling as I suffer from agraphia see the url in my header.
Never trust a country with more peaple then sheep.
Support NoCeM http://www.cm.org/
I'm sorry but I just don't consider 'because its yucky' a convincing argument
------------------------------
Date: Tue, 17 Feb 1998 11:39:26 +0530
From: Prateek Paliwal <iol@bom3.vsnl.net.in>
Subject: Urgent help requiredon Perl and Flocking
Message-Id: <34E92996.5B1C9306@bom3.vsnl.net.in>
I have a site that is visited very
frequently and I need to keep track
of the visitors' profile. I am currently
storing all info in mSQL for which I
generate an id from a counter
which I store in a text file.The problem is
that on concurrent access I end up
with the file either having the wrong
count or nothing at all. This is despite the
fact that I am using flock to lock the
file for exclusive access and
release it only on update of the count.
The part of the script that does the flocking is:
open(COUNT, "+>>$counter") || die" Error $!";
flock(COUNT, 2) || die "Error flocking $!"; # Does it crash here if lock
is not available...
seek(COUNT, 0,0);
# do something...
close(COUNT);
# I even tried something like this:
open(COUNT, "+>>$counter") || die "Error $!";
my $rv = flock(COUNT, 2);
if ( ! $rv ) {
my $endtime = time + 5;
while ( ! $rv && $endtime < time) {
$rv = flock(COUNT, 2);
}
if ( ! $rv ) {
close(COUNT);
die "Could not flock $!";
}
}
Anybody have any clues to what's going on!
I am running it on
FreeBSD 2.1.7-RELEASE with Apache 1.2 and Perl 5.003.
Thanks in advance...
Regards,
Prateeek Paliwal
E-mail: iol@bom3.vsnl.net.in
URL: http://www.winjobs.com
------------------------------
Date: 17 Feb 1998 04:43:18 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: WANTED UK PEARL SCRIPT PROGRAMER
Message-Id: <6cb4h6$6f4$2@comdyn.comdyn.com.au>
In article <genepoolEoI6qG.CLF@netcom.com>,
genepool@netcom.com (Jim Michael) writes:
> Martien Verbruggen (mgjv@comdyn.com.au) wrote:
>
>: Now, if only someone would need my Visual Basic experience.
>
> Could you write a PEARL compiler in Visual Basic?
I don't know how to make the button submit it to the HTML form...
dang..
--
Martien Verbruggen |
Webmaster www.tradingpost.com.au | For heaven's sake, don't TRY to be
Commercial Dynamics Pty. Ltd. | cynical. It's perfectly easy to be
NSW, Australia | cynical.
------------------------------
Date: Tue, 17 Feb 1998 05:48:03 GMT
From: cowboy@cnnw.net (James L. Taylor)
Subject: What does this mean?
Message-Id: <34e92209.82801769@news.cnnw.net>
Hi All,
I'm reading the book "Learning Perl" and I'm wondering if this chunk
of code, is what causes the program to read my personal info off of my
ISP or my system??...It's the "hello world" program and after I
inserted this section of code..I typed filename.pl and it said "Hello
James Taylor"...is this section suppose to do that??
#!/usr/bin/perl
&init_words;
@password = getpwuid($<);
$name = $password[6];
$name =~ s/,.*//;
James L. Taylor
www.bannerfx.com
James L. Taylor
www.bannerfx.com
------------------------------
Date: 17 Feb 1998 05:17:59 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: what is exaclty the "_" Variable ?!?!
Message-Id: <6cb6i7$7p9$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
:That's because Perl doesn't have a special variable called "_"; it has
:two completely different special variables, one called "$_" and another
:called "@_".
It also has a special identifier named "_", which is a filehandle.
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
"The usability of a computer language is inversely proportional to the
number of theoretical axes the language designer tries to grind."
--Larry Wall
------------------------------
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 1918
**************************************
