[6760] in Perl-Users-Digest
Perl-Users Digest, Issue: 385 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Apr 28 10:07:17 1997
Date: Mon, 28 Apr 97 07:00:27 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 28 Apr 1997 Volume: 8 Number: 385
Today's topics:
Re: A simple substitution <a.aitken@unl.ac.uk>
Re: Banner Ad Perl Scripts?? (TCM Online)
Re: Evoke one *.pl in another? <a.aitken@unl.ac.uk>
Re: Evoke one *.pl in another? <jhoglund@skypoint.com>
File Copy <rebecc60@pobox.upenn.edu>
Re: Get Chars up to first | without splitting <a.aitken@unl.ac.uk>
Re: How Does A JS Select Object Receive Data From A CGI <a.aitken@unl.ac.uk>
Re: Installing Perl compiler 5.003 AlvinKoh@WriteMe.COM
Is perl too slow? (Jan "Yenya" Kasprzak)
Re: Ldsa rader och jdmfvra dem med $FORM{'username'} fu (David Alan Black)
Re: Object IDs are bad (was: Ousterhout and Tcl lost th (Andrew Koenig)
Re: Object IDs are good ( was: Object IDs are bad ) (Matthias Blume)
Re: OOP & perl, and web, and lack of time <mcampbel@tvmaster.turner.com>
Re: OOP & perl, and web, and lack of time <tchrist@mox.perl.com>
Perl auto-replier (Chipmunk)
Re: Perl auto-replier (A. Deckers)
Re: Perl auto-replier <tchrist@mox.perl.com>
Re: Perl ODBC and IE 3.0x (Davide Marcato)
Re: Perl on HP 10.20 AlvinKoh@WriteMe.COM
Re: popen like function in perl <a.aitken@unl.ac.uk>
pre-RFD: comp.lang.perl.{data-structure,inter-process,p (A. Deckers)
Re: pre-RFD: comp.lang.perl.{data-structure,inter-proce <seay@absyss.fr>
Re: pre-RFD: comp.lang.perl.{data-structure,inter-proce <qdtcall@k2.kiere.ericsson.se>
Re: pre-RFD: comp.lang.perl.{data-structure,inter-proce <tchrist@mox.perl.com>
Re: pre-RFD: comp.lang.perl.{data-structure,inter-proce (A.Deckers)
Re: Question: nested comment '('...')' removal? (Michael Constant)
Re: switch and if (Chipmunk)
Re: Using timegm and utime in MacPerl <neeri@iis.ee.ethz.ch>
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 28 Apr 1997 13:16:45 +0100
From: Alastair Aitken <a.aitken@unl.ac.uk>
Subject: Re: A simple substitution
Message-Id: <3364952D.57A9@unl.ac.uk>
Lloyd Zusman wrote:
>
> On Mon, 14 Apr 1997 22:05:19 GMT, Jeff Yoak <jeff@yoak.com> wrote:
> > What is a good way to change the first letter of each word in a string
> > to uppercase? I found my self sufficiently confused with s/// and
> > tr/// that I ended up with:
> >
> > @lower = (a..z);
> > foreach $letter (@lower) {
> > $upper = $letter;
> > $upper =~ tr/a-z/A-Z/;
> > $line =~ s/\b$letter/$upper/g;
> > }
> >
> > Somehow, this just seems morally wrong. There must be a better way.
>
> What about this?
>
> $upper = "\u$lower";
>
$string =~ s/(\w+)/\u\L$1/g;
This taken verbatim from:
http://www.perl.com/perl/everything_to_know/regexps.html ~ by Tom
Christiansen - worth a read.
Alastair.
------------------------------
Date: 28 Apr 1997 12:46:49 GMT
From: tcm@wcl.on.ca (TCM Online)
Subject: Re: Banner Ad Perl Scripts??
Message-Id: <5k267p$faj@nr1.toronto.istar.net>
On Sat, 26 Apr 1997 21:31:02 -0700, Herb Rubin <herbr@pfinders.com>
wrote:
>Does anybody know of banner ad Perl scripts that I can tinker with.
>
>Thanks in advance,
>
>Herb Rubin
Take a look at
http://www.cgi-resources.com/Programs_and_Scripts/Perl/
under the 'advertisements' section - being new to Perl, I've been
looking everywhere for example code and the above reference site was
excellent.
Regards,
E. Johnson
------------------------------
Date: Mon, 28 Apr 1997 13:26:55 +0100
From: Alastair Aitken <a.aitken@unl.ac.uk>
Subject: Re: Evoke one *.pl in another?
Message-Id: <3364978F.41BF@unl.ac.uk>
Chris Zeth wrote:
>
> Hi All,
>
> How do I run program.1.pl and have this be a simple call to run
> program.2.pl?
>
> If this is possible, can I send a query variable as well? For example, I
> am calling program.2.pl like this:
>
> /cgi-bin/program.2.pl?QUERY1
>
> How can I included this query variable within the call to this script?
Back through CGI? I presume not ...
If program.1.pl calls program.2.pl then program.2.pl inherits its
environment from program.1.pl. If program.1.pl was called via CGI then
program.2.pl need only read that environment:
in program.2.pl:
$query = $ENV{'QUERY_STRING'};
However, if you really want the variable in the call to the script then:
in program.1.pl:
$param = $ENV{'QUERY_STRING'}; # see the CGI lists for more on
QUERY_STRING
$call = `/path/to/program.2.pl $param`; # $call contains the output from
program.2.pl
then .. in program.2.pl:
$param = $ARGV[1];
Alastair.
------------------------------
Date: Mon, 28 Apr 1997 07:06:35 -0500
From: Jamie <jhoglund@skypoint.com>
Subject: Re: Evoke one *.pl in another?
Message-Id: <336492CB.52B432AE@skypoint.com>
Chris Zeth wrote:
>
> Hi All,
>
> How do I run program.1.pl and have this be a simple call to run
> program.2.pl?
If they are both perl programs, you might be better off with "do".
> If this is possible, can I send a query variable as well? For example, I
> am calling program.2.pl like this:
In the case of CGI, you need to follow the CGI specs, I've used the
"get" method before, set up $ENV{QUERY_STRING} before calling the next
program.
Jamie
------------------------------
Date: Mon, 28 Apr 1997 09:15:23 -0400
From: Becky Schonfeld <rebecc60@pobox.upenn.edu>
Subject: File Copy
Message-Id: <3364A2EB.621C@pobox.upenn.edu>
Can anyone send me or recommend a very simple script to copy file1 to
file2 except for one line from file1? Any help is much appreciated.
------------------------------
Date: Mon, 28 Apr 1997 13:43:11 +0100
From: Alastair Aitken <a.aitken@unl.ac.uk>
Subject: Re: Get Chars up to first | without splitting
Message-Id: <33649B5F.54FC@unl.ac.uk>
Tom Phoenix wrote:
>
> On 25 Apr 1997, Chipmunk wrote:
>
> > In article <335F2EF8.7A61@unl.ac.uk>
> > Alastair Aitken <a.aitken@unl.ac.uk> writes:
> >
> > > ($first) = split /\|/, $line;
> >
> > If you're only keeping the first piece
> >
> > split /\|/, $line, 2;
> >
> > should be a little more efficient.
>
> Perl internally optimizes the first into the second, or so I'm told. But
> if you want efficiency, why use split? Regular expressions aren't anywhere
> near as efficient as index.
>
> $first = substr $line, 0, index($line, '|');
Jeepers! substr(index()) was my very first post to this thread. I
think the above post is an extract
from some Benchmark(ing), note the case :-), I did last week!
Am I being haunted by regexps?
$confusion =~ s/(ass)(elbow)/$2$1/g;
Alastair.
------------------------------
Date: Mon, 28 Apr 1997 14:47:55 +0100
From: Alastair Aitken <a.aitken@unl.ac.uk>
Subject: Re: How Does A JS Select Object Receive Data From A CGI Script?
Message-Id: <3364AA8B.3B7D@unl.ac.uk>
Frank Fisher wrote:
>
> How can I populate a JavaScript SELECT object from a perl .cgi script?
> I have to use the dynamic JS code similar to the following:
>
> mailList.options[mailList.length] = new Option(newAddress,"")
> index = mailList.length
> mailList.options[index - 1].text = editString
>
> and build the Select List Box items dynamically vs using:
>
> <select name="somename">
> <option> one
> <option> two
> </select>
>
> My question is: How can I transfer the cgi script file @array data
> into the JS code so I can dynamically build the List Box?
>
> In other form objects, I can transfer the cgi data using perl a
> $variable place holder in the form object defination such as <INPUT
> VALUE="$perlVariable"> and it gets transferred right over perfectly.
> However, in this case, the form object <SELECT tag> has no VALUE
> option to preload a perl cgi script variable - so how is it done?
um ..
print "<select name=\"somename\">";
foreach (@array) {
print "<option>$_</option>\n";
}
print "</select>";
That for the straight html. If the mailList contents are coming from
the server then you do not need to pass the array contents to javascript
then to html to the browser.
Does that help?
Alastair.
------------------------------
Date: Mon, 28 Apr 1997 18:03:44 +0800
From: AlvinKoh@WriteMe.COM
Subject: Re: Installing Perl compiler 5.003
Message-Id: <AlvinKoh-2804971803440001@fsng172mac.ops.sing.paging.mot.com>
I encountered this before. Try this.
Run Configure, and at the prompt where it runs config.sh, type "!vi config.sh"
Look for chsize and undef it. Then type 'exit' to return to Configure and
proceed from there.
Rgds
Alvin
In article <335A67A9.1F8F@netcomuk.co.uk>, Demon Flash
<dflash@netcomuk.co.uk> wrote:
>Help!!!
>
>I am trying to install the Perl compiler version 5.003 and whenever I am
>ready to make install I get an error.
>
>I am using SCO Unix v386 (version 3.2) with the Development system &
>TCP/IP installed.
>
>The error message is as follows:
>
># make
>install
> cc -o miniperl miniperlmain.o libperl.a -lintl -lnsl_s -ldbm
>-lld -lm -lc -lPW
>-lx
>undefined first referenced
>symbol in
>file
>Perl_chsize libperl.a
>
>ld fatal: Symbol referencing errors. No output written to
>miniperl
>** Error code
>13
>#
>
>If anyone can help could you please e-mail me at one of the addresses at
>the bottom of the page. Any advice or help would be much appreciated.
>
>Thanks.....
>
>--
>Demon Flash, England.
>
>Mailto:dflash@netcomuk.co.uk
>Mailto:demon_flash@hotmail.com
>http://www.netcomuk.co.uk/~jamesmc/dflash.htm
>http://www.hpvca.com
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Alvin Koh <AlvinKoh@WriteMe.COM>
...Today's dreamers are tomorrow's achievers....ZZZZZZZZZZZ....
($$$)-($$$)-($$$)-($$$)-($$$)-($$$)-($$$)-($$$)-($$$)-($$$)-($$$)
------------------------------
Date: Mon, 28 Apr 1997 10:20:57 GMT
From: no_spam_please@fi.muni.cz (Jan "Yenya" Kasprzak)
Subject: Is perl too slow?
Message-Id: <amt1k5.vg1.ln@localhost>
Hi there,
I have visited a www page of my friend, where he compares
speed of various interpreters and compilers. You can visit this page
page at http://www.fi.muni.cz/~pdm/lang-competition.html.
He simply compares a sorting algorithm written in (_not_ built in)
various languages. Perl is there even slower than Java and Emacs LISP.
I have looked at his perl code -- it is rather ugly, but I wasn't
able to achieve any massive speed improvement by rewriting it.
I was able to get a 10%-25% better speed than the original code.
Is perl too slow? Or can anyone write faster sorting algorithm
(not using builtin sort)?
-Yenya
--
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz> http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\ Czech Linux Homepage: http://www.fi.muni.cz/~kas/linux/ ///
/// die_if_kernel("Penguin instruction from Penguin mode??!?!", regs); \\\
// -- from linux/arch/sparc64/kernel/traps.c \\
------------------------------
Date: 28 Apr 1997 11:12:54 GMT
From: dblack@icarus.shu.edu (David Alan Black)
Subject: Re: Ldsa rader och jdmfvra dem med $FORM{'username'} funkar ej
Message-Id: <5k20nm$l3b@pirate.shu.edu>
Hello -
Jonas ThM-vrnvall <labah@algonet.se> writes:
>VarfM-vr blir fM-vljande kod alltid 'true'?
Probably because: "string" ne "string\n";
>for ($i=0;$i<=$SIZE;$i++) {
> $_=$LINES[$i];
chomp;
Another idea: (untested)**
foreach (@LINES) {
chomp;
$old++, last if $FORM{'$username'} eq $_;
}
print GUEST "$FORM{'username'}\n" unless $old;
David Black
dblack@icarus.shu.edu
**If the version of this posting where I put the comma after
GUEST gets through to anyone, please go easy on me. I will
never post unmarked untested code again, not even "1;".....
------------------------------
Date: Mon, 28 Apr 1997 12:08:40 GMT
From: ark@research.att.com (Andrew Koenig)
Subject: Re: Object IDs are bad (was: Ousterhout and Tcl lost the plot with latest paper)
Message-Id: <E9CKEG.Jxx@research.att.com>
In article <s6yg1wclykz.fsf@aalh02.alcatel.com.au> Chris.Bitmead@alcatel.com.au (Chris Bitmead uid(x22068)) writes:
> So all you have to do is generate a unique name for each node, right?
> Just an incremental number perhaps.
Sure, but then I lose the ability to tell whether two trees
have the same value, because they no longer do. So I have to
write a value-comparison routine that ignores the tags.
Of course, I can solve that problem too. But that's not the point.
The point is this: Someone suggested that if we were just to use
a language with a particular set of features (high-order functions,
closures, and something else that I forget at the moment), we would
all realize how horrible C++ was. So I picked one example of such
a language and gave an example of a problem that is not easy to solve
directly in that language. I intended that example (and still do)
as an existence proof that that particular language is not perfect,
thereby gainsaying the claim that the mere existence of these particular
features will show that languages without them are wretched.
Now, of course I can solve these problems in that language if I change
the problems appropriately. That will be true of any language that is
Turing-complete. But the fact is that some languages encourage particular
ways of thinking about programming and other languages encourage
other ways, and I do not believe that any particular way of thinking
about programming styles has an absolute moral superiority over any other.
As yet another example of this, I imagine that an experienced Haskell
programmer would say that generating unique names for each node is
tricky, because doing so is not referentially transparent unless the
serial number of the next node to be generated is passed around the whole
program (I do not think Haskell has global variables, or any way of
imitating them, because they are not referentially transparent). So
I would probably be urged to adopt yet another solution in the name of
referential transparency.
Now, referential transparency is very nice indeed, especially when you're
trying to reason about programs and prove their properties. But
writing substantial programs that are referentially transparent requires
yet another dramatically different way of thinking about programming,
which carries its own set of advantages and disadvantages.
In practice, which of those disadvantages you are willing to accept in
trade for which of those advantages should depend on the context, which
includes the problems you're trying to solve, the problems you might
be trying to solve in the future, the support structure that is available,
the local culture, your own experience and taste, and so on.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
------------------------------
Date: 27 Apr 1997 14:54:09 -0400
From: blume@mocha.cs.princeton.edu (Matthias Blume)
Subject: Re: Object IDs are good ( was: Object IDs are bad )
Message-Id: <izpvvgcn5a.fsf@mocha.CS.Princeton.EDU>
In article <E9AxB1.7nA@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
In article <izhggvrukk.fsf@mocha.CS.Princeton.EDU>,
Matthias Blume <blume@mocha.cs.princeton.edu> wrote:
>
> - Things that _actually_ look the same in each and every
> respect_are_ the same. Things that we can distinguish between
> do _not_ look the same (by definition -- this is what we mean by
> being able to distinguish).
I wouldn't necessarily agree. The difficulty lies in mutable objects. If
I have two mutable objects, alike in every way, and I change one, then the
other doesn't change. [ ... ]
Sorry, you are right, but you missed my point. If there is an
operation (here: modify one object and observe the change -- or
rather: non-change -- in the other), that lets you distinguish between
the two things, then they don't look the same (and never did). It's a
matter of what one means by "they look the same".
I think if a language has the concept of mutability, then it should also
have the concept of object identity because both the cases presented in
the previous paragraph are very useful in different curcumstances.
Of course if a language has no mutability, then object identity is
unnecessary.
And moreover, if the language has both mutable _and_ immutable things,
then it should support the concept of identity for the former and not
for the latter. Since that was what started the thread: ML is such a
language, and it gets this issue exactly right.
--
-Matthias
------------------------------
Date: 28 Apr 1997 07:43:03 -0400
From: Mike Campbell <mcampbel@tvmaster.turner.com>
Subject: Re: OOP & perl, and web, and lack of time
Message-Id: <r5sp0bjrug.fsf_-_@tvmaster.turner.com>
Tom Christiansen <tchrist@mox.perl.com> writes:
> I cannot begin to have the time in my life right now to do any web
> maintenance. ...
And then in the next message I see,
> I am creating a web page that contains the real addresses of
> everyone who posts a bogus address in their mail message. ...
------------------------------
Date: 28 Apr 1997 12:19:17 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: OOP & perl, and web, and lack of time
Message-Id: <5k24k5$iku$1@csnews.cs.colorado.edu>
Yup. So I added more in the filter lists.
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
_doprnt(pat, args, &fakebuf); /* what a kludge */
--Larry Wall, from util.c in the v5.0 perl distribution
------------------------------
Date: 28 Apr 1997 04:35:03 GMT
From: Ronald.J.Kimball@dartmouth.edu (Chipmunk)
Subject: Perl auto-replier
Message-Id: <5k19dn$f9s$2@dartvax.dartmouth.edu>
Here's a great idea for a perl script.
Something which scans the posts to comp.lang.perl.misc and
automatically generates replies to posters' questions. Replies such
as:
"You moron, look at the perlxxx man pages."
"You moron, that's not a Perl question, try comp.xxx.xxx.xxx."
"You moron."
Such a script would definitely save certain posters to this newsgroup a
lot of time and effort spent replying to questions. (Not mentioning
any names.)
Chipmunk
------------------------------
Date: 28 Apr 1997 12:30:18 GMT
From: I-hate-cyber-promo@man.ac.uk (A. Deckers)
Subject: Re: Perl auto-replier
Message-Id: <slrn5m962j.pfs.I-hate-cyber-promo@nessie.mcc.ac.uk>
In comp.lang.perl.misc,
Ronald.J.Kimball@dartmouth.edu wrote:
>Here's a great idea for a perl script.
>
>Something which scans the posts to comp.lang.perl.misc and
>automatically generates replies to posters' questions.
Tom Christiansen already does that. :-)
Alain
--
Perl information: <URL:http://www.perl.com/perl/>
Perl FAQ: <URL:http://www.perl.com/perl/faq/>
Perl archive: <URL:http://www.perl.com/CPAN/>
------------------------------
Date: 28 Apr 1997 12:48:55 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Perl auto-replier
Message-Id: <5k26bn$jnu$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc, Ronald.J.Kimball@dartmouth.edu (Chipmunk) writes:
:Something which scans the posts to comp.lang.perl.misc and
:automatically generates replies to posters' questions. Replies such
:as:
:
:"You moron, look at the perlxxx man pages."
:"You moron, that's not a Perl question, try comp.xxx.xxx.xxx."
:"You moron."
:
:Such a script would definitely save certain posters to this newsgroup a
:lot of time and effort spent replying to questions. (Not mentioning
:any names.)
I have a much better answer: remove all Perl documentation. It's obvious
that 90% of the posters don't grep it before posting.
This is not a newsgroup full of babysitters dedicated to reading children
stories out of the perl manpages at night before they go to sleep.
Nor is it a place to whine your way into limitless free consulting help.
It isn't even the place for those who refuse to follow netitquette and
find the right newsgroup before asking how to tie their shoes or walk
their dog (or program in bash). This isn't, in fact, just a simple
q&a forum, although it's been a long time since I've seen any threads
beyond that.
When's the last time you saw a posting by Larry? Ever wonder about that?
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
: And it goes against the grain of building small tools.
Innocent, Your Honor. Perl users build small tools all day long.
--Larry Wall in <1992Aug26.184221.29627@netlabs.com>
------------------------------
Date: Mon, 28 Apr 1997 11:22:58 GMT
From: davmarc@ashnet.it (Davide Marcato)
Subject: Re: Perl ODBC and IE 3.0x
Message-Id: <336373a5.2793439@news.interbusiness.it>
On Thu, 24 Apr 1997 16:08:30 +0200 Petri Backstrom
<...petri.backstrom@icl.fi> wrote:
>Unchecking that box, and checking "Basic (Clear Text)" (which, if
>my memory serves me right, is not checked by default) and "Allow
>Anonymous".
>
>Unless, of course, one wishes to take advantage of this IE/IIS
>feature. Benefits are that authentication is "automatic" (or
>should I say transparent), with no passwords transmitted for
>WWW authentication on the wire.
Actually Basic authentication doesn't offer any real security benefit: the
password is still transmitted from IE to IIS but is also base64 encoded,
which is not safe since its decoding algorithm is public and well-known!
If a hacker has the skills and the instruments to steal a Basic password,
he is likely to steal even Challenge/Response ones.
Davide Marcato.
--------------------------------------------------------
| -- AshNet S.r.l.
| -- C/C++ & Windows Developer
| -- Internet Developer & Administrator
| -- Technical Writer
--------------------------------------------------------
| -- E-Mail: davmarc@ashnet.it - marcato@programmers.net
| -- WWW: http://www.ashnet.it
| -- WWW: http://www.netics.net
--------------------------------------------------------
------------------------------
Date: Mon, 28 Apr 1997 18:00:11 +0800
From: AlvinKoh@WriteMe.COM
Subject: Re: Perl on HP 10.20
Message-Id: <AlvinKoh-2804971800110001@fsng172mac.ops.sing.paging.mot.com>
Yes, for both series 700 and 800. What problems are you having?
Rgds
Alvin
In article <3357E393.78A2@mentorg.com>, Matt McIntosh
<matt_mcintosh@mentorg.com> wrote:
>I was wondering if anybody out there has successfully built Perl on a HP
>10.20 machine. If you have I could use some help.
>Thanks.
>--
>
><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><->
>
>Matt McIntosh Mentor Graphics Corporation
>matt_mcintosh@mentorg.com Phone: (503) 685-1773
>mattm@wv.mentorg.com 1-800-592-2210 ext. 1773
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Alvin Koh <AlvinKoh@WriteMe.COM>
...Today's dreamers are tomorrow's achievers....ZZZZZZZZZZZ....
($$$)-($$$)-($$$)-($$$)-($$$)-($$$)-($$$)-($$$)-($$$)-($$$)-($$$)
------------------------------
Date: Mon, 28 Apr 1997 12:57:21 +0100
From: Alastair Aitken <a.aitken@unl.ac.uk>
Subject: Re: popen like function in perl
Message-Id: <336490A1.4995@unl.ac.uk>
Kevin Mulholland wrote:
> I am looking for a popen like function to use in my perl scripts.
> I need to run a command in the background and take its output an
> display it in a foreground program. Is there any easy way to do this ?
> It is imperitive that I see the output 'as it happens' not just look at
> it after the background program has finished running.
Running a script in background from a shell will print to the screen if
the script is configured to print
to STDOUT (the default) and if you are using a non-window system.
Problems arise when the default output is not your current display -
such as running the script from cron.
If you are running an ls -l when the script reports to you you might
miss it.
What about an audible warning rather than a simple print to STDIN?
Alastair.
------------------------------
Date: 28 Apr 1997 12:24:15 GMT
From: I-hate-cyber-promo@man.ac.uk (A. Deckers)
Subject: pre-RFD: comp.lang.perl.{data-structure,inter-process,porters,regex}
Message-Id: <slrn5m95n8.g1r.I-hate-cyber-promo@nessie.mcc.ac.uk>
[[NB: the email address included in the headers is valid, but I've
started using it in all my posts to Usenet. This way I get to filter
out most of the spam. Fear not, anything you send to that address with
/perl/i in the subject line will get to me and will be read.]]
Pre-RFD for additional clp.* groups.
====================================
I presume that I am not the only one who finds the volume of traffic in
comp.lang.perl.misc somewhat overwhelming. I also know that some people
in the Perl community are not entirely satisfied with the current
operation of the comp.lang.perl.* (clp.*) newsgroups.
I am therefore publishing this pre-RFD to air some ideas that might help
improve the usefullness of the clp.* groups and generate some interest in
the issue.
I have consulted a limited number of clpm regulars before
publishing this pre-RFD and they haven't voiced any strong opinions
either way (the prevailing attitude seems to be "fine, but I don't want
to get involved"), hence I'm putting this out for public comment.
My personal position is that though I would very much like a change in
the clp.* groups, I will not proceed with a formal RFD unless either
the Perl Institute takes it on board or a substantial number of the
regular posters to clp.* are willing to put their names forward as
co-proponents for a future RFD.
The clp.* hierarchy that I envisage would look something as follows:
M comp.lang.perl.announce Perl-related announcements.
+ m comp.lang.perl.data-structure Perl data-structures (array, hash, object).
comp.lang.perl.misc Miscelaneous Perl-related issues.
comp.lang.perl.modules Writing Perl modules.
+ m comp.lang.perl.inter-process Inter-Process Communications in Perl.
+ m comp.lang.perl.porters Extending Perl and porting to non-native OS's.
+ m comp.lang.perl.regex Perl's regular expressions.
comp.lang.perl.tk Tk extension for Perl.
NOTES:
+ indicates new group
m indicates auto-moderated group
M indicates hand-moderated group
For the clp.{data-structure,inter-process,regex} groups I envisage an
automatic moderation system. The only restriction that will be applied is
that cross-posts will be limited to clp.misc and clp.announce. In the
latter case, they would already incude an Approved header from the
clp.announce moderator, who could be given blanket approval to post to
other clp.* groups (and similarly for designated groups such as *.answers
and news.announce.newgroups, for example).
In addition, the moderation software could reject any article that
doesn't match /\bperl\b/i in either in the Subject header or in the
body . I just got this idea from Randal's autoack for submissions to
clp.announce. :-) A per-group keyword could be used, eg /tk/i for the
Tk group, /module/i for the modules group, etc.
In order to reduce propagation delays, I propose that the submission
address should be a mailing list and that the moderation script should
be made publically available. Thus, anyone can install the moderation
script, create a mail alias, subscribe it to the mailing list, and
start injecting articles into his or her local server.
This should actually *improve* propagation over the current situation. An
additional benefit of this system would be that those who preferred to
receive the group(s) via email could easily do so. Digests would also be
an option (just forward stuff sent to the submission address to a
majordomo list, for example).
While this might create a single point of failure for the moderated
groups, any delays introduced by server/network outages should be
minimised by locating the submission address at a well
connected/managed site. The unmoderated clp.misc could always be used
as a fall-back on those, hopefully rare, occasions when the moderated
groups are down.
The moderation script could also implement an autofaq mailing to first time
posters, similar to the one currently implemented in clp.misc. I'm sure
John Stanley will flame me for suggesting this. :-) (Obviously only one
moderation site would implement the autofaq feature.)
An open question is whether this moderation scheme should be extended to
the existing clp.* groups, namely clp.{modules,tk}. It would probably be
best if clp.misc remained unmoderated whatever happened.
No doubt the clp.porters suggestion will be controversial. As you know,
this traffic is currently carried by a mailing list and gated to a
local newsgroup on a single server. I have picked the name *.porters
after considering and rejecting *.developers (likely to attract loads of
inappropriate traffic) and *.workers (ditto). I have been made aware of
the fact that a proposal for comp.lang.perl.guts was made in the past but
fell foul of the "USENET Gods".
In addition to the name of the group, I see two further problems which
need to be solved before this group can go ahead:
i- ensuring a very high signal/noise ratio.
Many people on the p5p list would be unlikely to participate in the
group if the signal/noise ratio dropped noticeably below that which
exists on the p5p list and the corresponding gated group. The
moderation procedure must take this into account. Full hand moderation
is probably not practical, though (unless a large enough number of
volunteer moderators put themselves forward).
ii- foisting spammers harvesting email addresses.
This is likely to put some people off posting to clp.porters
altogether. While it would be possible to make the moderation script
add a spam-busting string to the email addresses in submitted articles,
this would no doubt not be acceptable to a number of people. I don't
know how to deal with this, and it may well be a fatal objection to the
creation of the group, much as I hate giving in to the spammers.
Until a global solution to this problem becomes available, it will
probably be necessary for each poster to implement a spam filter.
I hereby solicit feedback on the following issues:
0- whether this pre-RFD contains usefull ideas and whether they should be
pursued further;
1- whether the proposed additional groups are well chosen, and if not,
what the alternatives should be;
2 - whether the names of the new groups are adequate, and if not, what the
alternatives should be;
NB: I have already considered and rejected the following names for the
IPC group (reason for rejection in brackets): clp.ipc (obscure
abreviation), clp.networking (likely to lead some people astray).
3- whether the proposed auto-moderation scheme seems adequate in
principle, and if not, how it should be modified;
4- whether the auto-moderation scheme should be extended to the existing
clp.{modules,tk} groups.
5- whether it is worth going to the trouble of setting up clp.porters, or
if this will generate more costs than benefits. Since I don't participate
on the porters mailing list (though I occasionally read the gated
newsgroup), I will bow to whatever prevailing opinion emerges among
those who do.
6- anything else that you want to say about this pre-RFD. :-)
Please note that followups have been set to comp.lang.perl.misc.
Cheers,
Alain
--
Perl information: <URL:http://www.perl.com/perl/>
Perl FAQ: <URL:http://www.perl.com/perl/faq/>
Perl archive: <URL:http://www.perl.com/CPAN/>
------------------------------
Date: Mon, 28 Apr 1997 15:06:36 +0100
From: Douglas Seay <seay@absyss.fr>
To: I-hate-cyber-promo@man.ac.uk
Subject: Re: pre-RFD: comp.lang.perl.{data-structure,inter-process,porters,regex}
Message-Id: <3364AEEC.26DCEB5D@absyss.fr>
[posted and mailed]
A. Deckers wrote:
<snip>
> The clp.* hierarchy that I envisage would look something as follows:
>
> M comp.lang.perl.announce Perl-related announcements.
> + m comp.lang.perl.data-structure Perl data-structures (array, hash, object).
> comp.lang.perl.misc Miscelaneous Perl-related issues.
> comp.lang.perl.modules Writing Perl modules.
> + m comp.lang.perl.inter-process Inter-Process Communications in Perl.
> + m comp.lang.perl.porters Extending Perl and porting to non-native OS's.
> + m comp.lang.perl.regex Perl's regular expressions.
> comp.lang.perl.tk Tk extension for Perl.
<snip>
> 6- anything else that you want to say about this pre-RFD. :-)
Yes, you left off
comp.lang.perl.www Web applications using Perl
That is the only one I want to see created. I'm interested in the other
topics as they relate to Perl. Many/most of the web questions deal with
non-Perl issues. I want a CGI magnet newsgroup so I can more easily
ignore this stuff.
- doug
------------------------------
Date: 28 Apr 1997 15:19:27 +0100
From: Calle Dybedahl <qdtcall@k2.kiere.ericsson.se>
Subject: Re: pre-RFD: comp.lang.perl.{data-structure,inter-process,porters,regex}
Message-Id: <isbu6zxma8.fsf@k2.kiere.ericsson.se>
Douglas Seay <seay@absyss.fr> writes:
> That is the only one I want to see created. I'm interested in the other
> topics as they relate to Perl. Many/most of the web questions deal with
> non-Perl issues. I want a CGI magnet newsgroup so I can more easily
> ignore this stuff.
Agreed, but perhaps comp.lang.perl.cgi would be a better name? Not only is
it more obvious, it also comes before .misc when sorted alphabetically.
--
Calle Dybedahl, UNIX Sysadmin
qdtcall@esb.ericsson.se http://www.lysator.liu.se/~calle/
------------------------------
Date: 28 Apr 1997 13:26:42 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: pre-RFD: comp.lang.perl.{data-structure,inter-process,porters,regex}
Message-Id: <5k28ii$lm2$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc, Douglas Seay <seay@absyss.fr> writes:
: comp.lang.perl.www Web applications using Perl
:That is the only one I want to see created. I'm interested in the other
:topics as they relate to Perl. Many/most of the web questions deal with
:non-Perl issues. I want a CGI magnet newsgroup so I can more easily
:ignore this stuff.
There is such a group already. It doesn't attract people.
Why should we make a CGI group when one already exists?
I point out again the java groups for comparison:
comp.lang.java The Java Programming Language
comp.lang.java.advocacy Support for and criticism of the Java System.
comp.lang.java.announce Announcements re the Java System. (Moderated)
comp.lang.java.api The Java application programming interface.
comp.lang.java.misc Miscellaneous topics on using the Java System.
comp.lang.java.programmer Programming in the Java language.
comp.lang.java.security Security issues raised by Java.
comp.lang.java.setup Setting up a Java browser.
comp.lang.java.tech Technical aspects of Java, its inner workings.
comp.lang.javascript Netscape Communications Corp.'s JavaScript language.
You might look at the unix groups, too, for comparison.
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
That means I'll have to use $ans to suppress newlines now.
Life is ridiculous.
--Larry Wall in Configure from the perl distribution
------------------------------
Date: 28 Apr 1997 13:31:38 GMT
From: I-hate-cyber-promo@man.ac.uk (A.Deckers)
Subject: Re: pre-RFD: comp.lang.perl.{data-structure,inter-process,porters,regex}
Message-Id: <slrn5m99lq.kli.I-hate-cyber-promo@news.rediris.es>
In comp.lang.perl.misc,
seay@absyss.fr wrote:
>Yes, you left off
>
> comp.lang.perl.www Web applications using Perl
>
>That is the only one I want to see created. I'm interested in the other
>topics as they relate to Perl. Many/most of the web questions deal with
>non-Perl issues. I want a CGI magnet newsgroup so I can more easily
>ignore this stuff.
Actually, during the email discussions that lead to this pre-RFD, I
toyed with the idea of proposing comp.lang.perl.cgi. :-)
But no, since such a group would essentially duplicate
comp.infosystems.www.authoring.cgi, I would vote against it if it came
to a CFV. I think people should be taught to post in the right
group, rather than accomodating their ignornce by creting extra
groups of dubious value.
Alain
--
Perl information: <URL:http://www.perl.com/perl/>
Perl FAQ: <URL:http://www.perl.com/perl/faq/>
Perl archive: <URL:http://www.perl.com/CPAN/>
------------------------------
Date: 28 Apr 1997 05:14:16 -0700
From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant)
Subject: Re: Question: nested comment '('...')' removal?
Message-Id: <5k24ao$334@soda.CSUA.Berkeley.EDU>
Ying Chen <yingchen@fir.fbc.com> wrote:
>The question is.. if you know all parenthesis are matched and
>if you don't have to care about the contents within the
>parenthesis (because the contents are comment in this
>case) - but because comment can be nested and escaped... like:
> (junk (\(comment\) to junk (is junk ))) important (again junk)
>is it still possible to write a regexp to just remove the comments?
It can be done easily, if not efficiently:
s/\\(.)/sprintf '\%02x', ord $1/eg;
1 while s/\([^()]*\)//g;
s/\\(..)/"\\" . chr hex $1/eg;
The first line searches for a backslash followed by any character,
and replaces the character with its ascii value in hex. This is so
quoted parens will be ignored by the second line.
The second line searches for simple blocks of text enclosed in parens,
and deletes them. By "simple", I mean a block of text that contains
no parens itself; this is why we have to execute the second line
repeatedly, until it can extract no more text. (The first iteration
removes the innermost comments, leaving the next innermost comments
as simple comments; the next iteration removes those, and so on.)
The third line searches for the quoted text created by the first line,
and restores the original quoted characters.
If you need to run this under perl4, replace the first line with
s/\\(.)/sprintf('\\%02x', unpack('C', $1))/eg;
and the third with
s/\\(..)/"\\" . pack('C', hex $1)/eg;
The ord and chr functions don't exist in perl4, so we emulate them
with pack and unpack; a few more parentheses are needed; and weird
parsing necessitates an extra backslash in the sprintf format.
If you don't need the ability to quote parentheses, you can remove
the first and third lines.
--
Michael Constant (mconst@soda.csua.berkeley.edu)
------------------------------
Date: 28 Apr 1997 04:22:54 GMT
From: Ronald.J.Kimball@dartmouth.edu (Chipmunk)
Subject: Re: switch and if
Message-Id: <5k18mu$f9s$1@dartvax.dartmouth.edu>
I know that there is no switch statement in Perl. When I implied that
there was a switch statement in Perl, I was kidding. I was replying to
someone who asked:
> Is it better to use an if statement or switch, or doesn't it make much
> difference.
Obviously, since there is no switch statement, it is better to use an
if statement. Since it was so obvious, however, I decided to be
contrary and state the opposite.
I am fully aware that Perl does not have a switch statement.
Everybody got that?
Chipmunk
------------------------------
Date: 28 Apr 1997 13:29:18 +0200
From: Matthias Neeracher <neeri@iis.ee.ethz.ch>
Subject: Re: Using timegm and utime in MacPerl
Message-Id: <86vi57bd2p.fsf@iis.ee.ethz.ch>
Ben <B.P.Fowler@rack.demon.co.uk> writes:
> However, timegm does not give the correct result for dates
> after 1971.
>
> I think that this is because the Mac uses 1904 as the epoch, and
> 2 147 483 647 second (just over 68 years) brings us to the
> year in question. A further 68 years brings us to 2038, and I
> suspect that I would be OK if utime used unsigned integers.
Your analysis is essentially correct. The Mac's use of unsigned ints for
seconds causes some problems, which are aggravated by the fact that MacPerl is
still based on perl 5.002_01. I'm waiting for the release of perl 5.004 to
upgrade the Perl core of MacPerl, and at that time, I'll try to fix all the
time related problems.
Matthias
-----
Matthias Neeracher <neeri@iis.ee.ethz.ch> http://www.iis.ee.ethz.ch/~neeri
"I'm set free to find a new illusion" -- Velvet Underground
------------------------------
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 385
*************************************
