[26147] in Perl-Users-Digest
Perl-Users Digest, Issue: 8338 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 19 11:05:31 2005
Date: Fri, 19 Aug 2005 08:05:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 19 Aug 2005 Volume: 10 Number: 8338
Today's topics:
Re: debian rename <tadmc@augustmail.com>
Re: debian rename <tadmc@augustmail.com>
Re: debian rename <bernard.el-haginDODGE_THIS@lido-tech.net>
Re: How to detect a dead parent? <vek@station02.ohout.pharmapartners.nl>
Re: How to detect a dead parent? <ntrenholm@gmail.com>
Re: How to detect a dead parent? <markm@chiark.greenend.org.uk>
Re: How to detect a dead parent? <markm@chiark.greenend.org.uk>
Re: How to detect a dead parent? <markm@chiark.greenend.org.uk>
Re: How to detect a dead parent? <markm@chiark.greenend.org.uk>
Re: How to emulate the Unix command "which" chris-usenet@roaima.co.uk
Re: How to emulate the Unix command "which" axel@white-eagle.invalid.uk
Re: How to emulate the Unix command "which" <nospam-abuse@ilyaz.org>
Re: How to emulate the Unix command "which" <nabotleon@hotmail_N0_SPAMZ.com>
Re: How to emulate the Unix command "which" <1usa@llenroc.ude.invalid>
Re: How to emulate the Unix command "which" usenet@isbd.co.uk
Re: How to emulate the Unix command "which" axel@white-eagle.invalid.uk
Re: How to emulate the Unix command "which" <1usa@llenroc.ude.invalid>
Re: How to emulate the Unix command "which" <someone@example.com>
Re: How to emulate the Unix command "which" chris-usenet@roaima.co.uk
Re: Listing Folders with Net::IMAP chris-usenet@roaima.co.uk
Parse::RecDescent and unordered rules <trondmm-usenet@crusaders.no>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 19 Aug 2005 07:04:01 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: debian rename
Message-Id: <slrndgbilh.vnc.tadmc@magna.augustmail.com>
Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> Shane <shane@weasel.is-a-geek.net> wrote in comp.lang.perl.misc:
>> thanks.. I should of done the same
>
> "Should of"?
That is one of the Pinocchio/Jsut troll's foibles...
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 19 Aug 2005 08:02:27 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: debian rename
Message-Id: <slrndgbm33.vnc.tadmc@magna.augustmail.com>
Shane <shane@weasel.is-a-geek.net> wrote:
> for the benefit of the pedants..
Experienced Perl programmers already know about such problems, and
avoid them through common Best Practice.
Your followup up may well be of benefit to those new to Perl
programming though.
> the problem was a newline char
So then, if you had tried this code:
rename $old_name, $mail or die "Could not rename $old_name to $mail: $!";
You would have found the problem straightaway!
You might also have added checking of return values to your general
coding style, saving countless similar debugging debacles throughout
your entire career of programmming in Perl.
Why oh why didn't some kindly pedant volunteer their time to provide
you with such code?
If that had happened, this would have been a very much shorter thread...
> thanking you :-)
Yeah, right.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 19 Aug 2005 15:13:30 +0200
From: "Bernard El-Hagin" <bernard.el-haginDODGE_THIS@lido-tech.net>
Subject: Re: debian rename
Message-Id: <Xns96B79AE071FB3elhber1lidotechnet@62.89.127.66>
Tad McClellan <tadmc@augustmail.com> wrote:
[...]
> So then, if you had tried this code:
>
> rename $old_name, $mail or die "Could not rename $old_name to
> $mail: $!";
>
> You would have found the problem straightaway!
You mean "would of", you ol' pedant, you.
--
Cheers,
Bernard
------------------------------
Date: 19 Aug 2005 10:17:53 GMT
From: Villy Kruse <vek@station02.ohout.pharmapartners.nl>
Subject: Re: How to detect a dead parent?
Message-Id: <slrndgbceh.3li.vek@station02.ohout.pharmapartners.nl>
On 18 Aug 2005 21:19:08 +0100 (BST),
Mark Mackey <markm@chiark.greenend.org.uk> wrote:
>
> So, the question is, how can a child detect that its parent is dead? I
> tried using getppid() to test if the ppid had becore equal to 1 (which
> is what happens after the parent exits), but after frustrating hours of
> debugging I found a web page which pointed out the AFAIK undocumented
> fact that Perl caches the ppid on Linux and so will always return the
> same value in a script. Grrr. I also tried doing a kill 0 => getppid;,
> which works in theory but not in practice because the parent is uid 0
> and the children drop privileges, so the children aren't priviledged to
> signal the parent (even kill 0, which doesn't actually send a signal.
> Double Grrr.)
>
Take a look at Linux-Pid, available from CPAN.
As far as I can tell the problem occurs only if your perl runtime is compiled
with THREADS_HAVE_PIDS (perl -V), which was necessary because of a problem
in the original linux threads library.
Villy
------------------------------
Date: Fri, 19 Aug 2005 05:49:39 -0500
From: "N.Trenholm" <ntrenholm@gmail.com>
Subject: Re: How to detect a dead parent?
Message-Id: <vtadnRQByp7rJJjeRVn-jQ@centurytel.net>
"John W. Krahn" <someone@example.com> wrote in
> Anno Siegel wrote:
> > Bernard El-Hagin <bernard.el-haginDODGE_THIS@lido-tech.net> wrote in
> >>Mark Mackey <markm@chiark.greenend.org.uk> wrote:
> >>
> >>[...]
> >>
> >>>So, the question is, how can a child detect that its parent is
> >>>dead? [...]
> >>
> >>By the smell?
> >
> > That depends...
>
> Depends aren't large enough to cover a whole corpse.
>
Closures would be.
--
Neil
------------------------------
Date: 19 Aug 2005 15:47:07 +0100 (BST)
From: Mark Mackey <markm@chiark.greenend.org.uk>
Subject: Re: How to detect a dead parent?
Message-Id: <3Ek*6WxWq@news.chiark.greenend.org.uk>
In article <1gcft2-bl2.ln1@news.roaima.co.uk>, <chris@roaima.co.uk> wrote:
>Mark Mackey <markm@chiark.greenend.org.uk> wrote:
>> and the children drop privileges, so the children aren't priviledged to
>> signal the parent (even kill 0, which doesn't actually send a signal.
>
>You're talking UNIX/Linux?
Yes, sorry, I should have specified this.
>It is possible to use kill 0 to determine whether a process exists
>or not. You simply have to differentiate between a "No such process"
>error and a "Permission denied" error. (The latter indicates that the
>PID exists but you don't have permission to singal it.)
Argh. *FX: autothwap*. Of course, so simple. Many many thanks, this is
exactly what I needed but was too dense to think of.
--
Mark Mackey http://www.swallowtail.org/
bug bug bug bug bug bug bug bug bug bug bug bug bug code bug bug bug b
ug (C) Microsoft bug bug bug bug bug bug bug bug bug bug bug bug bug b
ug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug code bu
------------------------------
Date: 19 Aug 2005 15:49:24 +0100 (BST)
From: Mark Mackey <markm@chiark.greenend.org.uk>
Subject: Re: How to detect a dead parent?
Message-Id: <SKm*DXxWq@news.chiark.greenend.org.uk>
In article <de31d5$9ui$1@mamenchi.zrz.TU-Berlin.DE>,
Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
>
>Why don't you just keep the parent pid in a variable, or even
>
> use constant PPID => $$;
It's not getting the ppid that't the problem, it's detecting when it's
not there any more that I couldn't work out how to do.
> use Errno 'EPERM';
> if ( kill 0, PPID or $! == EPERM ) {
> # parent still alive
> }
As I mentioned elsewhere in the thread, this is exactly what I need and
was too dense to think of. Ta.
>An alternative way to monitor the lifetime of a particular process is
>to let it keep a lock on a file. Other processes can test for the
>existence of the lock. If the process goes, so does the lock.
I did think of this one, but it came under the heading of 'getting a bit
kludgy' in my mind :).
--
Mark Mackey http://www.swallowtail.org/
#define code bug
code code code code code code code code code code code code code code code co
de code code code code code code code code code code code code code code code
------------------------------
Date: 19 Aug 2005 16:00:34 +0100 (BST)
From: Mark Mackey <markm@chiark.greenend.org.uk>
Subject: Re: How to detect a dead parent?
Message-Id: <Yzw*e0xWq@news.chiark.greenend.org.uk>
In article <Xns96B75BABE447Celhber1lidotechnet@62.89.127.66>,
Bernard El-Hagin <bernard.el-haginDODGE_THIS@lido-tech.net> wrote:
>Mark Mackey <markm@chiark.greenend.org.uk> wrote:
>> So, the question is, how can a child detect that its parent is
>> dead? [...]
>
>By the smell?
I do sometimes get worried that a future employer will do a Google
search on my name and throw up posts with me talking about killing
children. Not good for the career prospects, that :)
--
Mark Mackey http://www.swallowtail.org/
code code code code code code code code code code code code code bug code co
de code code code bug code code code code code code code code code code code
code code code code code code code code code code code code code code code c
------------------------------
Date: 19 Aug 2005 15:55:32 +0100 (BST)
From: Mark Mackey <markm@chiark.greenend.org.uk>
Subject: Re: How to detect a dead parent?
Message-Id: <uNs*5YxWq@news.chiark.greenend.org.uk>
In article <slrndgbceh.3li.vek@station02.ohout.pharmapartners.nl>,
Villy Kruse <nobody> wrote:
>
>Take a look at Linux-Pid, available from CPAN.
As I said in my original post, I need to install this stuff on machines
for which random CPAN modules are a problem (and it uses Inline, which
is (a) beta, and (b) needs a C compiler installed).
>As far as I can tell the problem occurs only if your perl runtime is compiled
>with THREADS_HAVE_PIDS (perl -V), which was necessary because of a problem
>in the original linux threads library.
The solution seems to have caused another problem :).
--
Mark Mackey http://www.swallowtail.org/
code code fnord code code code code code code code code code code bug code c
ode code code code bug code code code code code code code code fnord code co
de code code code code code code fnord code code code code code code code co
------------------------------
Date: Fri, 19 Aug 2005 11:05:57 +0100
From: chris-usenet@roaima.co.uk
Subject: Re: How to emulate the Unix command "which"
Message-Id: <5hngt2-2eu.ln1@news.roaima.co.uk>
Leon Nabot <nabotleon@hotmail_n0_spamz.com> wrote:
> I try to find a quick solution to find onto the PATH where is located an
> executable as "which" do.
> For the moment the only solution seems to write a module which browse
> each directory of the PATH searching the file.
A quick way for a single command is:
foreach (split(/:/,$ENV{PATH})) { print "Found $_/rsh\n" if -x "$_/rsh" }
Or, if you want a fancier version:
my %what = (
ls => undef,
rsh => undef,
rfc => undef,
);
foreach my $path (reverse split (/:/, $ENV{PATH})) {
$path = '.' if $path eq '';
foreach my $cmd (keys %what) {
my $file = "$path/$cmd";
$what{$cmd} = $file if -x $file;
}
}
use Data::Dumper;
print Dumper (\%what), ".\n";
Chris
------------------------------
Date: Fri, 19 Aug 2005 11:00:21 GMT
From: axel@white-eagle.invalid.uk
Subject: Re: How to emulate the Unix command "which"
Message-Id: <9ZiNe.1001$5m3.808@fe1.news.blueyonder.co.uk>
Leon Nabot <nabotleon@hotmail_n0_spamz.com> wrote:
> I try to find a quick solution to find onto the PATH where is located an
> executable as "which" do.
> I have tried to use the "which" command into a pipe or backtick but the
> returns are not the same in all Unixes, in particular if the searched
> command is aliased, .
How are you specifying 'which' - in other words, which 'which' are
you using. It can appear as a shell built in command in tcsh which
will pick up aliases. However the standalone version (maybe
/usr/bin/which depending on your system) will not pick up aliases.
Axel
------------------------------
Date: Fri, 19 Aug 2005 11:54:25 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: How to emulate the Unix command "which"
Message-Id: <de4h9h$203c$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
<chris@roaima.co.uk>], who wrote in article <5hngt2-2eu.ln1@news.roaima.co.uk>:
> Leon Nabot <nabotleon@hotmail_n0_spamz.com> wrote:
> > I try to find a quick solution to find onto the PATH where is located an
> > executable as "which" do.
>
> > For the moment the only solution seems to write a module which browse
> > each directory of the PATH searching the file.
>
> A quick way for a single command is:
>
> foreach (split(/:/,$ENV{PATH})) { print "Found $_/rsh\n" if -x "$_/rsh" }
Splitting PATH on /:/ is wrong. Use $Config{path_sep} instead.
Hope this helps,
Ilya
------------------------------
Date: Fri, 19 Aug 2005 14:18:42 +0200
From: Leon Nabot <nabotleon@hotmail_N0_SPAMZ.com>
Subject: Re: How to emulate the Unix command "which"
Message-Id: <4305ce66$0$4171$636a15ce@news.free.fr>
Thank's to all.
The solution suggested by Chris is just good for me (One line of code)
I give up the use of the system "which" command because it seems that on
Solaris even the standalone version reports the alias (When in Linux and
HPUX it reports the real path)
Rgds.
Léo
> Hello,
>
> I try to find a quick solution to find onto the PATH where is located an
> executable as "which" do.
>
> I have tried to use the "which" command into a pipe or backtick but the
> returns are not the same in all Unixes, in particular if the searched
> command is aliased, .
------------------------------
Date: Fri, 19 Aug 2005 12:38:52 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: How to emulate the Unix command "which"
Message-Id: <Xns96B757F5C933Dasu1cornelledu@127.0.0.1>
Leon Nabot <nabotleon@hotmail_N0_SPAMZ.com> wrote in news:4305ce66$0
$4171$636a15ce@news.free.fr:
[ Please do not top-post.
Please quote the article you are replying to.
]
> The solution suggested by Chris is just good for me (One line of code)
Is that really a good criterion?
Let's review the solution:
> chris-usenet@roaima.co.uk wrote in
> news:5hngt2-2eu.ln1@news.roaima.co.uk:
>
>> A quick way for a single command is:
>>
>> foreach (split(/:/,$ENV{PATH})) { print "Found $_/rsh\n" if -x
>> "$_/rsh" }
This, IMHO, is needlessly platform dependent. One can make this fairly
portable by using File::Spec:
#!/usr/bin/perl
use strict;
use warnings;
use File::Spec::Functions qw'catfile path';
use constant LOOK_FOR => shift;
unless( LOOK_FOR ) {
die "Please provide the name of the command you want to find\n";
}
my @path = path;
for my $dir ( @path ) {
my $fn = catfile $dir, LOOK_FOR;
print "Found $fn\n" if -x $fn;
}
__END__
D:\Home\asu1\UseNet\clpmisc> mywhich perl.exe
Found C:\opt\Perl\bin\perl.exe
Found C:\opt\cygwin\bin\perl.exe
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: 19 Aug 2005 12:41:22 GMT
From: usenet@isbd.co.uk
Subject: Re: How to emulate the Unix command "which"
Message-Id: <3mm2biF17ldhhU1@individual.net>
Leon Nabot <nabotleon@hotmail_n0_spamz.com> wrote:
>
> Thank's to all.
>
> The solution suggested by Chris is just good for me (One line of code)
>
> I give up the use of the system "which" command because it seems that on
> Solaris even the standalone version reports the alias (When in Linux and
> HPUX it reports the real path)
>
Yes, I think the standalone 'which' on Solaris does wierd things like
looking at what shell you are running and then trying to parse the
relevant files to find aliases as well as actual executables on the
PATH.
--
Chris Green
------------------------------
Date: Fri, 19 Aug 2005 12:56:37 GMT
From: axel@white-eagle.invalid.uk
Subject: Re: How to emulate the Unix command "which"
Message-Id: <9GkNe.6860$Il.1987@fe2.news.blueyonder.co.uk>
A. Sinan Unur <1usa@llenroc.ude.invalid> wrote:
>>> A quick way for a single command is:
>>> foreach (split(/:/,$ENV{PATH})) { print "Found $_/rsh\n" if -x
>>> "$_/rsh" }
> This, IMHO, is needlessly platform dependent. One can make this fairly
> portable by using File::Spec:
> #!/usr/bin/perl
> use strict;
> use warnings;
> use File::Spec::Functions qw'catfile path';
> use constant LOOK_FOR => shift;
Why do you use this form rather than a normal variable?
Axel
------------------------------
Date: Fri, 19 Aug 2005 13:20:25 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: How to emulate the Unix command "which"
Message-Id: <Xns96B75F0094FC7asu1cornelledu@127.0.0.1>
axel@white-eagle.invalid.uk wrote in
news:9GkNe.6860$Il.1987@fe2.news.blueyonder.co.uk:
> A. Sinan Unur <1usa@llenroc.ude.invalid> wrote:
>>>> A quick way for a single command is:
>
>>>> foreach (split(/:/,$ENV{PATH})) { print "Found $_/rsh\n" if -x
>>>> "$_/rsh" }
>
>> This, IMHO, is needlessly platform dependent. One can make this
>> fairly portable by using File::Spec:
>
>> #!/usr/bin/perl
>
>> use strict;
>> use warnings;
>
>> use File::Spec::Functions qw'catfile path';
>
>> use constant LOOK_FOR => shift;
>
> Why do you use this form rather than a normal variable?
For variety :)
Actually, to match the way the command line argument is used in the
script: It is a value given from the outside which the script will not
modify.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Fri, 19 Aug 2005 13:33:44 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: How to emulate the Unix command "which"
Message-Id: <YclNe.195298$HI.191471@edtnps84>
Ilya Zakharevich wrote:
> [A complimentary Cc of this posting was sent to
>
> <chris@roaima.co.uk>], who wrote in article <5hngt2-2eu.ln1@news.roaima.co.uk>:
>>Leon Nabot <nabotleon@hotmail_n0_spamz.com> wrote:
>>>I try to find a quick solution to find onto the PATH where is located an
>>>executable as "which" do.
>>>For the moment the only solution seems to write a module which browse
>>>each directory of the PATH searching the file.
>>A quick way for a single command is:
>>
>> foreach (split(/:/,$ENV{PATH})) { print "Found $_/rsh\n" if -x "$_/rsh" }
>
> Splitting PATH on /:/ is wrong. Use $Config{path_sep} instead.
Or:
use Env '@PATH';
John
--
use Perl;
program
fulfillment
------------------------------
Date: Fri, 19 Aug 2005 14:28:09 +0100
From: chris-usenet@roaima.co.uk
Subject: Re: How to emulate the Unix command "which"
Message-Id: <9c3ht2-347.ln1@news.roaima.co.uk>
Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> [A complimentary Cc of this posting was sent to <chris@roaima.co.uk>]
No thanks. This is usenet.
>> A quick way for a single command is:
>> foreach (split(/:/,$ENV{PATH})) { print "Found $_/rsh\n" if -x "$_/rsh" }
> Splitting PATH on /:/ is wrong. Use $Config{path_sep} instead.
I did say it was a quick way.
To anyone else reading this thread, don't forget you'll need "use Config"
to populate the %Config hash values.
Chris
------------------------------
Date: Fri, 19 Aug 2005 10:48:13 +0100
From: chris-usenet@roaima.co.uk
Subject: Re: Listing Folders with Net::IMAP
Message-Id: <tfmgt2-2eu.ln1@news.roaima.co.uk>
Jon <jon@watcher.net.nz> wrote:
> I'm trying to write an IMAP Webmail Client using Net::IMAP and am having
> problems getting a list of IMAP folders.
> Is anybody able to point me in the right direction?
You need to provide a callback (set_untagged_callback) to process
the "list" that the IMAP server produces when you ask for the set of
folders. (The whole process is somewhat asynchronous.)
sub suc_list { print 'Callback (list): ', Dumper(@_), ".\n"; }
$imap->set_untagged_callback ('list', \&suc_list);
$imap->list ('', '%');
The value you get back from $imap->list helps you identify the items
passed to the callback.
Chris
------------------------------
Date: Fri, 19 Aug 2005 15:56:53 +0200
From: Trond Michelsen <trondmm-usenet@crusaders.no>
Subject: Parse::RecDescent and unordered rules
Message-Id: <3mm6p5F174ga4U1@individual.net>
Hi.
I'm completely new to Parse::RecDescent and parsing in general (I know
my regexes, though). I'm trying to write a parser to read a config-file,
and I've managed to rules for all the relevant parts of the config-file,
and everything seems to work fine. But, there are several parts of the
config-file where the order doesn't (well, shouldn't) matter, and I was
wondering if there is a simple way to tell Parse::RecDescent that the
order of these rules doesn't matter?
Here's an example:
alphanum: /[A-Za-z0-9_]/
word: alphanum(s)
name: 'NAME' word
rank: 'RANK' word
description: 'DESCRIPTION' word
example: name rank description(?)
So, with this grammar, the following would match:
NAME foo
RANK bar
DESCRIPTION baz
but this wouldn't
RANK bar
NAME foo
DESCRIPTION baz
I know I can just expand the rule to include all combinations, like this:
example: name rank description(?) |
name description rank |
rank name description(?) |
rank description name |
description name rank |
description rank name
but this seems silly. Besides, the real grammar is slightly more complex
too, so I'm not sure it's maintainable in the long run.
So, is it possible to tell Parse::RecDescent that a particular group of
rules are allowed in any order, or is there a better way to solve this?
(or should I simply tell my users that order is important, and they'd
better get used to it :)
--
Trond Michelsen
------------------------------
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 8338
***************************************
