[19174] in Perl-Users-Digest
Perl-Users Digest, Issue: 1369 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 24 14:06:29 2001
Date: Tue, 24 Jul 2001 11:05:18 -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: <995997917-v10-i1369@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Tue, 24 Jul 2001 Volume: 10 Number: 1369
Today's topics:
Re: CGI -> Apache Problem <Thomas@Baetzler.de>
Re: dumb question (Greg Bacon)
dynamically create hash? <mdulrich@unity.ncsu.edu>
Re: dynamically create hash? <mdulrich@unity.ncsu.edu>
Re: encrypt a password <Patrick_member@newsguy.com>
Re: encrypt a password nobull@mail.com
Re: encrypt a password <gerard@NOSPAMlanois.com>
fatal.pm <paul.johnston@dsvr.co.uk>
Re: fatal.pm <weiss@kung.foo.at>
Re: Filehandle major weirdness in recursive I/O <mjcarman@home.com>
Re: Filehandle major weirdness in recursive I/O nobull@mail.com
Re: Filehandle major weirdness in recursive I/O (Anno Siegel)
How Can I Run Command Line and Perl from the Same File? (Rick Kasten)
Re: How Can I Run Command Line and Perl from the Same F <jeff@vpservices.com>
Re: How Can I Run Command Line and Perl from the Same F <bart.lateur@skynet.be>
Re: How to convert Pc/Unix characterset (ISO-lat1) to t <bjoern@hoehrmann.de>
IO::Socket-Question (Konstantinos Agouros)
Re: IO::Socket-Question <buggs-clpm@splashground.de>
mod_perl for NT <curtish@ourtownusa.net>
Re: mod_perl for NT <bart.lateur@skynet.be>
Re: nested forks - help.... <bruce.g.mcardle_remove@intel.com>
Re: Newbie problem: if(<STDIN> =~ /^[yY]/) control stru <sunshinj@mail.nih.gov>
Re: Newbie problem: if(<STDIN> =~ /^[yY]/) control stru (Craig Berry)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 24 Jul 2001 17:38:28 +0200
From: =?ISO-8859-1?Q?Thomas_B=E4tzler?= <Thomas@Baetzler.de>
Subject: Re: CGI -> Apache Problem
Message-Id: <r15rltc34hjtd9t253mfjh62a7ujdlt0i0@4ax.com>
On Tue, 24 Jul 2001 "Georg Vassilopulos"
<Georg.Vassilopulos@SoftwareAG.de> wrote:
>I really freak out. Following situation:
[...]
>My code snippet:
>
>my $command = "p:/tools/wni/unzip.exe $myFile";
>system ($command) or print "Fuck the system command:$!";
[...]
I bet that P: is a mapped drive and that the Apache runs as a service
under a special user account on your Server. So from the Apache's POV,
there probably is no P: drive as drive mappings are only active for
the currently logged in account.
Solution: move unzip to a local FS.
HTH,
--
Thomas Baetzler - http://baetzler.de/ - Clan LoL - http://lavabackflips.de/
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This post was infected under the terms of the GNU General Public License.
------------------------------
Date: Tue, 24 Jul 2001 17:41:46 -0000
From: gbacon@HiWAAY.net (Greg Bacon)
Subject: Re: dumb question
Message-Id: <tlrcqq4apma461@corp.supernews.com>
In article <slrn9lpc1e.9a2.abigail@alexandra.xs4all.nl>,
Abigail <abigail@foad.org> wrote:
: Greg Bacon (gbacon@HiWAAY.net) wrote on MMDCCCLXXX September MCMXCIII in
: <URL:news:tlgjcet4ickba5@corp.supernews.com>:
:
: @@ The 0/1 Knapsack problem is similar, but sycorax is describing
: @@ SUBSET-SUM, which is, as you noted, NP-complete.
:
: 0/1 Knapsack is NP-complete too. SUBSET-SUM trivially reduces to
: 0/1 Knapsack.
That's what I said. :-)
Greg
--
What George Washington did for us was to throw out the British, so that we
wouldn't have a fat, insensitive government running our country. Nice try
anyway, George.
-- D.J. on KSFO/KYA
------------------------------
Date: Tue, 24 Jul 2001 11:33:48 -0400
From: Marc Ulrich <mdulrich@unity.ncsu.edu>
Subject: dynamically create hash?
Message-Id: <3B5D955C.3E050A40@unity.ncsu.edu>
I need to create a hash based on what I might find in a text file given
to my Perl script. How can I do this?
I cannot find the answer anywhere. I think it can simply be answered by
how do I add a key and value to an existing hash? There's a delete
command, but no add command.
Thanks,
Marc
------------------------------
Date: Tue, 24 Jul 2001 11:39:13 -0400
From: Marc Ulrich <mdulrich@unity.ncsu.edu>
Subject: Re: dynamically create hash?
Message-Id: <3B5D96A1.ED754434@unity.ncsu.edu>
Ack. Just found it!
$hash{key} = value;
I also noticed an answer to this which said to read the man perldata
pages. So I apologize to those who think this is obvious. I couldn't find
the answer when scanning those man pages. . .
Marc
Marc Ulrich wrote:
> I need to create a hash based on what I might find in a text file given
> to my Perl script. How can I do this?
>
> I cannot find the answer anywhere. I think it can simply be answered by
> how do I add a key and value to an existing hash? There's a delete
> command, but no add command.
>
> Thanks,
> Marc
------------------------------
Date: 24 Jul 2001 08:26:30 -0700
From: Patrick Flaherty <Patrick_member@newsguy.com>
Subject: Re: encrypt a password
Message-Id: <9jk43601mle@drn.newsguy.com>
Thanx Rob,
What I was hoping was that I could encrypt the password, using some tool,
_outside_ of Perl; then put the encrypted form into the source; and then have
this decrypted by a Perl subroutine just prior to its going out to the wire.
Although, now that I think about it, I'm not sure this makes sense. Since
presumably someone else could then take my encrypted form out of my source and
write their own little Perl program thtat decrypts. ... Unless of course, I
somehow work at private, personal key into the scheme. That is, the Perl
decrypt knows to go to a protected location to get my private key.
Maybe in the end what I want, as you suggest, is to simply compile the script.
I'm kind of new to Perl: how does one do this? (Yes I'll look it up in the
docs).
pat
In article <3B5CFC6C.6A41A1AF@ce.gatech.edu>, Robert says...
>
>Patrick Flaherty wrote:
>>
>> Hello,
>>
>> ActiveState Perl on W2000.
>>
>> What do people recommend for encrypting a password to be put into code that
>> makes use of Net::FTP?
>>
>>CPAN tells me of 15 modules (or are they packages?) that correspond to .*crypt.*
>>However what I think I need is, obviously, something that encrypts the password
>>_outside_ of Perl that I can then put into the code where it will be decrypted.
>>I'm not going to worry yet about what form of the password travels over the wire
>> during the ftp transaction. I just don't want the plaintext of my password
>> sitting in my Perl source.
>>
>> pat
>
>if your script can decrypt it, then anyone reading the source will be
>able to as well...you may want to compile the script or lock down that
>account so it can only do what you intend it to do. as far as the
>over-the-wire issue, look at Net::SFTP.
>
>-rob
------------------------------
Date: 24 Jul 2001 17:55:25 +0100
From: nobull@mail.com
Subject: Re: encrypt a password
Message-Id: <u94rs2nu6a.fsf@wcl-l.bham.ac.uk>
Patrick Flaherty <Patrick_member@newsguy.com> writes:
> I'm not going to worry yet about what form of the password travels over the wire
> during the ftp transaction. I just don't want the plaintext of my password
> sitting in my Perl source.
Your problem is:
1) Fundamentally insoluable.
2) Nothing to do with Perl (because of (1)).
3) Frequently asked here.
There is no way to write a program such that running the program will
output a secret and such that a person with access to the code of the
program cannot determine the secret.
You can obscure the password such that a person looking at the source
and not deliberately trying to discover the password will not
unintensionally become aware of the password.
If this is your goal then the simplest obscuring algorithm to
implement in Perl is a simple XOR:
my $password = "uirtqzfguls" ^ "likujyhtgrf" ^ "tyFqzp}d}lq";
print "$password\n";
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 24 Jul 2001 10:34:09 -0700
From: Gerard Lanois <gerard@NOSPAMlanois.com>
Subject: Re: encrypt a password
Message-Id: <uelr65izy.fsf@NOSPAMlanois.com>
Patrick Flaherty <Patrick_member@newsguy.com> writes:
> I just don't want the plaintext of my password
> sitting in my Perl source.
How about prompting for it instead?
# This works on Windows as well as Unices.
use Term::ReadKey;
print "login: ";
my $login = ReadLine(0);
chomp $login;
print "password: ";
ReadMode('noecho');
my $password = ReadLine(0);
ReadMode('restore');
chomp $password;
-Gerard
http://www.geocities.com/gerardlanois/perl/
------------------------------
Date: Tue, 24 Jul 2001 17:38:24 +0100
From: Paul Johnston <paul.johnston@dsvr.co.uk>
Subject: fatal.pm
Message-Id: <3B5DA480.F917D8D7@dsvr.co.uk>
Hi,
I notice few/no people use the Fatal module in code they post here. I
personally like it, as 95% of the time I handle an error by die()ing
with an appropriate message, and the other 5% I can handle quite nicely
using eval. Is there a good reason to avoid it, or just personal
preference?
Paul
------------------------------
Date: Tue, 24 Jul 2001 19:52:39 +0200
From: "Stefan Weiss" <weiss@kung.foo.at>
Subject: Re: fatal.pm
Message-Id: <3b5db53b$1@e-post.inode.at>
"Paul Johnston" <paul.johnston@dsvr.co.uk> wrote:
> I notice few/no people use the Fatal module in code they post here. I
> personally like it, as 95% of the time I handle an error by die()ing
> with an appropriate message, and the other 5% I can handle quite nicely
> using eval. Is there a good reason to avoid it, or just personal
> preference?
I can only give you my reason for not using Fatal:
In a Perl script I can play God and decide when I want to die. Since
there is currently no resurrect() built-in, Fatal would only make me
human again. Seriously, I usually don't handle errors with a fatal
exception, unless there is a very good reason to do so. If you are
writing modules, there is almost always a better solution than dying.
If all else fails, I usually want to utter some last words, make my
peace with the (other) gods, tell the user _exactly_ what was killing
me (more verbosely than $!), maybe log date and manner of my death,
then die.
Other reasons:
- I don't like the format of the failure statements produced by Fatal,
eg "main::__ANON__('FH', 'test.txt') called at foobar.pl line 4"
- Failure statements in a different language than English.
- consider this case:
use warnings;
use Fatal qw(:void open close);
open(FH, "test.txt");
print <FH>;
close(FH);
If test.txt could not be opened, fatal kills my script, as it is
supposed to. But additionally I get the warning:
"Name 'main::FH' used only once: possible typo at fatal.pl line 4."
This is misleading.
- And if somewhere along the script I decide to copy and paste some
sub from another script into this script, and this function _does_
use "or die" with open(), like here:
use Fatal qw(:void open close);
sub stirb {
open(FH, "xtest.txt") or die "Oops: $!";
print <FH>; close(FH);
}
stirb();
I get the error message:
"Oops: at fatal.pl line 3."
These are some of the reasons why I've only played around with Fatal
for a few minutes, then decided to do things the traditional way.
cheers,
stefan
------------------------------
Date: Tue, 24 Jul 2001 11:06:56 -0500
From: Michael Carman <mjcarman@home.com>
Subject: Re: Filehandle major weirdness in recursive I/O
Message-Id: <3B5D9D20.B28BFB54@home.com>
Andrew Mayo wrote:
>
> Running Perl 5.6.0 on Win2k. The following test program demonstrates a
> canonical case of recursive include processing. It takes two data
> files.
>
[...]
>
> printit("include.txt");
>
> sub printit
> {
> my $fh;
>
> open $fh,$_[0];
You should always test the return value of open()!
open($fh, $_[0]) or die "Can't open '$_[0]' [$!]\n";
> while (<$fh>)
> {
> if (m/include/)
> {
> printit("include1.txt");
> }
> print $_;
> }
> close $fh;
> }
You're trying to use $fh as a symref to a filehandle. Enable warnings
with -w and put 'use strict' at the beginning of your script (which you
should do for any non-trivial script) and Perl will tell you what's
wrong.
I would write this as either:
sub printit {
local *FH;
open(FH, $_[0]) or die "$!";
#...
}
or use the FileHandle module.
> The error messages indicate that I/O was being attempted on an
> uninitialised file handle.
Because $fh is uninitialized, and thus it doesn't refer to anything,
even symbolicly.
> Changing the line
>
> my $fh;
>
> to read
>
> my $fh="";
>
> cured the error messages but NOW.... when the inner file is read, and
> the routine printit returns to its caller, we get EOF immediately on
> the outer file read loop and so the remaining lines in the file
> include.txt are not printed.
Symrefs can only be used on global variables, so you didn't really have
two filehandles. $fh might have been local, but the thing it referred to
was not.
-mjc
------------------------------
Date: 24 Jul 2001 17:52:07 +0100
From: nobull@mail.com
Subject: Re: Filehandle major weirdness in recursive I/O
Message-Id: <u97kwynubs.fsf@wcl-l.bham.ac.uk>
ajmayo@my-deja.com (Andrew Mayo) writes:
> I have absolutely no mental model for the following weird behaviour,
> can anyone help?.
Yes, Perl can help. "use strict" and "use warnings". We always
recommend this. We do this for a reason. Can you guess what it is?
> my $fh;
>
> open $fh,$_[0];
> ...perl
> sometimes gets upset about using $fh and produces spurious error
> messages (seems to depend on perl version #, and I wanted to use this
> code against different perl versions)
>
> The error messages indicate that I/O was being attempted on an
> uninitialised file handle.
Filehandle autovivification is a new feature. If you attempt
filehandle autovivification on an older version of Perl you'll get
that error.
> Changing the line
>
> my $fh;
>
> to read
>
> my $fh="";
>
> cured the error messages
In the same way that taking the batteries out "cures" a noisey smoke
alarm.
If you'd used strict you'd have got a different error:
Can't use string ("") as a symbol ref while "strict refs" in use
This would totally have ruined all your fun by making your mistake
blindingly obvious. And "use strict" is for wimps isn't it? You are
macho and don't need no namby-pamby safety ropes.
The way to put out the fire is:
# Explictly create new filehandle where autovivification not supported
use IO::Handle;
my $fh = IO::Handle->new;
> but NOW.... when the inner file is read, and
> the routine printit returns to its caller, we get EOF immediately on
> the outer file read loop and so the remaining lines in the file
> include.txt are not printed.
>
> I am confused about this because $fh is a locally-scoped variable and
> should therefore be preserved on the stack frame of printit.
It is. But all instances of $fh are, in this case, symbolic
references to the same global variable having the null string as its
name.
> And
> indeed it does seem to be, unless it is initialised. But in theory,
> initialising $fh in the inner stack frame cannot possibly alter the
> outer stack frame copy.
If cannot. But modifying it's not $fh that is the filehandle. $fh
is a _reference_ (symbolic in this case) to a filehadle.
> Can anyone explain what is going on here, or is this a bug?.
Evidently you can... as you go on to say...
> Or is $fh acting like an object reference so that the inner copy is
> really pointing to the same object as the outer copy?.
Yep. Exactly right.
> But if that was so, how come using it in the inner routine WITHOUT
> initialising doesn't cause a problem?.
Autovivification.
> Somehow in that case, the currency of the
> outer-level file read is not altered by the recursive call, which
> isn't consistent with that theory,
Unless of course you consider autovivification.
> Perhaps I am doing things stupidly. If so, what is the preferred
> method for handling recursive file I/O, which is required for
> processing includes in the input text stream?. I've searched the FAQs
> without obvious success.
The FAQ "How can I make a filehandle local to a subroutine?..." is out
of date - it doesn't know about filehandle autovivification. It also
talks about the FileHandle module which has been superceded by IO::Handle.
The way you are doing it is actually better than the way given in the
FAQ if you are on a version of Perl new enough to have filehandle
autovivification. On older versions call IO::Handle->new explicitly.
(On really old versions (before 5.4) call FileHandle->new. On really
really old versions (before 5?) you have to resort to really nasty
tricks).
> And there is more weirdness yet. If I print $fh after the open it
> prints GLOB(0xnnnnn) where nnnnn is a hex address. And this number is
> different for the inner and outer calls, as you would expect. But if I
> assign $fh="xyz" before the open, then after the open, $fh still
> prints as "xyz" but the while(<$fh>) loop does read correctly (albeit
> that we get the problem referred to earlier when we return from the
> loop to the caller).
Yes, autovivification only comes into effect if the variable you are
trying to use in reference context is undefined. If you use a string
(even a null one) in a reference context then with "no strict
qw(refs)" in effect it will act as a symbolic reference.
> If $fh contains the string "xyz" how can it simultaneously act as a
> file handle?
Because despite all our efforts you didn't put "use strict" at the top
of your script to disable symbolic references.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 24 Jul 2001 17:10:37 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Filehandle major weirdness in recursive I/O
Message-Id: <9jka6d$bto$1@mamenchi.zrz.TU-Berlin.DE>
According to Andrew Mayo <ajmayo@my-deja.com>:
> I have absolutely no mental model for the following weird behaviour,
> can anyone help?.
>
> Running Perl 5.6.0 on Win2k. The following test program demonstrates a
> canonical case of recursive include processing. It takes two data
> files.
>
> File include.txt contains the following lines
>
> line 1
> include
> line 2
> line 3
>
> and file include1.txt contains the following lines
>
> inc 1
> inc 2
> inc 3
> inc 4
>
> The perl program below reads include.txt and when it hits the line
> 'include', reads include1.txt by recursively invoking the read
> routine, then resumes reading include.txt. Thus, the output will be
>
> line 1
> inc 1
> inc 2
> inc 3
> inc 4
> line 2
> line 3
>
> and here is the program
>
> printit("include.txt");
>
> sub printit
> {
> my $fh;
>
> open $fh,$_[0];
> while (<$fh>)
> {
> if (m/include/)
> {
> printit("include1.txt");
> }
> print $_;
> }
> close $fh;
> }
I'd expect that to work as intended, and it (or something very similar)
does with Perl 5.6.1.
> So what am I confused about?. Well, depending on the complexity of the
> actual program (this is a vastly simplified 'canonical case'), perl
> sometimes gets upset about using $fh and produces spurious error
> messages (seems to depend on perl version #, and I wanted to use this
> code against different perl versions)
>
> The error messages indicate that I/O was being attempted on an
> uninitialised file handle.
Your example code fails to check open() for success. The errors
you were getting could easily go back to a failed open.
> Changing the line
>
> my $fh;
>
> to read
>
> my $fh="";
>
> cured the error messages but NOW.... when the inner file is read, and
> the routine printit returns to its caller, we get EOF immediately on
> the outer file read loop and so the remaining lines in the file
> include.txt are not printed.
"open $fh, ..." works radically different depending on whether $fh
has a defined value at the moment.
If it hasn't (your original case), an anonymous filehandle (well,
not quite anonymous, but rather symbolic) is created somewhere, and
a globref to this filehandle is placed into $fh. Using this in
I/O-related functions works as if the original filehandle was used,
which is magical (and violates the principle that Perl doesn't
de-reference things for you). This creates a new filehandle
each time you use it, and the only way to access it is through
the globref.
If $fh has a defined value, this is taken as a string value and a
filehandle *of that name* is used. This is called "indirect
filehandle", and it is also magical. Unlike the other case, the
same filehandle is accessed whenever $fh holds this particular
string (and yes, "" is a valid filehandle name here), so if you
call another open, the file previously opened is closed.
> I am confused about this because $fh is a locally-scoped variable and
> should therefore be preserved on the stack frame of printit. And
> indeed it does seem to be, unless it is initialised. But in theory,
> initialising $fh in the inner stack frame cannot possibly alter the
> outer stack frame copy.
No, but it can access the filehandle "", close it, and open it to
another file.
[snippage]
> And there is more weirdness yet. If I print $fh after the open it
> prints GLOB(0xnnnnn) where nnnnn is a hex address. And this number is
> different for the inner and outer calls, as you would expect. But if I
> assign $fh="xyz" before the open, then after the open, $fh still
> prints as "xyz" but the while(<$fh>) loop does read correctly (albeit
> that we get the problem referred to earlier when we return from the
> loop to the caller). How is this possible?. It is as if perl is
> binding <$fh> earlier in time to the assignment.
Quite. You're using a good old-fashioned indirect filehandle. The
binding isn't "earlier" it is simply the *same* filehandle every
time. After "$fh = 'xyz'; open $fh, ...;" you could even use the
filehandle directly and do "while ( <xyz> ) {" synonymously with
"while ( <$fh> ) {".
Anno
------------------------------
Date: 24 Jul 2001 08:50:35 -0700
From: rckjr@yahoo.com (Rick Kasten)
Subject: How Can I Run Command Line and Perl from the Same File?
Message-Id: <4ecf6f35.0107240750.6750c95e@posting.google.com>
I saw somewhere once where someone figured out how to run command-line
commands and perl commands _from within the same file_. It was a .CMD
file on NT. All I can remember is that it started with CMD lines,
switched to perl (the bulk of the script), and finished with CMD. I
think the sections were separated by some % symbols...
I know this sounds strange, but believe me, this is NOT XML, WSF or
multiple perl commands redirected to a file that was executed later on
in the script. It was true batch commands and true perl scripting.
Anything you can do to help would be great.
btw, I know about pl2bat, but I want one solution that will work for
all of my servers. My many configurations would require multiple
pl2bat scripts, and that kind of defeats the purpose...
Rick
------------------------------
Date: Tue, 24 Jul 2001 09:06:05 -0700
From: Jeff Zucker <jeff@vpservices.com>
Subject: Re: How Can I Run Command Line and Perl from the Same File?
Message-Id: <3B5D9CED.7322D9A3@vpservices.com>
Rick Kasten wrote:
>
> btw, I know about pl2bat, but I want one solution that will work for
> all of my servers. My many configurations would require multiple
> pl2bat scripts, and that kind of defeats the purpose...
I don't follow this. If you have a foo.pl that works as a perl script
on machines A,B,C,D and you run pl2bat on machine A producing foo.bat
and then copy foo.bat to machines B, C, D, in what way does the
configuration of A,B,C,D enter in?
--
Jeff
------------------------------
Date: Tue, 24 Jul 2001 17:14:32 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: How Can I Run Command Line and Perl from the Same File?
Message-Id: <u5brltg3njp665j7ealnj0fq3qsdl6rnnb@4ax.com>
Rick Kasten wrote:
>I saw somewhere once where someone figured out how to run command-line
>commands and perl commands _from within the same file_. It was a .CMD
>file on NT. All I can remember is that it started with CMD lines,
>switched to perl (the bulk of the script), and finished with CMD. I
>think the sections were separated by some % symbols...
>btw, I know about pl2bat, but I want one solution that will work for
>all of my servers.
Look at what pl2bat produces. It's probably close to what you want. In
short: use the -x switch to make perl scan for the "#!... perl" line,
and "__END__" to end the script; and make the batch interpreter jump
over the script. See more info in perlrun.
--
Bart.
------------------------------
Date: Tue, 24 Jul 2001 17:13:55 +0200
From: Bjoern Hoehrmann <bjoern@hoehrmann.de>
Subject: Re: How to convert Pc/Unix characterset (ISO-lat1) to the Mac character set
Message-Id: <3b627727.4185498@news.bjoern.hoehrmann.de>
* Louis Banens wrote in comp.lang.perl.misc:
>Can anybody tell me how to convert Pc/Unix characterset (ISO-lat1) to the
>Mac character set. We have problems with extende characters uploaded from a
>Mac to a PC/Unix system. Are there any perl routines available for this.
Try Text::Iconv or Unicode::Map8.
--
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/
------------------------------
Date: 24 Jul 2001 17:00:26 +0200
From: elwood@news.agouros.de (Konstantinos Agouros)
Subject: IO::Socket-Question
Message-Id: <elwood.995986739@news.agouros.de>
Hi,
I wrote an application that uses IO::Socket::Inet to connect to a server. This
server seems to be buggy and lock up. However this gets me with an
print $sock "something" where my perl-process locks up. I tried setting $sock->
timeout but this didn't help. Do I really have to go to select and everything?
Konstantin
--
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: elwood@agouros.de
Otkerstr. 28, 81547 Muenchen, Germany. Tel +49 89 69370185
----------------------------------------------------------------------------
"Captain, this ship will not sustain the forming of the cosmos." B'Elana Torres
------------------------------
Date: Tue, 24 Jul 2001 18:44:51 +0200
From: Buggs <buggs-clpm@splashground.de>
Subject: Re: IO::Socket-Question
Message-Id: <9jk8cq$u6i$06$1@news.t-online.com>
Konstantinos Agouros wrote:
> Hi,
>
> I wrote an application that uses IO::Socket::Inet to connect to a server.
> This server seems to be buggy and lock up. However this gets me with an
> print $sock "something" where my perl-process locks up. I tried setting
> $sock-> timeout but this didn't help. Do I really have to go to select and
> everything?
>
> Konstantin
You migth have to avoid buffering.
Keywords
autoflush ,flushing, $| , syswrite
perldoc perlipc
You may also consider posting a short programm,
which demonstrates the behavior.
Buggs
------------------------------
Date: Tue, 24 Jul 2001 11:09:28 -0500
From: "Curtis Hawthorne" <curtish@ourtownusa.net>
Subject: mod_perl for NT
Message-Id: <03h77.4048$fo2.1078@newsfeed.slurp.net>
Is there an equivalent to mod_perl for Windows NT 4.0 and IIS 4.0?
Thanks!
Curtis H.
------------------------------
Date: Tue, 24 Jul 2001 16:56:52 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: mod_perl for NT
Message-Id: <gn9rltk8qo916ab9nv1l719pv4pa1sm8qc@4ax.com>
Curtis Hawthorne wrote:
>Is there an equivalent to mod_perl for Windows NT 4.0 and IIS 4.0?
There is a mod_perl for NT. Just not for IIS.
And look into ActiveState's PerlIIS. Er... here?
<http://www.iisanswers.com/Top10FAQ/t10-installperl.htm>
And maybe into PerlEx as well (although I don't know the product
myself):
<http://aspn.activestate.com/ASPN/Perl/Reference/Products/PerlEx/Welcome.html>
--
Bart.
------------------------------
Date: Tue, 24 Jul 2001 11:24:09 -0400
From: "Bruce McArdle" <bruce.g.mcardle_remove@intel.com>
Subject: Re: nested forks - help....
Message-Id: <9jk3v1$gab@news.or.intel.com>
Can I ask how you do process cleanup in this situation?
I'm having problems with 1 process. I'm trying to have perl fork a system
"sleep 1; someprogram; if ..."
and later perl can kill all the sub programs if needed.
It seems that with multiple arguments to system, perl forks "sh". If I then
try to kill the child PID, sh dies, but the sub processes keep running - not
a desired thing in this case.
I've tried putting this in my term handler:
# trap the term signal, so we can kill our children processes
use POSIX ":sys_wait_h";
$SIG{TERM} = sub{reaper()};
$SIG{INT} = sub{reaper()};
$SIG{QUIT} = sub{reaper()};
sub reaper{
$debug && print "reaper: subprocess id $kidpid\n";
if ($kidpid) {
$debug && print "trying to kill child pid $kidpid\n";
kill 'TERM', $kidpid;
# kill -'TERM', $kidpid;
# system "/bin/kill -TERM $kidpid";
}
} #sub reaper
The last 2 kills should kill the process group, but maybe this isn't
supported on hpux 10.20?
my fork routine is:
sub fork_process {
my $exec_line = $_[0];
# fork the sub process
if (!defined($kidpid = fork())) {
# fork returned undef, so failed
die "ERROR: cannot fork: $!";
} elsif ($kidpid == 0) {
# fork returned 0, so this branch is the child
print "trying to fork $exec_line\n";
exec("$exec_line");
# if the exec fails, fall through to the next statement
die "ERROR: can't exec: $!";
} else {
print "child process id: $kidpid\n";
# fork returned neither 0 nor undef, so this branch is the parent
waitpid $kidpid,0;
$debug && print "child returned: $?\n";
}
$kidpid = 0;
return $?;
} #sub fork_process
thanks for any perl insight.
Bruce
"Elias_Haddad" <Elias_Haddad@tertio.com> wrote in message
news:OF41DF5F54.FBA09438-ON80256A92.00395CF7@tertio.com...
> Hi all,
>
> Any help will be much appreciated on the subject.
> I am writing an application whereby I would like to fork a few processes,
> and in these forked processes, fork additionnal processes without any of
> the parent processes to have to wait for their children to finish. It is
> something of the form:
>
> foreach $customer (@customers) {
> if ($cust_pid = fork) { #in parent
> sleep 1;
> $SIG{CHLD} = 'IGNORE';
> }
> if ($cust_pid == 0) { #in child
> foreach $router (@routers) {
> if ($router_pid = fork) { #in parent
> sleep 1;
> $SIG{CHLD} = 'IGNORE';
> }
> if ($router_pid == 0) { #in child
> #do something, main application here
> exit; #this exits child process at router level
> }
> }
> }
> exit; #this exits child process at customer level
> }
>
> So basically, what I am trying to do is for each customer in my list of
> customers, fork a process, and then for each router owned by that
customer,
> fork another process and this is where my main application takes place, at
> router level. I think what I have here are nested forks.
> My probelm is that my application is giving me really strange results when
> I have nested forks. Perl seems to be confusing which child belongs to
> which parent or something of the kind. The reason I am saying this is
> because when I test my code without the forking at customer level, just at
> router level, it works perfectly. More over, when I replace $SIG{CHLD}
> = 'IGNORE'; with waitpid($cust_pid, 0); at the customer level forking (ie
> make the parent process wait for its child process to terminate before
> beginning a new one), the code works perfectly as well. I need though to
> have all these processes run concurrently and hence I do not want to use
> the waitpid($cust_pid, 0); solution.
> Any help on possible alternative ways will be VERY appreciated as I am
> writing this application for a customer.
>
> Thanks in advance,
> Elias.
>
> PS: if you're interested by what kind of application I am writing, it's
> basically a polling engine that monitors some remote site routers via an
> ISDN link, and the polls are made from central site routers via the cisco
> ping mib. In order to do the polling, I am using Net::SNMP module. Just
> thought you might want to know.
>
>
> Tertio Limited - One Angel Square, Torrens Street, London EC1V 1PL
> Tel: +44 (0)20 7843 4000 Fax: +44 (0)20 7843 4001 Web
http://www.tertio.com
> Any views expressed in this message are those of the individual sender,
> except where the sender specifically states them to be the views of Tertio
> Ltd.
>
>
>
> --
> Posted from [212.250.216.229]
> via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
Date: Tue, 24 Jul 2001 11:48:31 -0400
From: Joshua Sunshine <sunshinj@mail.nih.gov>
Subject: Re: Newbie problem: if(<STDIN> =~ /^[yY]/) control structure returns true if i type y-How
Message-Id: <3B5D98CF.7A7B399B@mail.nih.gov>
prabu wrote:
> Hello Geeks,
>
> I'm a perl newbie.I'm using llama book to learn.In the perl regular
> expressions unit i learnt that "^" is a negation operator.--pg.79 in
> 2nd edition
> Then in pg 85 i foud the above control structure
> " if (<STDIN>=~ /[^yY]/) "
> returns true as return value if i type anything starting with y or Y.
>
> From my earlier understanding "^" means negation operator.So how come
> looking(seraching) for a non yY character in my <STDIN> returns true
> if i type yY.
> from my understanding this should be otherway...
>
> Can some one pls.explain on this issue.I belive my understanding is
> wrong somewhere.Pls. help to correct me.
The "^" operator has two different meanings depending on the context.
Within a regular expression (surrounded by "//"), the "^" operator
searches the beginning of a string. For example if I attach the "^"
operator to a regular expression searching for the letter y or Y.
"Yellow" and "yellow" will return true, but "grey" or "greY" will not.
In all other contexts the "^" is the negation operator.
------------------------------
Date: Tue, 24 Jul 2001 18:01:58 -0000
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Newbie problem: if(<STDIN> =~ /^[yY]/) control structure returns true if i type y-How
Message-Id: <tlre0m66247a25@corp.supernews.com>
prabu (prabuanand@excite.com) wrote:
: I'm a perl newbie.I'm using llama book to learn.In the perl regular
: expressions unit i learnt that "^" is a negation operator.--pg.79 in
: 2nd edition
More specifically, as the first character inside a character class
specifier, it negates that class.
: Then in pg 85 i found the above control structure
: " if (<STDIN>=~ /[^yY]/) "
: returns true as return value if i type anything starting with y or Y.
: From my earlier understanding "^" means negation operator.So how come
: looking(seraching) for a non yY character in my <STDIN> returns true
: if i type yY.
: from my understanding this should be otherway...
:
: Can some one pls.explain on this issue.I belive my understanding is
: wrong somewhere.Pls. help to correct me.
It certainly is. Rather than telling you directly, here's a clue: What
does
print length <STDIN>;
output when you enter Y and then hit enter?
--
| Craig Berry - http://www.cinenet.net/~cberry/
--*-- "Brute force done fast enough looks slick."
| - William Purves
------------------------------
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 1369
***************************************
