[31598] in Perl-Users-Digest
Perl-Users Digest, Issue: 2857 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 8 14:09:28 2010
Date: Mon, 8 Mar 2010 11:09:06 -0800 (PST)
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, 8 Mar 2010 Volume: 11 Number: 2857
Today's topics:
[OT] Re: Is there a "poor man's" perldoc? <m@rtij.nl.invlalid>
ANNOUNCE: Major Feature Release - NHI1-0.7, PLMK-1.6 an <aotto1968@users.sourceforge.net>
Re: Core dump with "in memory" file <ben@morrow.me.uk>
Re: Detecting Bourne (or csh) shell from Perl <ben@morrow.me.uk>
Re: FAQ 8.21 Where do I get the include files to do ioc <jrdavid@magma.ca.INVALID>
Re: HTML standard (was Apache2::Request doesn't work as <kwan.jingx@gmail.com>
Re: Prevent script from adding an extra line at the end <tzz@lifelogs.com>
Re: Why does assigning @_ cause sub's parameter to be c <sreservoir@gmail.com>
Re: Why does assigning @_ cause sub's parameter to be c <sreservoir@gmail.com>
Re: Why does assigning @_ cause sub's parameter to be c <jerry@ieee.org>
Re: Why does assigning @_ cause sub's parameter to be c <uri@StemSystems.com>
Re: Why does assigning @_ cause sub's parameter to be c <tadmc@seesig.invalid>
Win32::AdminMisc Perl 5.10 x64: ActiveState PPD require <dilbert1999@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 8 Mar 2010 07:56:14 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: [OT] Re: Is there a "poor man's" perldoc?
Message-Id: <elje67-cj6.ln1@news.rtij.nl>
On Sun, 07 Mar 2010 12:24:31 +0100, Mart van de Wege wrote:
> You know, sometimes security is best served by giving an admin the tools
> to reduce their response time to an incident. That gives them the time
> to ascertain whether the incident is merely an innocent crash or an
> actual exploit attempt.
Don't get me started, I work as a security officer too. Most notable tool
of software not installed for security reasons is 'lsof'. Which means I
cannot investigate certain kinds of incidents in a competent manner.
That and a monitoring team that create tickets because I executed 'man'
as root (yes installed on that machine). That email has decorated the
wall for quite some time.
M4
------------------------------
Date: Mon, 08 Mar 2010 14:43:46 +0100
From: Andreas Otto <aotto1968@users.sourceforge.net>
Subject: ANNOUNCE: Major Feature Release - NHI1-0.7, PLMK-1.6 and libmsgque-4.5
Message-Id: <hn2uui$qb5$03$2@news.t-online.com>
Dear User,
ANNOUNCE: Major Feature Release
====================================
libmsgque: Application-Server-Toolkit for
C, C++, JAVA, C#, TCL, PERL, PYTHON, VB.NET
PLMK: Programming-Language-Microkernel
NHI1: Non-Human-Intelligence #1
SUMMARY
=======
This is a 'major-feature-release' to add 'longtime-transaction' support.
A 'longtime-transaction' is a transaction with a possible infinite time
period between the start and the end. A 'longtime-transaction' is always
a 'persistent-transaction' too. The 'persistent' support is available as
an in-memory solution on the 'application-server' or in an additional
'bidirectional-filter' available for the next release.
A typical scenario for a 'longtime-transaction' is:
* A user with a client connect to the server and start a
'longtime-transaction' job. After a while the user shutdown the client
and leave the office. At the next morning the user start the client
again and the results are send from the server to the client.
* On a space mission the time-overhead between transaction start and end
is large. It is usually not possible to keep the
client-server-connection open all the time.
* On a military action-system the enemy try to interrupted the
client-server-connection to disable data communication.
To use a 'longtime-transaction' the results are send to a
'client-service' registered with MqServiceCreate. This service and
addtional data (I call this data 'local-context-data') have to be added
to the 'longterm-transaction' package to be available in the result. On the
'link-target' the 'local-context-data' is initial stripped from the
'data-package' and is later added to the results again.
The 'local-context-data' is added to the 'data-package' with
MqSendT_START and MqSendT_END.
The 'local-context-data' is read from the 'data-package' with
MqReadT_START and MqReadT_END.
LINKS
=====
libmsgque:
> http://nhi1.berlios.de/theLink/index.htm
NHI1:
> http://nhi1.berlios.de/
DOWNLOAD:
> http://developer.berlios.de/projects/nhi1/
mfg
Andreas Otto (aotto1968)
------------------------------
Date: Mon, 8 Mar 2010 00:02:21 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Core dump with "in memory" file
Message-Id: <ddrd67-00g2.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2010-03-05 01:47, Ben Morrow <ben@morrow.me.uk> wrote:
> > It's a bug in perl, but it appears to have been fixed in blead. The fix
> > will be in 5.10.0, and probably in 5.10.2 if there ever is one
> 5.12.0?
Yes. Thanks for the correction.
Ben
------------------------------
Date: Mon, 8 Mar 2010 10:36:56 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Detecting Bourne (or csh) shell from Perl
Message-Id: <8j0f67-htj2.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2010-03-04, Ben Morrow <ben@morrow.me.uk> wrote:
> > AS and Strawberry (all the various flavours) apply no more than minor
> > patches to the core. (This wasn't true once, as I'm sure you remember,
> > but ActiveState haven't had their own port for a long time.) Cygwin (and
> > Interix and UWin) don't set $^O = "Win32"; as far as Perl is concerned,
> > they're mostly a different OS from Win32.
>
> I strongly oppose this misuse of the word "OS"; an OS is an OS - a
> port is a port.
>
> Otherwise - a lot of thanks for bringing my attention to Interix and
> UWin (this is VERY CLOSE to the kind of info I was asking for). In
> other message of this thread, you advocate looking in perlport; but I
> find very scarce info about these ports there...
>
> The end result is that I do not know what shell they do use... I'm
> afraid one would need to run something like
>
> system qq(echo "1" | $^X -wne "exit 1 unless /\\x22/")
> and print "no quote passed through"
>
> each time C::Scan is loaded...
Cygwin, Interix and UWin all use some kind of sh-ish shell.
> >> I would guess that your understanding of non-Unix architechture is
> >> kinda blurred. There are probably tens of different C libraries, none
> >> of them "standard"...
>
> > I'm aware of that. However, TTBOMK there aren't any C libraries for
> > Win32 which don't use command.com/cmd.exe for system(3).
>
> Are you sure about cygwin one?
I don't consider Cygwin's libc to be a libc 'for Win32'. If you do,
then: TTBOMK there aren't any C libraries for native Win32 (without any
sort of Unix emulation layer) which don't use cmd.exe for system(3).
Ben
------------------------------
Date: Mon, 08 Mar 2010 12:37:44 +0000
From: Jean-Rene David <jrdavid@magma.ca.INVALID>
Subject: Re: FAQ 8.21 Where do I get the include files to do ioctl() or syscall()?
Message-Id: <a44de$4b94ef98$adce9bd8$9714@PRIMUS.CA>
* PerlFAQ Server [2010.03.08 05:00]:
> 8.21: Where do I get the include files to do ioctl() or syscall()?
[...]
> doesn't work perfectly, but it usually gets most of the job done. Simple
> files like errno.h, syscall.h, and socket.h were fine, but the hard ones
Shouldn't this be:
"Simple files like errno.h, syscan.h, and socket.h *work*
fine, ..."?
--
JR
------------------------------
Date: Sun, 7 Mar 2010 18:43:21 -0800 (PST)
From: kwan <kwan.jingx@gmail.com>
Subject: Re: HTML standard (was Apache2::Request doesn't work as expected)
Message-Id: <5e6f3041-4b52-45d2-ab81-2e848a705df6@g11g2000yqe.googlegroups.com>
On Mar 6, 9:58=A0pm, s...@netherlands.com wrote:
> On Sat, 6 Mar 2010 19:31:17 -0800 (PST), kwan <kwan.ji...@gmail.com> wrot=
e:
> >On Mar 6, 9:23 pm, s...@netherlands.com wrote:
> >> On Sat, 06 Mar 2010 19:46:05 -0600, Tad McClellan <ta...@seesig.invali=
d> wrote:
> >> >smallpond <smallp...@juno.com> wrote:
>
> >> >> Single quotes are not used in html.
>
> >> >Single quotes are most certainly allowed in HTML.
>
> >> >http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2
>
> >> ^^
> >> So xml is a fix on html and '' is grandfathered in.
>
> >> > By default, SGML requires that all attribute values be delimited
> >> > using either double quotation marks (ASCII decimal 34) or single
> >> > quotation marks (ASCII decimal 39).
>
> >> And now, the king god SGML speaks it, deems it, it!
> >> It is now in stone, and let no man take us'eth er a under.
> >> So beith, as it was and will be, <pause>, or forever hold your peace..=
<pause>,
> >> Amen!
>
> >> So sayeth we all !! Aye...
>
> >> -sln
>
> >Probably, it is how Apache2::Request handle the parameters. I am not
> >sure it is a bug, but hopefully I can find the solution.
> >I don't really want to mix with Apache2::Request with CGI script.
> >CGI::param is working fine with the problems that I have described,
> >but when Apache2::Request::param just doesn't understand the request
> >at all.
>
> I won't say I could handle or fix your problem. I would say I have been
> paid a lot of money to fix problems a lot of experts can't.
>
> -sln
I got the answer. It was the problem with the form.
<form method=3D"POST" action=3D"/app3">
</form>
I need action in order for the Apache2::Request::param to be able to
query the parameter.
------------------------------
Date: Mon, 08 Mar 2010 08:22:48 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Prevent script from adding an extra line at the end of file
Message-Id: <87hboqhozr.fsf@lifelogs.com>
On Thu, 04 Mar 2010 14:52:54 -0600 Tad McClellan <tadmc@seesig.invalid> wrote:
TM> Don Pich <dpich@polartel.com> wrote:
>> Desired output:
>>
>> convert the IP into a quad hex form.
TM> print "convert the IP into a quad hex form.\n";
So what do we call these answers? "quinine pills" (pun on "quine")?
I've seen a few and they're definitely their own brand of humor, so we
may as well label it.
Ted
------------------------------
Date: Sun, 07 Mar 2010 10:36:12 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Why does assigning @_ cause sub's parameter to be copied?
Message-Id: <hn0h5e$hfq$1@speranza.aioe.org>
On 3/7/2010 1:35 AM, Jerry Krinock wrote:
> After several hours of head-scratching, I finally found out why I
> changes I made to an array passed by reference to a subroutine are not
> seen outside the subroutine, thanks to Steve Litt's Perls of Wisdom
> [1]:
>
> "Any change the subroutine performs to @_ or any of its members like
> $_[0], $_[1], etc, are changes to the original argument. HOWEVER,
> assigning @_ or its elements to other variables makes a separate copy.
> Changes to the separate copy are unknown outside of the subroutine."
never do this. not unless you have a really good idea of why you're
doing it. you obviously don't.
> Maybe if someone could explain the reason why Perl would do this, make
> a copy upon *assignment*, it would be easier for me to remember. Is
> this a "feature" of the language, or some unfortunate implementation
> reality? The reason why I discovered this is that since I'm not a
> full-time Perl guy, I try and write readable code, defining lots of
> variables. However, as you can see from my code below, my nice and
> pedantic subroutine pushBad() doesn't work because it makes a local
> assignment, but the hard-to-read pushGood() works.
try this:
push(my @b = @{my $a = [qw/this list/]}, qw/that list/);
what would you expect $a to contain?
it seems you expect [qw/this list that list/].
I prefer, in perls above 5.6, to use subroutine prototypes:
sub pushScalar(\@$) {
my $ref = shift;
push @$ref, shift;
}
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Sun, 07 Mar 2010 10:36:42 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Why does assigning @_ cause sub's parameter to be copied?
Message-Id: <hn0h6d$hfq$2@speranza.aioe.org>
On 3/7/2010 10:36 AM, sreservoir wrote:
> On 3/7/2010 1:35 AM, Jerry Krinock wrote:
>> After several hours of head-scratching, I finally found out why I
>> changes I made to an array passed by reference to a subroutine are not
>> seen outside the subroutine, thanks to Steve Litt's Perls of Wisdom
>> [1]:
>>
>> "Any change the subroutine performs to @_ or any of its members like
>> $_[0], $_[1], etc, are changes to the original argument. HOWEVER,
>> assigning @_ or its elements to other variables makes a separate copy.
>> Changes to the separate copy are unknown outside of the subroutine."
>
> never do this. not unless you have a really good idea of why you're
> doing it. you obviously don't.
>
>> Maybe if someone could explain the reason why Perl would do this, make
>> a copy upon *assignment*, it would be easier for me to remember. Is
>> this a "feature" of the language, or some unfortunate implementation
>> reality? The reason why I discovered this is that since I'm not a
>> full-time Perl guy, I try and write readable code, defining lots of
>> variables. However, as you can see from my code below, my nice and
>> pedantic subroutine pushBad() doesn't work because it makes a local
>> assignment, but the hard-to-read pushGood() works.
>
> try this:
>
> push(my @b = @{my $a = [qw/this list/]}, qw/that list/);
>
> what would you expect $a to contain?
>
> it seems you expect [qw/this list that list/].
>
> I prefer, in perls above 5.6, to use subroutine prototypes:
>
> sub pushScalar(\@$) {
> my $ref = shift;
> push @$ref, shift;
> }
called pushScalar(@array, scalar)
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Sun, 7 Mar 2010 21:26:43 -0800 (PST)
From: Jerry Krinock <jerry@ieee.org>
Subject: Re: Why does assigning @_ cause sub's parameter to be copied?
Message-Id: <0fd25b80-4dc7-48f9-b768-d1c6d70e4464@s36g2000prh.googlegroups.com>
Thanks for all the replies. Upon further testing, I see that
dereferencing works the same way in "C" language functions.
Retrieving $arrayRef = shift, and then referring to @$arrayRef, to
avoid making a copy, works as expected, is efficient, and is readable.
Jerry
------------------------------
Date: Mon, 08 Mar 2010 01:07:47 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Why does assigning @_ cause sub's parameter to be copied?
Message-Id: <87eijvqrbg.fsf@quad.sysarch.com>
>>>>> "JK" == Jerry Krinock <jerry@ieee.org> writes:
JK> Thanks for all the replies. Upon further testing, I see that
JK> dereferencing works the same way in "C" language functions.
no it doesn't. there are many difference between perl's references and
c's pointers. if you don't learn the differences you will not appreciate
the power of references. refs can't be modified (c's pointers can be) so
they are always safe - no core dumps are possible via normal ref
use. refs can only be dereferenced into their original type. c's
pointers can be coerced to anything and abused. user code can't create a
ref to whatever. c's pointers can be assigned to point to anywhere.
JK> Retrieving $arrayRef = shift, and then referring to @$arrayRef, to
JK> avoid making a copy, works as expected, is efficient, and is readable.
and it took you this long to learn this? as i said, you picked the wrong
source to learn perl (hell, pretty much no web source is good for
learning perl). the perl doc perlreftut would have taught you this and
more in less time and with less pain. then you could move on to perlre
(the reference reference doc), perllol and perldsc. no web needed as
these all come with your perl installation.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 08 Mar 2010 06:51:14 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Why does assigning @_ cause sub's parameter to be copied?
Message-Id: <slrnhp9ser.3ee.tadmc@tadbox.sbcglobal.net>
Uri Guttman <uri@StemSystems.com> wrote:
> then you could move on to perlre
> (the reference reference doc),
s/perlre/perlref/
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Mon, 8 Mar 2010 10:12:19 -0800 (PST)
From: Dilbert <dilbert1999@gmail.com>
Subject: Win32::AdminMisc Perl 5.10 x64: ActiveState PPD required
Message-Id: <ba1c5020-3ed1-4f2d-a197-116b7192f90d@j27g2000yqn.googlegroups.com>
I am trying to install Win32::AdminMisc using a PPD repository for
ActiveState Perl v 5.10 with 64 bits.
I googled "Win32::AdminMisc 5.10 64 bits ppd" and I came across
http://www.ramtek.us/downloads.html which had a PPD repository for
Perl 5.10 at http://www.ramtek.us/cgi-bin/ppmsend.cgi?File=Win32-AdminMisc
So I typed:
C:\>ppm install http://www.ramtek.us/cgi-bin/ppmsend.cgi?File=Win32-AdminMisc
but this failed...
ppm install failed: The PPD does not provide code to install for this
platform
This is my Perl platform...
C:\>perl -v
This is perl, v5.10.1 built for MSWin32-x64-multi-thread
(with 2 registered patches, see perl -V for more detail)
Copyright 1987-2009, Larry Wall
Binary build 1006 [291086] provided by ActiveState http://www.ActiveState.com
Built Aug 24 2009 13:45:20
... and this is the content of http://www.ramtek.us/cgi-bin/ppmsend.cgi?File=Win32-AdminMisc
<SOFTPKG NAME="Win32-AdminMisc" VERSION="0,2003,07,14">
<TITLE>Win32::AdminMisc</TITLE>
<ABSTRACT>The Win32::AdminMisc extension for Win32 X86</ABSTRACT>
<AUTHOR>Roth Consulting (http://www.roth.net/)</AUTHOR>
<IMPLEMENTATION>
<OS NAME="MSWin32" />
<ARCHITECTURE NAME="MSWin32-x86-object" />
<CODEBASE HREF="http://ramtek.us/perl/packages/x86/Win32/
AdminMisc_5005_AS.tar.gz" />
</IMPLEMENTATION>
<IMPLEMENTATION>
<OS NAME="MSWin32" />
<ARCHITECTURE NAME="MSWin32-x86" />
<CODEBASE HREF="http://ramtek.us/perl/packages/x86/Win32/
AdminMisc_5005.tar.gz" />
</IMPLEMENTATION>
<IMPLEMENTATION>
<OS NAME="MSWin32" />
<ARCHITECTURE NAME="MSWin32-x86-multi-thread" />
<CODEBASE HREF="http://ramtek.us/perl/packages/x86/Win32/
AdminMisc_5006.tar.gz" />
</IMPLEMENTATION>
<IMPLEMENTATION>
<OS NAME="MSWin32" />
<ARCHITECTURE NAME="MSWin32-x86-multi-thread-5.8" />
<CODEBASE HREF="http://ramtek.us/perl/packages/x86/
Win32/AdminMisc_5008.tar.gz" />
</IMPLEMENTATION>
<IMPLEMENTATION>
<OS NAME="MSWin32" />
<ARCHITECTURE NAME="MSWin32-x86-multi-thread-5.10" />
<CODEBASE HREF="http://ramtek.us/perl/packages/x86/
Win32/AdminMisc_5010.tar.gz" />
</IMPLEMENTATION>
</SOFTPKG>
I could find a perl 5.10 repository in the above PPD <ARCHITECTURE
NAME="MSWin32-x86-multi-thread-5.10" />, but that would be 32 bits.
Does anybody know of a PPD repository that offers Win32::AdminMisc for
Perl 5.10 under 64 bits ?
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 2857
***************************************
