[25197] in Perl-Users-Digest
Perl-Users Digest, Issue: 7443 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Nov 24 11:05:57 2004
Date: Wed, 24 Nov 2004 08:05:10 -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 Wed, 24 Nov 2004 Volume: 10 Number: 7443
Today's topics:
Re: Any RT users (Sara)
Re: Any RT users (Sara)
Re: Any RT users <richard@zync.co.uk>
Re: Any RT users <aharrison@gmail.com>
Re: Can't stat e:: Unknown file or directory - why? <mark-news@PLEASE.NOSPAM.gags-r-us.org>
Re: Can't stat e:: Unknown file or directory - why? <mark-news@PLEASE.NOSPAM.gags-r-us.org>
Re: cookie failes (Anno Siegel)
Re: cookie failes <cwilbur@mithril.chromatico.net>
Re: cookie failes <nospam@nospam.com>
Re: CTRL-Z on Win32 <mritty@gmail.com>
Re: CTRL-Z on Win32 <nospam@nospam.com>
Re: CTRL-Z on Win32 <do-not-use@invalid.net>
Re: CTRL-Z on Win32 <nospam@nospam.com>
Re: CTRL-Z on Win32 <mritty@gmail.com>
FAQ 6.1: How can I hope to use regular expressions with <comdog@panix.com>
Re: Fork, exec - setsid? <vek@station02.ohout.pharmapartners.nl>
Re: Fork, exec - setsid? <rob@nova.hbx.us>
Re: Fork, exec - setsid? <rob@nova.hbx.us>
GET YOUR FREE TRIP (GET YOUR FREE TRIP)
Re: How to "unread" STDIN? (Peter Scott)
Installing modules on Solaris in non-default location boekhold@gmail.com
Re: Installing modules on Solaris in non-default locati <boekhold@gmail.com>
Re: Managing PERL5LIB with multiple perl installation <do-not-use@invalid.net>
Re: parent of an orphaned process (Anno Siegel)
Re: parent of an orphaned process <vek@station02.ohout.pharmapartners.nl>
Re: redirect question <amead@comcast.net>
Re: redirect question <nospam@nospam.com>
Re: redirect question <nospam@nospam.com>
ssi querystring <tryandspamme@youcant.com>
Re: sysread(socket..) problem on perl 5.8.0 linux (Anno Siegel)
Re: Using embedded PERL with commercial applications? (Donal K. Fellows)
Re: Using embedded PERL with commercial applications? <tassilo.von.parseval@rwth-aachen.de>
Re: Using embedded PERL with commercial applications? (Cameron Laird)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 24 Nov 2004 03:47:12 -0800
From: sa_ravenone@yahoo.com (Sara)
Subject: Re: Any RT users
Message-Id: <8e3b2dfa.0411240347.1bb25727@posting.google.com>
> On Tue, 23 Nov 2004 21:11:06 -0800, Sara wrote:
>
> > I am looking for some help/pointers to get started with RT customization
> > (objects and HTML Mason). Again, if this is off-topic please let me
> > know. If not, I would like to clarify some specific doubts relevant to
> > Perl.
>
Thanks for all the replies.
I am becoming more familiar with object-oriented Perl with the help of
Camel, 3rd Ed. Now looking at a big project like RT, everything is
modular and is in blocks - because of HTML Mason. I am finding it
difficult to get the whole picture - the objects involved in the
process, their attributes and methods and inheritance.
I am comfortable in dealing with simple objects, but this one is too
difficult for me to grasp.
If confronted with such a problem, what would be the best way to solve
it (understand it).
Thanks,
Sara
------------------------------
Date: 24 Nov 2004 03:49:35 -0800
From: sa_ravenone@yahoo.com (Sara)
Subject: Re: Any RT users
Message-Id: <8e3b2dfa.0411240349.4e4dfd27@posting.google.com>
> On Tue, 23 Nov 2004 21:11:06 -0800, Sara wrote:
>
> > I am looking for some help/pointers to get started with RT customization
> > (objects and HTML Mason). Again, if this is off-topic please let me
> > know. If not, I would like to clarify some specific doubts relevant to
> > Perl.
>
Thanks for all the replies.
I am becoming more familiar with object-oriented Perl with the help of
Camel, 3rd Ed. Now looking at a big project like RT, everything is
modular and is in blocks - because of HTML Mason. I am finding it
difficult to get the whole picture - the objects involved in the
process, their attributes and methods and inheritance.
I am comfortable in dealing with simple objects, but this one is too
difficult for me to grasp.
If confronted with such a problem, what would be the best way to solve
it (understand it).
Thanks,
Sara
P.S.: Sorry if this has been posted twice.
------------------------------
Date: Wed, 24 Nov 2004 12:24:19 GMT
From: Richard Gration <richard@zync.co.uk>
Subject: Re: Any RT users
Message-Id: <pan.2004.11.24.12.23.47.363755@zync.co.uk>
On Tue, 23 Nov 2004 21:11:06 -0800, Sara wrote:
> Hi all,
> Please correct me if this is an off-topic question.
> I know that there are separate forums for Request Tracker, but thought it
> would be good if I can get suggestions from our clpm community. I am
> looking for some help/pointers to get started with RT customization
> (objects and HTML Mason). Again, if this is off-topic please let me know.
> If not, I would like to clarify some specific doubts relevant to Perl.
> Thanks,
> Sara
Hi,
I'd just like to mention rt-users@lists.bestpractical.com. This is a
mailing list for rt users <slaps forehead in amazement> ;-). It's quite
high traffic, and is read by Jesse (or was last time I was subscribed to
it, about 6 months ago). The archives are also available at several
places, you can google for them. I'm not sure it's the best place to ask
about the overall structure of RT, you'll might be told to RTFM, but
you'll get great help with specific questions. You'll learn a lot just by
lurking there.
HTH
Rich
------------------------------
Date: Wed, 24 Nov 2004 09:19:55 -0500
From: Andy Harrison <aharrison@gmail.com>
Subject: Re: Any RT users
Message-Id: <20041124091955.3ff183b4@andy>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Wed, 24 Nov 2004 00:19:35 -0500, Sherm Pendley wrote
Subject: "Re: Any RT users"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Sara wrote:
>
> > I am looking for some help/pointers to get started with RT
> > customization (objects and HTML Mason).
Aside from the aforementioned mailing lists, don't forget the wiki,
http://wiki.bestpractical.com
> Naturally, there's an O'Reilly book:
>
> "Learning Perl Objects, References, and Modules"
> <http://www.oreilly.com/catalog/lrnperlorm/index.html>
I second this. Great book. I read it from cover to cover and
it helped me grasp some stuff that I just couldn't wrap my feeble
brain around...
> "Embedding Perl in HTML with Mason"
> <http://www.oreilly.com/catalog/perlhtmlmason/index.html>
Also, this is available for free (legally, too), just google a
bit for it, easy to find.
--
Andy
------------------------------
Date: Wed, 24 Nov 2004 11:13:26 GMT
From: Abe <mark-news@PLEASE.NOSPAM.gags-r-us.org>
Subject: Re: Can't stat e:: Unknown file or directory - why?
Message-Id: <k8r8q09se208td5c89aggdufpdvmgjb30g@4ax.com>
On Tue, 23 Nov 2004 20:18:02 -0600, Tad McClellan
<tadmc@augustmail.com> wrote:
>Have you read the docs regarding the strange problem yet?
Yes I've googled the shit out of this and have found nothing useful.
>I can't find any message like that in my version of Perl, only
>one that says 'Can't stat script "%s"'.
>
>Is what you've shown the exact text of the message?
Yes.
>Put
>
> use diagnostics;
>
>at the top of your program and run it again (or just look up the
>message yourself in perldiag.pod).
Thanks. I'll give it a shot.
** Due to SPAM I no longer receive email responses to
** newsgroup postings, so don't bother.
------------------------------
Date: Wed, 24 Nov 2004 11:15:20 GMT
From: Abe <mark-news@PLEASE.NOSPAM.gags-r-us.org>
Subject: Re: Can't stat e:: Unknown file or directory - why?
Message-Id: <dfr8q0t1hbsrpjuoh42sp6c9gmmlbrmpoc@4ax.com>
On Wed, 24 Nov 2004 05:49:23 +0100, "Tassilo v. Parseval"
<tassilo.von.parseval@rwth-aachen.de> wrote:
>In fact it is. It is a message generated by File::Find, with the use of
>warnings::warnif(). That explains why the OP didn't get it when warnings
>were disabled.
>This wont help here. The answer must lie somewhere in File::Find.
<snip>
>Possibly this paragraphs from its perldocs could help:
>
> CAVEAT
> $dont_use_nlink
> You can set the variable $File::Find::dont_use_nlink to 1,
> if you want to force File::Find to always stat directo-
> ries. This was used for file systems that do not have an
> "nlink" count matching the number of sub-directories.
> Examples are ISO-9660 (CD-ROM), AFS, HPFS (OS/2 file
> system), FAT (DOS file system) and a couple of others.
>
>Tassilo
Thanks!
** Due to SPAM I no longer receive email responses to
** newsgroup postings, so don't bother.
------------------------------
Date: 24 Nov 2004 09:53:20 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: cookie failes
Message-Id: <co1lmg$3qm$1@mamenchi.zrz.TU-Berlin.DE>
daniel kaplan <nospam@nospam.com> wrote in comp.lang.perl.misc:
> "Sherm Pendley" <spamtrap@dot-app.org> wrote in message
> news:41A39AF9.1020906@dot-app.org...
> if you want to say "making obviosu remarks about my abilities" is not an
> insult, well, you're hiding behind softspeak....you don't know what i have
> done, have accomplished, etc, therefore nothign is obvious....
We've seen you perform for a few weeks. Enough to form an opinion
about your abilities as a programmer and as a Usenet poster.
> foot 2 giant you would cower at meeting, or a paraplegic who you would feel
> terible for all the insults......you don't know who i am and vice-versa.....
From here you look more like a pear-shaped hot-air balloon.
You want respect, you got to earn it.
Anno
------------------------------
Date: Wed, 24 Nov 2004 15:14:43 GMT
From: Charlton Wilbur <cwilbur@mithril.chromatico.net>
Subject: Re: cookie failes
Message-Id: <87llcrxpa0.fsf@mithril.chromatico.net>
>>>>> "uri" == Uri Guttman <uri@stemsystems.com> writes:
uri> <watching kaplan learn perl and web is like watching a train
uri> wreck in slow motion. i amazed how slowly he picks up stuff,
uri> at his poor doc parsing skills and at his vaunted claim to
uri> know c so well.>
Actually, you seem to believe that he's learning. Given his demeanor
here, I think you're giving him too much credit.
Charlton
--
cwilbur at chromatico dot net
cwilbur at mac dot com
------------------------------
Date: Wed, 24 Nov 2004 10:35:41 -0500
From: "daniel kaplan" <nospam@nospam.com>
Subject: Re: cookie failes
Message-Id: <1101310624.805165@nntp.acecape.com>
"Charlton Wilbur" <cwilbur@mithril.chromatico.net> wrote in message
news:87llcrxpa0.fsf@mithril.chromatico.net...
> Actually, you seem to believe that he's learning. Given his demeanor
> here, I think you're giving him too much credit.
talk about vreating unecessary noise in a group....
------------------------------
Date: Wed, 24 Nov 2004 12:54:23 GMT
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: CTRL-Z on Win32
Message-Id: <3w%od.6018$hJ6.3318@trndny01>
"daniel kaplan" <nospam@nospam.com> wrote in message
news:1101272111.88598@nntp.acecape.com...
> "daniel kaplan" <nospam@nospam.com> wrote in message
> news:1101270987.621584@nntp.acecape.com...
>
> > just my 2 sense....
>
> wow, must be my worst typo ever.....
> *cents
>
> also...and again new to perl so not sure how this affects, but CTRL-Z
at the
> end of the line as opposed to on a new blank line produces two
different
> results if you were cerating a file directly to DOS from the
console...so
> maybe that's it? again, too new to perl to say ... and i forget what
ctrl-z
> does....indicate EOF? i really forget, it some carry over from CP/M
if i
> recall.....not sure what CTRL-D does
Once again, this problem is wholly unrelated to the language being used.
EOF is EOF, regardless of the language used to read from standard input.
The constant disclaimer you offer of "too new to perl" is irrelevant.
The keystroke used to symbolize EOF is defined by the operating system
(or shell?), not by the language that happens to have created the
program.
Paul Lalli
------------------------------
Date: Wed, 24 Nov 2004 10:09:13 -0500
From: "daniel kaplan" <nospam@nospam.com>
Subject: Re: CTRL-Z on Win32
Message-Id: <1101309035.685727@nntp.acecape.com>
"Paul Lalli" <mritty@gmail.com> wrote in message
news:3w%od.6018$hJ6.3318@trndny01...
> Once again, this problem is wholly unrelated to the language being used.
> EOF is EOF, regardless of the language used to read from standard input.
> The constant disclaimer you offer of "too new to perl" is irrelevant.
> The keystroke used to symbolize EOF is defined by the operating system
> (or shell?), not by the language that happens to have created the
> program.
>
> Paul Lalli
>
...again, i was just postulating (sp?) on what ctrl-z does (as it's too old,
or i am also)
...if you re-read what i said it was, i don't know how it affects Perl in
that, depending where the ctrl-z is placed, you might get one extra line...i
was not claiming how ctrl-z affected perl, but how the extra blank line (or
lack thereof) affect the code he was writing....
daniel
------------------------------
Date: 24 Nov 2004 16:27:51 +0100
From: Arndt Jonasson <do-not-use@invalid.net>
Subject: Re: CTRL-Z on Win32
Message-Id: <yzdsm6z6zd4.fsf@invalid.net>
"daniel kaplan" <nospam@nospam.com> writes:
> "Paul Lalli" <mritty@gmail.com> wrote in message
> news:3w%od.6018$hJ6.3318@trndny01...
>
> > Once again, this problem is wholly unrelated to the language being used.
> > EOF is EOF, regardless of the language used to read from standard input.
> > The constant disclaimer you offer of "too new to perl" is irrelevant.
> > The keystroke used to symbolize EOF is defined by the operating system
> > (or shell?), not by the language that happens to have created the
> > program.
> >
> > Paul Lalli
> >
> ...again, i was just postulating (sp?) on what ctrl-z does (as it's too old,
> or i am also)
I think "speculating" is the word you want.
------------------------------
Date: Wed, 24 Nov 2004 10:35:06 -0500
From: "daniel kaplan" <nospam@nospam.com>
Subject: Re: CTRL-Z on Win32
Message-Id: <1101310589.145675@nntp.acecape.com>
"Arndt Jonasson" <do-not-use@invalid.net> wrote in message
news:yzdsm6z6zd4.fsf@invalid.net...
> > ...again, i was just postulating (sp?) on what ctrl-z does (as it's too
old,
> > or i am also)
>
> I think "speculating" is the word you want.
my vocabulary is worse than my typing...and that's when i'm healthy, now i
have the flu.....how i didn't type "posturing" is a mriacle....but thanks
;-)
------------------------------
Date: Wed, 24 Nov 2004 16:01:15 GMT
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: CTRL-Z on Win32
Message-Id: <ff2pd.6013$K36.1563@trndny03>
"daniel kaplan" <nospam@nospam.com> wrote in message
news:1101309035.685727@nntp.acecape.com...
> "Paul Lalli" <mritty@gmail.com> wrote in message
> news:3w%od.6018$hJ6.3318@trndny01...
>
> > Once again, this problem is wholly unrelated to the language being
used.
> > EOF is EOF, regardless of the language used to read from standard
input.
> > The constant disclaimer you offer of "too new to perl" is
irrelevant.
> > The keystroke used to symbolize EOF is defined by the operating
system
> > (or shell?), not by the language that happens to have created the
> > program.
> >
> ...if you re-read what i said it was, i don't know how it affects Perl
in
> that, depending where the ctrl-z is placed, you might get one extra
line...i
> was not claiming how ctrl-z affected perl, but how the extra blank
line (or
> lack thereof) affect the code he was writing....
Please do not accuse me of not reading your post before replying. Thank
you.
I *know* you don't know how "it affects Perl". That's why I'm telling
you that it does not. That is the point of making such replies - to
inform and educate someone who clearly does not have a certain piece of
knowledge. The secondary point of my post was to attempt to explain to
you why your almost-constant disclaimers of "I don't know Perl well,
but..." are irrelevant to the problem at hand. This is part 2 in my
attempt this week at helping you to correctly partition a problem (the
first being the CGI/Perl thread). If you do not want assistance in this
area, allow me to suggest you make an effort to learn the skill on your
own.
Thank you,
Paul Lalli
------------------------------
Date: Wed, 24 Nov 2004 11:03:04 +0000 (UTC)
From: PerlFAQ Server <comdog@panix.com>
Subject: FAQ 6.1: How can I hope to use regular expressions without creating illegible and unmaintainable code?
Message-Id: <co1pp8$gbp$1@reader1.panix.com>
This message is one of several periodic postings to comp.lang.perl.misc
intended to make it easier for perl programmers to find answers to
common questions. The core of this message represents an excerpt
from the documentation provided with Perl.
--------------------------------------------------------------------
6.1: How can I hope to use regular expressions without creating illegible and unmaintainable code?
Three techniques can make regular expressions maintainable and
understandable.
Comments Outside the Regex
Describe what you're doing and how you're doing it, using normal
Perl comments.
# turn the line into the first word, a colon, and the
# number of characters on the rest of the line
s/^(\w+)(.*)/ lc($1) . ":" . length($2) /meg;
Comments Inside the Regex
The "/x" modifier causes whitespace to be ignored in a regex pattern
(except in a character class), and also allows you to use normal
comments there, too. As you can imagine, whitespace and comments
help a lot.
"/x" lets you turn this:
s{<(?:[^>'"]*|".*?"|'.*?')+>}{}gs;
into this:
s{ < # opening angle bracket
(?: # Non-backreffing grouping paren
[^>'"] * # 0 or more things that are neither > nor ' nor "
| # or else
".*?" # a section between double quotes (stingy match)
| # or else
'.*?' # a section between single quotes (stingy match)
) + # all occurring one or more times
> # closing angle bracket
}{}gsx; # replace with nothing, i.e. delete
It's still not quite so clear as prose, but it is very useful for
describing the meaning of each part of the pattern.
Different Delimiters
While we normally think of patterns as being delimited with "/"
characters, they can be delimited by almost any character. perlre
describes this. For example, the "s///" above uses braces as
delimiters. Selecting another delimiter can avoid quoting the
delimiter within the pattern:
s/\/usr\/local/\/usr\/share/g; # bad delimiter choice
s#/usr/local#/usr/share#g; # better
--------------------------------------------------------------------
Documents such as this have been called "Answers to Frequently
Asked Questions" or FAQ for short. They represent an important
part of the Usenet tradition. They serve to reduce the volume of
redundant traffic on a news group by providing quality answers to
questions that keep coming up.
If you are some how irritated by seeing these postings you are free
to ignore them or add the sender to your killfile. If you find
errors or other problems with these postings please send corrections
or comments to the posting email address or to the maintainers as
directed in the perlfaq manual page.
Note that the FAQ text posted by this server may have been modified
from that distributed in the stable Perl release. It may have been
edited to reflect the additions, changes and corrections provided
by respondents, reviewers, and critics to previous postings of
these FAQ. Complete text of these FAQ are available on request.
The perlfaq manual page contains the following copyright notice.
AUTHOR AND COPYRIGHT
Copyright (c) 1997-2002 Tom Christiansen and Nathan
Torkington, and other contributors as noted. All rights
reserved.
This posting is provided in the hope that it will be useful but
does not represent a commitment or contract of any kind on the part
of the contributers, authors or their agents.
------------------------------
Date: 24 Nov 2004 08:30:50 GMT
From: Villy Kruse <vek@station02.ohout.pharmapartners.nl>
Subject: Re: Fork, exec - setsid?
Message-Id: <slrncq8hlq.5i9.vek@station02.ohout.pharmapartners.nl>
On 23 Nov 2004 16:34:17 +0100,
Arndt Jonasson <do-not-use@invalid.net> wrote:
>
> 'kill' can take a negative number, and then kills the processes in a
> process group. This may be what you want. Thus:
>
> kill 9, -$cpid;
>
> Another solution is to send $s_id up to the parent by some means.
and it would be better to use signal 15 as that would give the shell
a chance to do its cleaning up. With signal 9 it dosn't get that chance.
Also, specifying the negative pid works only if that pid is the process
group leader, which would be the case if POSIX::setsid or setpgrp didn't
fail. You can get the actual process group using the getpgrp function.
Villy
------------------------------
Date: Wed, 24 Nov 2004 15:05:53 +0100
From: Robert Manea <rob@nova.hbx.us>
Subject: Re: Fork, exec - setsid?
Message-Id: <1g42oc.t71.ln@rob.unisolblade.de>
Segfault in module "Anno Siegel" - dump details are as follows:
> That would mean that one or another of the programs you start has
> demon-like properties and puts itself in the background (It may leave
> a pidfile around, if so).
Well, if I understand the documentation correctly I have to contradict
you.
A shell with job control arranges a pipeline in such a way that the
invoking instance of the shell is the process group leader (PGL).
A process group (PG) will be exsisting until all of the processes in
this group have been terminated even if the PGL has been killed.
Thus there is no need for any process within the PG to be daemonized in
order to exist after the PGL has been terminated.
Or am I misinterpreting something?
> The whole thing has little to do with Perl, but is a fork/exec/kill
> issue and also depends on the behavior of the programs you run. The
> question to ask is, how would you end a run if the program was used
> "normally", whatever that means, and see how to gain that kind of
> control from Perl.
Ok, agreed. Not a 100% pure perl thing. Should have better asked in a
unix.programmer group..
Maybe a F'UP?
> Anno
Greets, Rob
--
The Enterprise meets God, and it's a child, a computer, or a C program.
------------------------------
Date: Wed, 24 Nov 2004 15:11:13 +0100
From: Robert Manea <rob@nova.hbx.us>
Subject: Re: Fork, exec - setsid?
Message-Id: <1q42oc.v71.ln@rob.unisolblade.de>
Segfault in module "Villy Kruse" - dump details are as follows:
> On 23 Nov 2004 16:34:17 +0100,
> Arndt Jonasson <do-not-use@invalid.net> wrote:
>>
>> 'kill' can take a negative number, and then kills the processes in a
>> process group. This may be what you want. Thus:
>>
>> kill 9, -$cpid;
>>
>> Another solution is to send $s_id up to the parent by some means.
> and it would be better to use signal 15 as that would give the shell
> a chance to do its cleaning up. With signal 9 it dosn't get that chance.
> Also, specifying the negative pid works only if that pid is the process
> group leader, which would be the case if POSIX::setsid or setpgrp didn't
> fail. You can get the actual process group using the getpgrp function.
Thanks a lot Arndt and Villy. That definitly is what I was searching for.
Should have better read kill(2) as the behaviour is documented there in
quite round terms..
> Villy
Greets, Rob
--
The Enterprise meets God, and it's a child, a computer, or a C program.
------------------------------
Date: Wed, 24 Nov 04 08:27:21 GMT
From: hengre386@yahoo.com(GET YOUR FREE TRIP)
Subject: GET YOUR FREE TRIP
Message-Id: <04112408272126164@newshost.allthenewsgroups.com>
TRIPS TO DESNEY
TRIPS TO HAWAII
ALL FREE
http://travelexpert2004.us
http://travelexpert2004.biz
http://gotraveling85.us
------------------------------
Date: Wed, 24 Nov 2004 15:09:34 GMT
From: peter@PSDT.com (Peter Scott)
Subject: Re: How to "unread" STDIN?
Message-Id: <Ou1pd.313252$Pl.261979@pd7tw1no>
In article <co10r2$a29$1@reader1.panix.com>,
KKramsch <karlUNDERSCOREkramsch@yahooPERIODcom.invalid> writes:
>In <slrncq7r4r.3jk.tadmc@magna.augustmail.com> Tad McClellan <tadmc@augustmail.com> writes:
>>Why do you think you need to unread STDIN?
>
>I'm trying to understand a large (and poorly documented program)
>by stepping through it using DB. In various places, the program
>reads from <STDIN>. It would make my life a whole lot easier if
>I didn't have to restart DB every time I wanted to affect what the
>program reads from <STDIN>.
Step to the place the program reads from STDIN, and provided
it's a simple variable assignment like, say,
while (<STDIN>)
then step just past that statement and then put into the input
variable whatever you'd like it to have read instead, e.g.,
DB<1> $_ = "fnord\n"
And then continue.
--
Peter Scott
http://www.perldebugged.com/
*** NEW *** http://www.perlmedic.com/
------------------------------
Date: 24 Nov 2004 04:32:31 -0800
From: boekhold@gmail.com
Subject: Installing modules on Solaris in non-default location
Message-Id: <1101299551.773040.139600@z14g2000cwz.googlegroups.com>
Hi,
I'm having quite some difficulty in installing even the simplest Perl
module on a Solaris 2.8 system (default perl installation) if I try to
use a non-default installation directory.
Typically 'perl Makefile.PL PREFIX=/dir' would work, but this still
tries to place the files under /usr/perl5/5.00503/site_perl.
'perl Makefile.PL PREFIX=/dir LIB=/dir/lib' comes a bit further, but
still fails at installing the manual pages in the correct location.
'perl Makefile.PL PREFIX=/dir INSTALLSITELIB=/dir INSTALLDIRS=site \
INSTALLMAN1DIR=/dir/man/man1 INSTALLMAN3DIR=/dir/man/man3' comes even
further, but fails on 'Appending installation info to
/usr/perl5/5.00503/sun4-solaris/perllocal.pod'
Why is this so difficult with the standard solaris perl installation?
"This is perl, version 5.005_03 built for sun4-solaris"
Kind regards, Maarten
------------------------------
Date: 24 Nov 2004 04:45:17 -0800
From: "boekhold" <boekhold@gmail.com>
Subject: Re: Installing modules on Solaris in non-default location
Message-Id: <1101300317.424860.267290@c13g2000cwb.googlegroups.com>
Hmm, I'll be damned. The following seems to work:
perl Makefile.PL LIB= PREFIX= INSTALLMAN1DIR= INSTALLMAN3DIR=
Still, would be nice if just 'PREFIX' would do the job...
Maarten
------------------------------
Date: 24 Nov 2004 09:53:22 +0100
From: Arndt Jonasson <do-not-use@invalid.net>
Subject: Re: Managing PERL5LIB with multiple perl installation
Message-Id: <yzdwtwb7hml.fsf@invalid.net>
Ben Morrow <usenet@morrow.me.uk> writes:
> Quoth $HOME:
> > * Big and Blue <No_4@dsl.pipex.com>:
> > <SNIP>
> > > Write an interlude (for *both* perls if necessary) which sets the
> > > relevant PERL5LIB for each before exec'ing the real perl executable (or
> > > write modules and prepend a -M.... arg before those passed on before
> > > exec'ing). Then use those interludes to free yourself from environmental
> > > pollution.
> >
> > I am not sure what an interlude is. can you please elaborate on it?
>
> A more usual (or perhaps simply more modern?) term would be 'shell
> script' or 'batch file', depending on OS.
Another term in common use is 'wrapper'. Exactly what it wraps depends
on context, of course - you can have wrapper functions too. The term
"interlude" was new to me - a dejanews search on comp.* gives me 52
hits for "interlude AND script" and 15000 for "wrapper AND script".
Outside the programming world, "interlude" has to do with music.
------------------------------
Date: 24 Nov 2004 10:31:55 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: parent of an orphaned process
Message-Id: <co1nur$5ea$1@mamenchi.zrz.TU-Berlin.DE>
<madhav_a_kelkar@hotmail.com> wrote in comp.lang.perl.misc:
> hi all,
>
> i was doing the following program in perl
>
> #!/usr/bin/perl
> 2
> 3 main();
> 4
> 5 sub main
> 6 {
> 7 my $id;
> 8 if(($id=fork())==0)
> 9 {
> 10 print("in child process, id=$$!\n");
> 11 sleep 5;
> 12 $i=getppid;
> 13
> 14
> 15 if(kill 0,$i)
> 16 {
> 17 print("signal sent\n");
> 18 }
> 19 else
> 20 {
> 21 print("parent died pid=$i\n");
> 22 }
> 23
> 24 exit;
> 25 }
> 26 else{
> 27 print("parent terminated\n");
> 28 exit(0);
> 29 }
>
> note that i am taking the parent pid after the
> parent has exited.
You are taking it after sleeping for five seconds. Presumably the parent
process had time to terminate, but we don't *know* this.
> according to std unix idiom,
Idioms are part of languages (including computer languages). What
you are describing is the behavior of an OS, not an idiom.
> the init process (with
> pid =1) should be the parent of the orphaned child process in this
> example. but when i executed the code, this was the output:
>
> [madhav@madhav perl]$ perl child.pl
> in child process, id=13235!
> parent terminated
> [madhav@madhav perl]$ parent died pid=13234
>
> this indicates that the parent of the orphaned child process is not
> the init process as it should be. please tell me what is means. i did
> the same program in C and got the parent id as 1. cant it be the same
> with perl?
It is, for me. When I run your program, I see
[anno4000@lublin ~/clpm]$ perl ttt
parent terminated
in child process, id=13690!
[anno4000@lublin ~/clpm]$ parent died pid=1
No idea why it's behaving differently for you, but it doesn't look
like Perl is responsible.
Anno
------------------------------
Date: 24 Nov 2004 13:47:48 GMT
From: Villy Kruse <vek@station02.ohout.pharmapartners.nl>
Subject: Re: parent of an orphaned process
Message-Id: <slrncq9484.5vc.vek@station02.ohout.pharmapartners.nl>
On 24 Nov 2004 10:31:55 GMT,
Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> <madhav_a_kelkar@hotmail.com> wrote in comp.lang.perl.misc:
>> hi all,
>>
>> i was doing the following program in perl
>>
>> #!/usr/bin/perl
>> 2
>> 3 main();
>> 4
>> 5 sub main
>> 6 {
>> 7 my $id;
>> 8 if(($id=fork())==0)
>> 9 {
>> 10 print("in child process, id=$$!\n");
>> 11 sleep 5;
>> 12 $i=getppid;
>> 13
>> 14
>> 15 if(kill 0,$i)
>> 16 {
>> 17 print("signal sent\n");
>> 18 }
>> 19 else
>> 20 {
>> 21 print("parent died pid=$i\n");
>> 22 }
>> 23
>> 24 exit;
>> 25 }
>> 26 else{
>> 27 print("parent terminated\n");
>> 28 exit(0);
>> 29 }
>>
>> note that i am taking the parent pid after the
>> parent has exited.
>
> You are taking it after sleeping for five seconds. Presumably the parent
> process had time to terminate, but we don't *know* this.
>
But then again the kill command seems to have failed which is probably
a permission error. Displaying the $! variable would have shown if that
were the case. Anyway, the original parent should have the same user id
as the child so kill shouldn't return with a permission error, but if
the child was orphaned the new parent may very well have a different uid.
Perhaps this example wasn't run on a real unix system.
Villy
------------------------------
Date: Wed, 24 Nov 2004 02:14:40 -0600
From: Alan Mead <amead@comcast.net>
Subject: Re: redirect question
Message-Id: <pan.2004.11.24.08.14.40.467106@comcast.net>
On Wed, 24 Nov 2004 01:20:01 -0600, Alan Mead wrote:
> On Tue, 23 Nov 2004 23:41:13 -0500, daniel kaplan wrote:
>
>> i explained why i thought it was an overlap, but paul made it clear why,
>> it's all about CGI, so i thanked him and dropped it here...and have already
>> posted the question on comp.....authoiring.cgi ... of course not one new
>> post in 10 hours has shown up there, but what can you do...will wait till
>> tomorrow before reposting...
>
> I don't see your question on c.i.w.a.cgi. So I would repost, if I were
> you.
I am soooo dull at 1:20 am... c.i.w.a.cgi is self-moderated. You need to
approve your post if you want it to appear. Look at any article there for
a link that explains it...
-Alan
------------------------------
Date: Wed, 24 Nov 2004 10:10:26 -0500
From: "daniel kaplan" <nospam@nospam.com>
Subject: Re: redirect question
Message-Id: <1101309108.626409@nntp.acecape.com>
"Alan Mead" <amead@comcast.net> wrote in message
news:pan.2004.11.24.08.14.40.467106@comcast.net...
> I am soooo dull at 1:20 am... c.i.w.a.cgi is self-moderated. You need to
> approve your post if you want it to appear. Look at any article there for
> a link that explains it...
>
> -Alan
WOW, thanks so much for telling me that......
daniel
------------------------------
Date: Wed, 24 Nov 2004 10:36:25 -0500
From: "daniel kaplan" <nospam@nospam.com>
Subject: Re: redirect question
Message-Id: <1101310668.166613@nntp.acecape.com>
"Tad McClellan" <tadmc@augustmail.com> wrote in message
news:slrncq8a10.516.tadmc@magna.augustmail.com...
>
>
> LOL!
talk about creating unnecessary noise in a group
------------------------------
Date: Wed, 24 Nov 2004 14:06:40 -0000
From: "Stuart Palmer" <tryandspamme@youcant.com>
Subject: ssi querystring
Message-Id: <30jirgF30h8tkU1@uni-berlin.de>
Hi,
Not sure if this is the right place to post this as it's pure ssi question,
but I'll try anyway......
I have a server that only allows me to run ssi code. No perl, no asp, just
ssi code.
I can pull into a variable - <!--#set var="querystring"
value="$QUERY_STRING" -->
Now, if my querystring passed through has 3 params and values, I'd like to
split this up or pull in each of the 3 values into seperate variables, so I
can process them seperatly.
I would imagine that perhaps I might be able to do something like:
<!--#set var="var1" value="$QUERY_STRING('variable1')" -->
<!--#set var="var2" value="$QUERY_STRING('variable2')" -->
<!--#set var="var3" value="$QUERY_STRING('variable3')" -->
but not sure if this is valid context, if indeed it can be done.
Is there anyway I can do this?...if so, how? I don't want to use Javascript
(as this defeats the object or what I am trying to achieve)
Thanks for any help
Stu
------------------------------
Date: 24 Nov 2004 11:19:21 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: sysread(socket..) problem on perl 5.8.0 linux
Message-Id: <co1qnp$5ea$2@mamenchi.zrz.TU-Berlin.DE>
Bean <bcant@centra-systems.com> wrote in comp.lang.perl.misc:
> After more coffee I realized i've mixed buffered/non-buffered IO :/
...and to tell us that you had to quote 250 lines of your own posting?
Anno
------------------------------
Date: 24 Nov 2004 02:22:33 -0800
From: donal.k.fellows@man.ac.uk (Donal K. Fellows)
Subject: Re: Using embedded PERL with commercial applications?
Message-Id: <cdcf9bb7.0411240222.7871acb9@posting.google.com>
Tassilo v. Parseval wrote:
> The Perl license includes both the GPL (which would be a problem here)
> and the Artistic license. You can pick the one you like better which in
> your case will be the Artistic license. It states (paragraph 8):
>
> 8. Aggregation of this Package with a commercial distribution is
> always permitted provided that the use of this Package is embedded;
> that is, when no overt attempt is made to make this Package's
> interfaces visible to the end user of the commercial distribution.
> Such use shall not be construed as a distribution of this Package.
To me that says "You can implement your functionality using Perl, and
embed Perl to ensure that that functionality operates, but you can't
expose Perl scripting without falling under the restrictions due to
the AL."
By contrast, Tcl's license is "As long as you don't claim you wrote
Tcl or sue us, embed away in any way that suits you." Much easier to
get past the suits. :^)
Donal.
------------------------------
Date: Wed, 24 Nov 2004 13:05:21 +0100
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: Using embedded PERL with commercial applications?
Message-Id: <slrncq8u81.pm.tassilo.von.parseval@localhost.localdomain>
Also sprach Donal K. Fellows:
> Tassilo v. Parseval wrote:
>> The Perl license includes both the GPL (which would be a problem here)
>> and the Artistic license. You can pick the one you like better which in
>> your case will be the Artistic license. It states (paragraph 8):
>>
>> 8. Aggregation of this Package with a commercial distribution is
>> always permitted provided that the use of this Package is embedded;
>> that is, when no overt attempt is made to make this Package's
>> interfaces visible to the end user of the commercial distribution.
>> Such use shall not be construed as a distribution of this Package.
>
> To me that says "You can implement your functionality using Perl, and
> embed Perl to ensure that that functionality operates, but you can't
> expose Perl scripting without falling under the restrictions due to
> the AL."
I don't think so. Here's how the license defines package:
"Package" refers to the collection of files distributed by the
Copyright Holder, and derivatives of that collection of files
created through textual modification.
When providing Perl scripting abilities, you are _not_ providing an
interface to the collections of files the package consists of.
The Artistic license mostly deals with how you modify the software and
how that affects distribution. This does not apply when you embed a Perl
interpreter.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Wed, 24 Nov 2004 14:08:04 GMT
From: claird@lairds.us (Cameron Laird)
Subject: Re: Using embedded PERL with commercial applications?
Message-Id: <0nee72-p48.ln1@lairds.us>
In article <a1538a71.0411232156.69cbeabd@posting.google.com>,
Patrick Finnegan <chppxf1@yahoo.com.au> wrote:
>We just had a discussion in the Office about the use of embedded Perl
>with commercial applications. Three of the server applications used
>in the corporate environment, WebSphere, Control SA and Cisco
>Networks, use Tcl or a Tcl derivative as the embedded scripting
>interface. Is there a licensing limitation on the use of embedded
>PERL with commercial applications?
I'll answer a different question, leaving yours about licensing
to others: Perl is *technically* more difficult to embed, and
even more so in the past. Also, Tcl's event constructs and
reduced syntax are handy for the supervisory applications Oracle,
IBM, et al., require.
I like your LDAP contributions, by the way.
------------------------------
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 7443
***************************************
