[8207] in Perl-Users-Digest
Perl-Users Digest, Issue: 1825 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 6 21:13:24 1998
Date: Fri, 6 Feb 98 18:00:23 -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 Fri, 6 Feb 1998 Volume: 8 Number: 1825
Today's topics:
AUTOLOAD subroutine <achoy@us.oracle.com>
Re: Data Conversion (COBOL PIC S9999V99 to/from Perl) (Sitaram Chamarty)
Re: Data Conversion <boyletd@istar.ca>
Re: Determine if machine is connected to the Net? (David Efflandt)
Fork is cheap and powerful <tchrist@mox.perl.com>
How do copy files based on pattern on original file nam ckcheng@tribune.com
Re: Is Perl 5 year 2000 compliant? (Devin L. Ganger)
Re: Is Perl 5 year 2000 compliant? <swd@strata-group.Xcom>
Re: killing a child process after a timeout <tchrist@mox.perl.com>
MacPerl_not_even_newbie (Ddarras)
Re: Method Invocation: non-intuitive behaviour or is it <tchrist@mox.perl.com>
Re: Permission Help!! (David Efflandt)
Re: quick .signature hack (Christopher Masto)
Re: quick .signature hack (Craig Berry)
Reading The FAQ's etc.: a teacher's perspective... (Lynchqvctc)
Re: Regex From Hell? <daftary@cisco.com>
Sending a message to a pager (team lamer)
Re: Socket Connections (David Efflandt)
sorting hash by numeric values rlindner@avsgroup.com
Re: Unpack float <tchrist@mox.perl.com>
Re: variable -> form ->varibale (David Efflandt)
Year 2000 Compliance: Lawyers, Liars, and Perl <tchrist@mox.perl.com>
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 06 Feb 1998 16:23:04 -0800
From: Allen Choy <achoy@us.oracle.com>
Subject: AUTOLOAD subroutine
Message-Id: <34DBA968.FA250D8F@us.oracle.com>
Hi,
Is it possible to share an AUTOLOAD subroutine by several modules?
Thanks in advance--Allen
------------------------------
Date: 6 Feb 1998 23:18:06 GMT
From: sitaram@diac.com (Sitaram Chamarty)
Subject: Re: Data Conversion (COBOL PIC S9999V99 to/from Perl)
Message-Id: <slrn6dn11s.7l.sitaram@ltusitaram.diac.com>
On Fri, 06 Feb 1998 10:28:38 GMT, Bart Lateur <bart.mediamind@tornado.be> wrote:
>vhartley@sybase.com wrote:
>
>>Does anyone know of any modules for converting signed decimal
>>and packed fields to the Perl numerics and vice versa.
>
>>Problem: I get an ASCII file thats created by a COBOL program which
>>writes a money field using S9999V99. I need to convert this field to a
>>Perl numeric, do some math, then write the result in the same original
>>format.
>
>I don't know Cobol. So I don't know what "S9999V99" means. But I'm
S stands for Sign alright. But unless the field is further decalred with
"SIGN LEADING SEPARATE" or "SIGN TRAILING SEPARATE", this means the sign is
overpunched onto either the first or the last digit. So the total length is
still 6 bytes. (You didnt mention any COMP usage clause - if so the whole
story changes!)
Which digit is ovepunched (first or last) and what is the nature of the
overpunch will depend on your COBOL compiler/vendor. MicroFocus, for
instance, will overpunch the last digit, and the overpunch will be an OR-ing
with 0x40. (The characters "p" thru "y" represent negative 0 thru negative 9)
The V is an *implicit* decimal point. (Remember that COBOL is mainly used for
business computation, where the rounding that floating point forces - as seen
in occasional complaints to this newsgroups like "1/3*3 = 0.999999!!!" or
whatever - are verboten).
Your S9999V99 can store values between -9999.99 and +9999.99. Assuming a
compiler much like the MicroFocus one I described, a value or 1804.37 would be
represented as "180437" - just those 6 characters. -1804.37 would be
"18043w", since "w" (ASCII code 0x77, is the result of ORing "7" and 0x40).
To read the value into Perl:
($Perl_number = $COBOL_number) =~ tr[p-y][0-9];
substr($Perl_number,4) = "." . substr($Perl_number,4);
That should be your number. Remember that just because it's declared S9999V99
doesnt mean the data you get is valid - be sure to check the input with a
suitable regexp first...
To write back the value, do the reverse. Use sprintf to get a 6-digit,
0-filled on the left, with 2 decimal places (37 becomes 0037.00, 804.37
becomes 0804.37). Then chop off the ".", and tr the last digit in the
opposite way as before (0-9 -> p-y). Done.
Be sure to check your COBOL version to see if the bit about which digit is
overpunched and how is valid. Change accordingly. Email if you need more
help, but I'll need to see a few sample "numbers", preferably ones containing
at least one non-digit. Cause I certainly dont remember the conventions of
all the COBOLs that I have worked with :-)
HTH
Sitaram
-------
Hoping I dont get kicked out of this newsgroup now that my dark secret is out
:-)
------------------------------
Date: Sat, 07 Feb 1998 00:31:21 GMT
From: "Tom Boyle" <boyletd@istar.ca>
Subject: Re: Data Conversion
Message-Id: <01bd3360$350d8f40$770435c6@boyletd>
vhartley@sybase.com wrote in article <886744299.1197277192@dejanews.com>...
> Does anyone know of any modules for converting signed decimal
> and packed fields to the Perl numerics and vice versa.
>
> Problem: I get an ASCII file thats created by a COBOL program which
> writes a money field using S9999V99. I need to convert this field to a
> Perl numeric, do some math, then write the result in the same original
> format.
>
> -------------------==== Posted via Deja News ====-----------------------
> http://www.dejanews.com/ Search, Read, Post to Usenet
>
I support PC to mainframe connections and I've heard this kind of request
several times before. I'm just starting at Perl and my COBOL is near
non-existent so I won't presume to give advice on conversion. However,
there is a good chance that your data comes from a program written
specifically to extract it from a larger store specifically for downloading
to whatever your ASCII system is. If this is the case, and if you can ge
the COBOL programmers to cooperate, and if they have the time (there, I
think I've qualified that enough), then ask to them to format the data in a
more ASCII friendly fashion. Assuming that this is an extract, the
original programmer may have used packed decimal simply because that's what
the original source was formatted as. I believe that it is just a change
in a PIC statement at the COBOL end which is a lot easier than what you'll
have to go through.
Tom
------------------------------
Date: Sat, 07 Feb 1998 00:42:20 GMT
From: efflandt@xnet.com (David Efflandt)
Subject: Re: Determine if machine is connected to the Net?
Message-Id: <34ddab5d.3240241@flood.xnet.com>
fl_aggie@thepentagon.com (I R A Aggie) wrote:
>In article <6bfrrh$p38@shell.clark.net>, hdiwan@shell.clark.net (Hasan
>Diwan) wrote:
>
>+ I am not entirely sure if this will work, but check the return value
>+ from system("ping"); and based on it, continue with the program (check
>+ the man page for the return values).
>
>Why call an external shell?
>
> use Net::Ping;
>
> $p = Net::Ping->new();
> print "$host is alive.\n" if $p->ping($host);
> $p->close();
This did not work with new() (which defaults to udp), but did work
with new(icmp) which is the UNIX method. However, it would hang if
not connected (or if autoconnect failed) due to delayed hostname
lookup. Possibly this method with IP instead of hostname would work.
For some reason pingecho($host) [which uses tcp] failed even for
'localhost' or when already connected via PPP.
>This will require the libnet modules to be installed. This is an
>interesting question, and the "ping" solution is dependent on whether
>or not a particular machine is able to answer a ping request. My feeling
>is that there is a Better Way.
>
>But I'm not sure what that is.
>
>James
David Efflandt/Elgin, IL USA
efflandt@xnet.com http://www.xnet.com/~efflandt/
------------------------------
Date: 4 Feb 1998 14:44:18 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Fork is cheap and powerful
Message-Id: <6b9us2$7pr$3@csnews.cs.colorado.edu>
Contrary to what prisoners of a lesser operating system will tell you,
fork is a elegant and inexpensive solution to many multitasking needs.
Be not deceived!
The following example shows the effect of forking large perl processes
on your vmsytem. For example, here is the first 6 lines of output
(the second argument is the head -N param) of running 2**7 processes
(seven being the number of forks.)
chthon(tchrist)% perl /tmp/chkfork 7 6
7128 Cached 21M 21M 21M 21M 21M 21M 21M
7128 MemFree 42M 41M 41M 41M 40M 39M 36M
7128 MemTotal 124M 124M 124M 124M 124M 124M 124M
7128 SwapFree 251M 251M 251M 251M 251M 251M 251M
7128 Buffers 24M 24M 24M 24M 24M 24M 24M
7128 MemShared 48M 55M 61M 78M 113M 181M 290M
Each column N above (well, after the pid and type fields) is that data
after 2**N forks.
Notice how slow "MemFree" is to go down, and how quick
"MemShared" is to go up.
Because this relies upon the layout of /proc/meminfo, it's not
expected to run elsewhere than linux without some help.
Notice how head(N) works like a post-processing pipe to head -N.
Also notice all the piping action without any explicit calls to
the pipe() function.
I guess what I'm hoping people see is how fork is far from dead, but
works quite well for single applications with concurrent multiple
threads of execution.
Time of that run says: 0.390u 0.180s 0:04.61 12.3% 0+0k 0+0io 233pf+0w
--tom
#!/usr/bin/perl
## usage: chkfork [ N [ L ] ]
## We check memory changes in /proc/meminfo.
## This start 2**N processes. N defaults to 0.
## We only show the first L lines. L defaults to all.
use strict;
BEGIN { die "This isn't linux." unless $^O =~ /linux/i; }
# use Fcntl qw(:flock);
use vars qw($MEMINFO $Filter_Pid);
$MEMINFO = "/proc/meminfo";
my $Count = shift || 0;
my $Lines = shift || 0;
filter();
@::GOBBLE = ("fred") x 100000; # gobble lotsa memory
show_info();
while (--$Count > 0) {
fork;
show_info();
}
unfilter();
exit;
################################################
sub show_info {
open(MEMINFO) || die "can't open $MEMINFO: $!";
# flock(MEMINFO, LOCK_EX);
while (<MEMINFO>) {
next if /^(Mem|Swap):/;
s{(\d+) kB}{sprintf("%*dM", (length($1)-1), $1/1024)}ge;
s/^/$$:/;
print unless /total:/;
}
close MEMINFO;
}
sub filter {
flush();
unless ($Filter_Pid = open(STDOUT, "|-")) {
die "cannot fork: $!" unless defined $Filter_Pid;
head($Lines) if $Lines;
my %mem;
while (<STDIN>) {
my ($pid, $field, $size) = split /[:\s]+/;
next unless $size;
push @{ $mem{$pid}{$field} }, $size;
}
foreach my $pid ( sort { $a <=> $b } keys %mem ) {
foreach my $field ( keys %{ $mem{$pid} } ) {
my @vals = @{ $mem{$pid}{$field} };
printf "%-5d %12s " . "%6s " x @vals . "\n",
$pid, $field, @vals;
}
}
exit;
}
flush();
}
sub unfilter {
close(STDOUT);
# waitpid($Filter_Pid,0);
}
sub head {
return if my $pid = open(STDOUT, "|-");
die "cannot fork: $!" unless defined $pid;
my $count = shift;
while (<STDIN>) {
if ($count-- > 0) {
print;
} else {
exit;
}
}
exit;
}
sub flush { $| = 1; } # or duplicate output buffers!!
# following is an example cat of /proc/meminfo
__END__
total: used: free: shared: buffers: cached:
Mem: 130650112 80674816 49975296 49299456 25858048 22708224
Swap: 263192576 0 263192576
MemTotal: 127588 kB
MemFree: 48804 kB
MemShared: 48144 kB
Buffers: 25252 kB
Cached: 22176 kB
SwapTotal: 257024 kB
SwapFree: 257024 kB
--
Tom Christiansen tchrist@jhereg.perl.com
A woman needs a little more weird today than normal. --Andrew Hume
------------------------------
Date: Fri, 06 Feb 1998 18:41:08 -0600
From: ckcheng@tribune.com
Subject: How do copy files based on pattern on original file namnes
Message-Id: <886811716.1860304903@dejanews.com>
I have about 7000 files in a directory and I need to copy them to
different locations based on the pattern on the original file names.
All file name start with 00 and end with 008, for example, 00ABCDEFGH008,
00ABCDEFG-008, 00AB------008.
So, what I need to do is if the file name is 00ABCDEFGH008, I'll copy
it to ABC/ABCDEFGH. More examples,
source files destination files
============ =================
00ABCDEFG-008 ABC/ABCDEFG
00AB------008 ABC/AB
00CCCC----008 ABC/CCCC
00EABLAFAS008 DEF/EABLAFAS
00I-------008 GHI/I
Could anyone tell me how to accomplish this?
Thanks
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
------------------------------
Date: 6 Feb 98 23:22:27 GMT
From: devin@premier1.net (Devin L. Ganger)
Subject: Re: Is Perl 5 year 2000 compliant?
Message-Id: <slrn6dn6pr.1p4.devin@blacktower.premier1.net>
<flashy-thing!> Remember only that on Wed, 04 Feb 1998 21:45:46 -0800,
in comp.lang.perl.misc RandallBart wrote:
> Abigail wrote:
> >
> > David Lee Lambert (lamber45@EGR.msu.edu) wrote on 1618 September 1993 in
>
> I just calculated this: The 1618th day of Sepetember 1993 is today,
> 1998-02-04.
>
> But Abigail, why does your program do that? The original post had
> today's date in a normal format.
You obviously don't read alt.sysadmin.recovery, do you? <grin>
Abigail's program obviously has been optimized towards reporting the brutal
truth.
--
Devin L. Ganger <devin@premier1.net>
Chief Systems Administrator
Premier1 Internet Services
------------------------------
Date: Fri, 06 Feb 1998 18:30:16 -0600
From: Steve Dover <swd@strata-group.Xcom>
Subject: Re: Is Perl 5 year 2000 compliant?
Message-Id: <34DBAB18.F3A9F26@strata-group.Xcom>
Abigail wrote:
> RandallBart (Barticus@worldnet.att.spam.net) wrote on 1619 September 1993
> in <URL: news:6bbk6m$9co@bgtnsc03.worldnet.att.net>:
> ++ Abigail wrote:
> ++ >
> ++ > David Lee Lambert (lamber45@EGR.msu.edu) wrote on 1618 September 1993 in
> ++
> ++ I just calculated this: The 1618th day of Sepetember 1993 is today,
> ++ 1998-02-04.
> ++
> ++ But Abigail, why does your program do that? The original post had
> ++ today's date in a normal format.
>
> My newsreader is error correcting.
>
That could be construed as Use *ouch*
------------------------------
Date: 5 Feb 1998 03:20:49 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: killing a child process after a timeout
Message-Id: <6bbb6h$m2m$1@csnews.cs.colorado.edu>
[expedited carbon copy of this posting sent to cited author]
In comp.lang.perl.misc, "Rajan Troostwyk [8000885]"
<troostwyk_rajan@jpmorgan.com> writes:
:This should rsh to "ahost" do a ls of /tmp/*.old and be killed after 60
:seconds if the child has not exited.
Chip says you can't use signals. Well, I'd love to hear him tell me
why the following approach isn't not just right, but in fact, provably
correct. I'll even take theorectical answers rather than practical ones.
You should be able to adjust it into something that suits your precise
purposes.
--tom
#!/usr/bin/perl -w
#
# pipe_timeout demo: tchrist@perl.com
#
# This code uses *FORBIDDEN SIGNALS* perfectly safely.
#
use strict;
my @lines = pipe_timeout(2, 'who; date; sleep 3; date');
print "Output is:\n----\n", @lines, "\n----\n";
exit ($? != 0);
sub pipe_timeout {
my ($seconds, @args) = @_;
local *ME;
my $child = open(ME, "-|");
die "cannot fork: $!" unless defined $child;
if ($child) {
my @retlines = <ME>;
close ME;
return @retlines;
}
my $grandchild = fork();
die "cannot fork: $!" unless defined $grandchild;
$SIG{CHLD} = sub { waitpid($grandchild, 0); exit $? };
unless ($grandchild) { exec(@args) || die "exec @args failed: $!" }
sleep $seconds;
kill 'TERM', $grandchild;
exit 1;
}
__END__
--
Tom Christiansen tchrist@jhereg.perl.com
There's some side effect based on the fact that SIGCHLD isn't sent by
anyone, but is fabricated by the kernel when a child dies. It's a huge
kludge. But then, it _is_ SysV. --Chip Salzenberg, aka <chs@nando.net>
------------------------------
Date: 7 Feb 1998 00:47:32 GMT
From: ddarras@aol.com (Ddarras)
Subject: MacPerl_not_even_newbie
Message-Id: <19980207004701.TAA19753@ladder03.news.aol.com>
chomp(), chop() ? won't compile. Didn't see anything
in the MacPerl faqs to that effect.
Thanks for your attention.
D.Darras.
------------------------------
Date: 4 Feb 1998 13:45:48 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Method Invocation: non-intuitive behaviour or is it me?
Message-Id: <6b9rec$5ma$1@csnews.cs.colorado.edu>
Keywords: method, invocation, subroutine, declaration, syntax, parsing
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc, pdf@morgan.ucs.mun.ca (Paul David Fardy) writes:
:The Perl code below generates a syntax error that's easily fixed by
:rearranging the function declarations. Why?
Because "indirect object" syntax is fraught with peril.
Always use "OO" syntax and you'll be much happier.
$ob1 = Class->gimma();
$res = $ob1->chortle();
$ob2 = $ob1->instagen();
--tom
PS: Here's something I wrote last week regarding this. There
are other reasons, too, that have come up since then.
RESOLVED: Indirect object syntax has subtle but severe flaws.
I intend to show, using three demonstrations, that because the resolution
of parser ambiguities of method calls versus function calls lead to
confusion and broken programs, use of indirect objects is at
best highly suspect.
+--------------------+
| DEMONSTRATION ONE: |
+--------------------+
Consider the following:
$a = meth $x->{whatnot}
That, except in the case demonstrated below, is going to execute
as the first of these, not the second.
$a = $x->meth()->{whatnot}
$a = $x->{whatnot}->meth()
If that's not enough to scare the bejesus out of you,
then let's continue.
+--------------------+
| DEMONSTRATION TWO: |
+--------------------+
Because the syntax
fn X;
does not always mean
X->fn();
Sometimes it means
fn(X);
When is it one, when is it the other? Do you know how the compiler
guesses this one? It looks to see at compile time, whether there is a
package X in existence. And of course, if X is a variable, you lose.
And the way this is determines depends upon load order!
We call this strange magic at a distance.
Compare this:
package Mine;
sub new {}
$x = new FileHandle; # not a method call: Mine::new('FileHandle');
with this:
package Mine;
use FileHandle;
sub new {}
$x = new FileHandle; # method call: FileHandle->new();
with this:
package Mine;
use FileHandle;
sub new {}
$p = 'FileHandle';
$x = new $p; # not method call: Mine::new($p);
Going back to the first demo, what does this do:
package Mine;
sub methA {}
sub methB {
my $self = shift;
$answer = methA $self->{FIELD};
}
Well, in this case, it is the function:
Mine::MethA($self->{field})
And miraculously, this makes it appear to work!!
But what about this one:
package Mine;
sub methB {
my $self = shift;
$answer = methA $self->{FIELD};
}
sub methA {}
Now it's actually $self->methA()->{FIELD} instead.
All because of ordering! Can you believe that?
Are you afraid yet?
+----------------------+
| DEMONSTRATION THREE: |
+----------------------+
This is going to a bit more complicated, but it's not
uncommon, and its subtlety will make you scream.
I'll include only the important parts.
File Alpha.pm
package Alpha;
sub new { bless {} => shift }
sub clone {
my $self = shift;
my $type = ref $self;
my $copy = new $type;
%$copy = %$self;
return $copy;
}
sub child {
my $self = shift;
my $kid = clone $self;
$kid->{PARENT} = $self;
return $child;
}
File Beta.pm
package Beta;
use Alpha;
@ISA = ('Alpha');
sub clone {
my $self = shift;
my $type = ref $self;
my $copy = new $type;
$copy->{GENCNT}++;
return $copy; # note no full copy
}
File main.pm
package main;
use Beta;
$dad = new Beta;
$babe = child $dad;
That just did the very wrong thing. Why? Because main called
$dad->child, which got Alpha::child($dad), because Beta has no child()
method, but inherits from Alpha who does. Alpha::child, however, then
appears to call a ->clone() method on that $self object. It doesn't.
It tricks you. It calls instead Alpha::clone($self), rather than the
correct Beta::clone($self). Which that the child $babe has a PARENT field
set, which is the Alpha clone behaviour, but not a GENCNT field, which is
the correct Beta child behaviour. This code, apparently perfectly fine,
is wrong for reasons tortuous in explanation. It looks right, but due
to accidents of the parser, ordering, and syntax.
The OO notation, meaning an infix error as in $ABC->meth, will never hose
you. Don't use indirect objects, because I/O notation is fatally flawed.
QED.
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
The hardest thing in the world to understand is the income tax.
--Albert Einstein
------------------------------
Date: Sat, 07 Feb 1998 01:29:06 GMT
From: efflandt@xnet.com (David Efflandt)
Subject: Re: Permission Help!!
Message-Id: <34deafd8.4387258@flood.xnet.com>
aoliva@uspe.com (Alex Oliva) wrote:
>OK... I am at wits end! :)
>
>I am creating an .shtml file via a perl based cgi script.
>The directory the file is being written to has permissions of 777.
>Since I have a server side include, I use a `chmod 755` inside my
>perl script to change the permission of the subdir the .shtml file is
>being accessed from. The problem is I STILL get the
>
>"404 - document not found or INSECURE" error message.
>
>It's obvious that even though I changed my permission to 755, it still
>won't let me run the SSI file (it runs NON SSI html files fine).
>
>Is there something I'm missing here? Also, I can't seem to DELETE the
>subdir via FTP if I have set the permissions from within the perl
>script.
>
>Your help would be GREATLY appreciated... thanks!!
>
>Please respond to aoliva@uspe.com
This should have been posted in comp.infosystems.www.authoring.cgi
since it is not perl related. But web pages (including .shtml) should
typically have 644 permission, scripts should be 755 and files you
write to should either already exist with 666 or to create a new file
the dir must be 777. Possibly you could reduce group permissions
(middle number) once they are working.
You likely cannot change dir permissions on your files from CGI
because the webserver (nobody) cannot do that. However, your CGI
should chmod any files created by CGI to 666 so that 'you' can edit or
remove files belonging to user 'nobody'.
David Efflandt/Elgin, IL USA
efflandt@xnet.com http://www.xnet.com/~efflandt/
------------------------------
Date: 6 Feb 1998 23:27:28 GMT
From: chris@netmonger.net (Christopher Masto)
Subject: Re: quick .signature hack
Message-Id: <6bg690$jvd$2@schenectady.netmonger.net>
In article <Pine.HPP.3.95.980206171845.2062O-100000@homer.louisville.edu>,
Mark Crane <mecran01@homer.louisville.edu> wrote:
> I am trying to figure out how to do the following:
>
> In order to use multiple random sigs on Pine, I am trying to
> cobble a
> script together that will
>
> 1. look at a file of quotes or sigs delimited by multiple
> returns or some pre-chosen character string, like "$$$$"
>
> 2. select a quote at random.
>
> 3. write it to the file ".sig"
>
> That's it. I would have it run every time I went into pine. Is
> this doable in 4 lines or less? (not that it matters--I'm trying
> to goad someone into writing it for me because I am
> lazy/busy/newbie)
Post your code and you have a better chance of getting help with it.
--
Christopher Masto <chris@netmonger.net>
Director of Operations, NetMonger Communications, Inc.
+1-516-221-6664 http://www.netmonger.net/ info@netmonger.net
------------------------------
Date: 7 Feb 1998 01:06:55 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: quick .signature hack
Message-Id: <6bgc3f$9hm$1@marina.cinenet.net>
Mark Crane (mecran01@homer.louisville.edu) wrote:
: I am trying to figure out how to do the following:
:
: In order to use multiple random sigs on Pine, I am trying to
: cobble a script together that will
:
: 1. look at a file of quotes or sigs delimited by multiple
: returns or some pre-chosen character string, like "$$$$"
:
: 2. select a quote at random.
:
: 3. write it to the file ".sig"
:
: That's it. I would have it run every time I went into pine. Is
: this doable in 4 lines or less? (not that it matters--I'm trying
: to goad someone into writing it for me because I am
: lazy/busy/newbie)
Untested, writing this directly into my newsreader's editor, but this is
the general idea:
undef $/;
open QUOTES, "< quotes.txt" or die $!;
@quotes = split /\Q$$$$\E\n/ <QUOTES>;
close QUOTES;
$quote = $quotes[int rand(@quotes)];
open SIG, "> .sig" or die $!;
print SIG $quote;
close SIG;
More than four lines, of course, but a lot of it is file opening and
closing. The key lines are:
* Turning off input record separation $/, so we slurp up the entire
file as one long scalar;
* Splitting that scalar on your chosen delimiter (note that I've
included a terminal \n in that delimiter, to avoid leading \n
in the quotes); and
* Selecting a quote at random by using a random integer from 0 to
quote-count - 1.
Hope this helps!
---------------------------------------------------------------------
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| Member of The HTML Writers Guild: http://www.hwg.org/
"Every man and every woman is a star."
------------------------------
Date: 7 Feb 1998 01:41:16 GMT
From: lynchqvctc@aol.com (Lynchqvctc)
Subject: Reading The FAQ's etc.: a teacher's perspective...
Message-Id: <19980207014100.UAA17499@ladder02.news.aol.com>
I'd like to respond as thoughtfully as I can, to add to the wonderful,
mutual-help process that goes on here. I am relatively new to perl, and am
learning slowly, but getting some neat things done in the process. Each step
takes a real learning curve, and that's what I've come to expect (heck! I'm an
anthropologist, not a computer programmer!). As a teacher, I realize I have
"forgotten more things than many of my students presently know..." Sometimes,
like the chimp that "doesn't know its own strength..." I can easily miss the
point that what I take for granted as "common sense" and "logical places to
look" for information, are things I've come to rely on as a knowledge based
built on years of incrimental learning.
So when I hear folks say..."Didn't you read the manpages?" or "Hey..that's a
CGI question, not a perl question"... when someone posts a request for help, I
am torn between agreeing with the response (the responder must know what he/she
is talking about... they are the "experts") and saying..."yes... but YOU know
that... maybe the questioner isn't even at the point to know it." We're all
learning... some of us are much newer than others. Our time is precious, and
no one should be lazy and expect others to "do their work for them..." At the
same time-- we have to be careful to realize we might have "forgotten more than
the latest questioner ever knew about programming..."
Keep it light... this perl stuff is great, and so are the folks who work/play
so hard to keep it that way...
------------------------------
Date: Fri, 6 Feb 1998 15:10:32 -0800
From: "Kuntal M. Daftary" <daftary@cisco.com>
To: Alexis Huxley <alexis@danae.demon.co.uk>
Subject: Re: Regex From Hell?
Message-Id: <Pine.GSO.3.96.980206150926.21124F-100000@flipper.cisco.com>
On 3 Feb 1998, Alexis Huxley wrote:
> perl -ne 'print if (/^([abc][xyz]){3}$/)'
> perl -ne 'print if (/^(([abc])\1*([xyz])\2*){3}$/)'
try this:
perl -ne 'print if (/^([abc]+[xyz]+){3}$/)'
Kuntal Daftary
1.408.527.9789
daftary@cisco.com
------------------------------
Date: Fri, 06 Feb 1998 22:26:46 GMT
From: spam@fritter.com (team lamer)
Subject: Sending a message to a pager
Message-Id: <34dc89d2.3602980@news2.newscene.com>
I'd like a button on one of my pages (intranet) so that the users can
page relevent people is certain production problems arise.
(yes I'm evil!)
I think I have 2 options here,
1/ create a query-string & send it to a web site offering a paging
service (??)
2/ open up /dev/modem and do all the dialing stuff :(
1/ would be good if its free ;)
2/ would be great if someone can give give me some pointers
( I don't really want to spend 1/2 day pressing buttons on a phone
figuring out how to get perl to find it's way around a touch-tone
answer system)
(We use BT's 'Easy reach alpha' system -yuk)
------------------------------
Date: Sat, 07 Feb 1998 01:51:39 GMT
From: efflandt@xnet.com (David Efflandt)
Subject: Re: Socket Connections
Message-Id: <34e1bcad.7672889@flood.xnet.com>
Beverly Treadwell <beverlyt@datequest.com> wrote:
>Hi,
>I am trying to run the following code and am getting the error message
>'Unsupported socket function "getprotobyname" called at prereg.pl line
>29'. What's wrong? The socket.pm file is being found. Any help would
>be truly appreciated. My code looks like this.
>
>#!/usr/bin/perl
>
>use Socket;
>
>$| = 1;
>
>$port = "4080";
>$ipaddress = "207.165.90.100";
Dots have special meaning in double quoted strings. Either use single
quotes or escape the dots. Examples:
$ipaddress = '207.165.90.100';
$ipaddress = "207\.165\.90\.100";
I do as little as possible in Windows, so I don't know if there are
any other problems, but it may have simply choked on your IP.
>@pieces = split(/\./, $ipaddress);
>$packname = pack("C4", @pieces);
>$session = sockaddr_in($port, $packname);
>$proto = getprotobyname('tcp');
>$method = "GET";
>$newstring = "post_new_user";
>
>socket(S, AF_INET, SOCK_STREAM, $proto) || die "socket: $!";
>connect(S, $session) || die "connect: $!";
>
>select(S); $| = 1; select(STDOUT);
>print S "$method $newstring HTTP/1.0\n\n";
>sleep 1;
>
>close(S);
>
>
>I'm running on WinNT.
>Thanks.
David Efflandt/Elgin, IL USA
efflandt@xnet.com http://www.xnet.com/~efflandt/
------------------------------
Date: Fri, 06 Feb 1998 17:36:51 -0600
From: rlindner@avsgroup.com
To: rlindner@avsgroup.com
Subject: sorting hash by numeric values
Message-Id: <886807661.1673658375@dejanews.com>
Greetings,
I'm trying to output a bunch of keywords and their associated count for a
log analysis program I'm writing. I've got it working just fine with
this:
while (($keyword, $count) = each(%keywords))
{
print "$count\t$keyword\n";
}
However, I'd love it if I could see the results printed in descending
order of $count but I am too new to perl to figure out an easy way to
sort the keywords hash numerically by the values.
Could someone help me out with this?
Thanks in advance,
Bob
P.S. - please cc me when you post to the group.
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
------------------------------
Date: 5 Feb 1998 14:28:05 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Unpack float
Message-Id: <6bci9l$5va$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
bart.mediamind@tornado.be (Bart Lateur) writes:
:BTW Does anybody know what is the fastest way to calculate 2^n in Perl,
:where n is quite big (so bitshifting won't work, as the result won't fit
:into an integer)?
Why are you running bitwise xor on non-integers?
Oh, you misused ^ to mean **. Why do people make this
mistake? Back to FORTRAN class with you.
Since you don't want to lose precision, you'll have to do
this for arbitrarily large exponents:
use Math::BigInt;
$n = Math::BigInt->new(2);
$n **= 2000;
print $n, "\n";
You'll find that 2**2000 is precisely
11481306952742545242328332011776819840223177020886952004776427368257\
66261392370313856659486316506269918445964638987462773447118960863055\
33142593135616665318539129989145312280000688779148240044871428926990\
06348624478161546364638836394731702604046635397090499655816239880894\
46296056233116495361642219703326813441689089844585056023794848079140\
58900934776500429002716706625830522008132236281291761267883317206598\
99539641812702177985840404215985318325154088943390209192055495778358\
96720391600819572166305827553804255837260155283487864194320545089152\
75783882625175435528800822842770817965453762184851149029376
whereas the result of
$a = 2; $n = 2000;
$a *= 2 while --$n > 0;
print $a;
is given as the risibly inaccurate "Inf".
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
Sorry. My testing organization is either too small, or too large, depending
on how you look at it. :-)
--Larry Wall in <1991Apr22.175438.8564@jpl-devvax.jpl.nasa.gov>
------------------------------
Date: Sat, 07 Feb 1998 01:29:07 GMT
From: efflandt@xnet.com (David Efflandt)
Subject: Re: variable -> form ->varibale
Message-Id: <34dfb5f8.5955577@flood.xnet.com>
eedvab@eed.ericsson.se (Vjekoslav Balas) wrote:
>
>Hi,
>Maybe someone could give a pointer how I would do this:
>I have a number of data in a file (A) something like this (with pattern repeating (but no of activities/goal variable):
>Goal1:...
>Comment:...
>Responsible:...
>Status:
>Activity:
>Comment:
>Responsible
>Status:
>I would like to fetch this data and present it on www in a form (eg. as a table) via which the user could change the "changeable data". The form output would then be used to update file (A).
>
>My idea was to use perl to parse the file, then place the data in variables which
>would be included in html code. All is well till here - but not sure how
>to get the data out of the form so that I know which variable it was in. Thanks,Vjeko
You probably want a hash of hashes. See page 270 of the O'Reilly book
"Programming Perl" or search the perl docs for 'hash'. You can put
the main keys in a list (array) if you want to sort them or keep them
in any particular order.
David Efflandt/Elgin, IL USA
efflandt@xnet.com http://www.xnet.com/~efflandt/
------------------------------
Date: 5 Feb 1998 06:21:21 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Year 2000 Compliance: Lawyers, Liars, and Perl
Message-Id: <6bblp1$26c$1@csnews.cs.colorado.edu>
As the clock draws us relentlessly closer toward 2000, the final year
of the second millennium, doom sayers everywhere are prophesying
unprecedented computer failure in every conceivable sector. Known
popularly as the "Year 2000 Problem", or the "Millennium Bug", this
situation is quite easy to explain. Programs that interpret two-digit
dates in the form "XX" as "19XX" behave unpredictably starting in the
year 2000 and beyond into the next millennium. If your birthday is
"2/2/05", are you 106 years old in 2006, or just one year old?
Cost estimates of fixing this bug range well into the billions of dollars,
with the likely threat of at least that much money again incurred in
protracted legal fees due to real and alleged damages. Because of these
devastating cost projections, corporations and government are mounting
pressure to secure legally binding statements that all software they
use is warranted to be year 2000 compliant.
As you might well guess, this pressure often stems from lawyer-wary
insurance companies, who quite reasonably fear death-by-litigation even
more than they might the effects of any actual costs of actual, incurred
damages. To defend themselves against legal perils, organizations all
over the world are rushing to secure, in all possible haste, affidavits
to the effect that such-and-such software is year 2000 compliant. They
intend to brandish these as some sort of legal shield when the inevitable
chaos strikes, righteously proclaiming themselves free of Y2K taint and
redirecting lawsuits toward the signers of the aforementioned documents.
Remember this: if someone asks you to warrant that your software is free
of year 2000 bugs, they're really just looking for an excuse to sue *you*
if they misuse your software, even if it should happen to be their own
fault. Probably they've already forgotten the terms of their software
licence, one which probably read something rather close to the following:
IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY
DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND
NON-INFRINGEMENT. THIS SOFTWARE IS PROVIDED ON AN "AS IS" BASIS,
AND THE AUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE
MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
Did you ever stop to wonder just how long an automobile manufacturer
might survive government with such an anti-warranty? Why should software
manufacturers be any different? Somehow, though, they do appear to be.
Whether such things survive the courts in the litigational feeding frenzy
certain to ensue in a couple of year is something that remains to be seen.
Don't count on anything.
The anxiety about the Y2K situation is reaching an increasingly feverish
pitch in most large organizations. Every few days, you read something
else in the popular media forecasting certain havoc. Nearly all these
reports are peppered with vague prevarications or technical confusion.
That's not to say that there isn't a real issue here, and that we can go
pretending there's nothing to bother ourselves with. There certainly is.
But what that problems stems from, and what can be done about it, is
something usually misunderstood at best. Three commonly repeated lies
exacerbate the situation.
The first lie routinely recounted is that the Y2K problem historically
derived from expensive computers of yesteryear whose memory was so
dear that programmers maintained dates in a two-digit format to keep
costs under control.
This assertion is demonstrably false. Think about it. A two-digit
number requires how much storage? Two bytes, that is, sixteen bits?
No, much less: numeric data are seldom stored in text format, since a more
compact representation is readily available. A two-digit year would be a
number ranging between 00 and 99. That can be represented in just 7 bits.
What about using full years, like 1985 or 2010? Those numbers could be
represented in just 11 bits. So did those veteran programmers of old
truly gleefully rack up dramatic cost savings at the rate of 4 entire
bits per date? Surely this tremendously precious hardware could have
spared 4 bits! And even if not, one could have employed an offset from a
reasonable base instead. If instead of using just the last two digits,
years in dates could have been represented not as absolute values but
rather as the number of years since 1900. If so, this too would still
fit in those aforementioned 7 bits, at least for a while. Add another
bit, and we're clear until 2256. End of problem. Saving memory
was not why it was done.
The second lie is that this phenomenon is somehow brand new, that in
the year 2000, myriad systems will suddenly fail, and that this kind of
thing has never occurred before. Think about the ancient pensioner born
in 1895. A program that reads their birthday as "95" will not pay them
their months checks, since in 1998, they appear to be only three years
old. The year 2000 has not occurred in this equation. The so-called
"year-2000" problem is in no fashion new, nor is it limited to that year.
It will simply be more evident then.
The third, and by far the gravest lie about Y2K matters, is that your
company can, through the acquisition of affidavits of compliance, protect
itself against harm, whether real or litigated. It can't. This faith
in legal documents is hollow and in fact dangerous. The wisest course
of action is for you to immediately disabuse yourself of this deceit.
The insidious, underlying root cause of this entire problem is neither
the hardware nor the software. No, that would be too easy; that we
know how to fix. Just apply a few hundred billion dollars, and voil`,
it's all taken care of.
Unfortunately, that's not it. The real problem is the wetware. That's
right: the defect lies not in our computers, nor in their programming,
but rather in us.
Most of the time that people think about dates, they use only the
final two digits of the year. They write it on checks. They write in
family Bibles. You hear someone casually say, "I remember back in '65,"
or "the Generation of '98 had their collective consciousness shaken to
the root by their astonishing loss to the Americans in the Caribbean,"
and you're just supposed to know what they mean. Just which 65 is that?
Assuming a living speaker, it provably has to be 1965. But just *which*
98 was that? Why, it was not the current year, but rather way back
in 1898, when Spain lost the remainder of their decrepit empire to
those upstart New Worlders and subsequently succumbed to a national
soul-searching that permeated throughout their literature of that age.
In both cases, you resolve the ambiguity by inferring the full year from
the context, of course. But if you don't have that context, then you
just have to guess. And remember: computers make notoriously bad guessers.
The most horrifying aspect of all this is that even with a perfectly
accurate and working computer program, one that is obviously "Y2K
compliant", you are still in big trouble. Take for example, the famous
Unix `cal' program. Let's check out the current month.
$ cal 2 98
February 98
Su Mo Tu We Th Fr Sa
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28
Hold on. What was that? Isn't Valentine's Day is supposed to fall on
Saturday, not Wednesday, this year? Oops; wrong millennium! What you
really meant to type was:
$ cal 2 1998
February 1998
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
As you see, it doesn't matter whether the programs are compliant,
because the humans using them are not! Fixing the programs is certainly
a necessary step, but far, far from sufficient. You can certify every
single program in existence, and it still will not be enough for safety.
Until such time as the teeming billions of people in this world -- or even
just the many millions using computers -- are all similarly certified,
and warranted not to forget, there can be no safety. And that's not
going to happen.
To seek legally binding statements that a particular program cannot
be intentionally or unintentionally misused is nothing but a witch
hunt doomed to fail in its ultimate goal of protecting you and yours.
You cannot help that there will always be cluefully-challenged users
and programmers out there, or even persons of clue who occasionally
have a memory lapse. You cannot find them, you cannot blame the tool
or language, and you cannot protect yourself from them. Every time a
human being thinks about a year in terms of just two digits, the problem
reasserts itself. And no one has yet figured out how to fix the wetware.
Now, what about Perl? Is Perl "Year 2000 Compliant"? The answer is
that Perl is every bit as Y2K compliant as is your pencil; no more, and
no less. Does that comfort you? It shouldn't. Just as you can commit
Y2K transgressions with your pencil, so too you can do so with Perl --
or with any other tool, for that matter. You don't really even have to
go very far out of your way to do so; witness the demonstration of the
perfectly compliant cal program provided above.
The date and time functions supplied with Perl are the gmtime and
localtime functions, which are derived from their namesakes from the C
programming language. These supply adequate information to determine
the year well beyond 2000. 2038 is when trouble strikes, but only for
those of us still stuck on 32-bit machines, a somewhat unlikely albeit
not entirely unthinkable situation.
The year returned by these functions (when used in list context) is,
contrary to popular misconception, *not* by definition a two-digit year.
Rather, it merely happens to be such right now. What it actually is,
is the current year minus one thousand nine hundred. For years between
1900 and 1999 this happens to be a 2-digit decimal number, but that's
not going to last long. To avoid the year 2000 problem, simply do not
treat the year as a 2-digit number. Easy to say, and easy to break.
Imagine that
use Time::localtime;
$then = time() + ( 60 * 60 * 24 * 365 * 5 ); # 5 years from now
$that_year = localtime($then)) -> year;
printf("It shall be 19%d\n", $that_year); # WRONG! 19103
printf("It shall be %d\n", 1900 + $that_year); # right: 2003
As you see, in the wrong hands, even a nominally year 2000 compliant tool
such as perl or cal can be misused by the underclued or simply the forgetful.
+------------------------------------------------+
| Executive summary from TPI, The Perl Institute |
+------------------------------------------------+
Perl has no warranty, and TPI does not support Perl. Furthermore,
Perl is a language, and languages can be misused in many ways.
But that's the responsibility of the programmer and the user, not
of the many creators of Perl. Nevertheless, as spokes-organization
for the Perl freeware movement, we feel compelled to point out that
Perl is every bit as Y2K compliant as the C language upon which its
interfaces are based, and in which the Perl compiler and interpreter
are themselves written. That is, the interfaces giving access to
date information in Perl, when used as designed, are Y2K compliant
in every sense of that word.
If that makes your lawyers or managers happy, well, good for them.
You still have a lot to worry about.
--
Tom Christiansen tchrist@jhereg.perl.com
"Espousing the eponymous /cgi-bin/perl.exe?FMH.pl execution model is like
reading a suicide note -- three days too late."
--Tom Christiansen <tchrist@mox.perl.com>
------------------------------
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 1825
**************************************
