[31399] in Perl-Users-Digest
Perl-Users Digest, Issue: 2651 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 26 11:09:41 2009
Date: Mon, 26 Oct 2009 08:09:07 -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 Mon, 26 Oct 2009 Volume: 11 Number: 2651
Today's topics:
Re: 6 images in tile format(google maps) <tadmc@seesig.invalid>
Re: 6 images in tile format(google maps) <ben@morrow.me.uk>
Re: FAQ 4.74 How do I print out or copy a recursive dat <marc.girod@gmail.com>
Re: File locking using threads <timothy.hill@gmail.com>
Re: File locking using threads <ben@morrow.me.uk>
math:trig - is there a Lenny package <john1949@yahoo.com>
Re: math:trig - is there a Lenny package (Alan Curry)
Re: math:trig - is there a Lenny package <john1949@yahoo.com>
Perl bioinformatics <cartercc@gmail.com>
Re: Perl bioinformatics <jurgenex@hotmail.com>
Re: Perl bioinformatics (Bradley K. Sherman)
Re: Perl bioinformatics (Bradley K. Sherman)
Re: Shifting error codes (Alan Curry)
Re: Shifting error codes <ben@morrow.me.uk>
Re: Shifting error codes (Alan Curry)
Re: Shifting error codes <ben@morrow.me.uk>
Re: Shifting error codes (Alan Curry)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 25 Oct 2009 19:32:03 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: 6 images in tile format(google maps)
Message-Id: <slrnhe9rfe.in7.tadmc@tadmc30.sbcglobal.net>
Dwayne Triffitt <dwayne.triffitt@gmail.com> wrote:
> #!/usr/local/bin/perl -w
^^
^^
[snip]
> use warnings;
Lose the switch and keep the pragma, no need for both.
(I don't even know what happens when they're both used, are warnings
lexical or global in that case?
)
> my $icon = $mw->Photo(-file=>'marker.png');
^^
Why no whitespace around operators here...
> my $c1 = $mw->Canvas(-width => 768, -height => 768,
^^^^
... and yes whitespace around operators here?
You should choose one style and use it consistently.
> b-cos my images are 256x256
what kind of cosine is a b-cosine?
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Mon, 26 Oct 2009 01:36:44 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: 6 images in tile format(google maps)
Message-Id: <c2bfr6-tme1.ln1@osiris.mauzo.dyndns.org>
Quoth Tad J McClellan <tadmc@seesig.invalid>:
> Dwayne Triffitt <dwayne.triffitt@gmail.com> wrote:
>
> > #!/usr/local/bin/perl -w
> ^^
> ^^
> [snip]
> > use warnings;
>
>
> Lose the switch and keep the pragma, no need for both.
>
> (I don't even know what happens when they're both used, are warnings
> lexical or global in that case?
> )
-w turns on warnings globally, but any code under the control of 'use
warnings' or 'no warnings' will ignore -w (and $^W, of course). See
perllexwarn for the full details, and for the -W and -X switches.
Ben
------------------------------
Date: Mon, 26 Oct 2009 07:00:15 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: FAQ 4.74 How do I print out or copy a recursive data structure?
Message-Id: <53ff71f9-854f-44e8-8f52-edc472bd3685@l33g2000vbi.googlegroups.com>
On Oct 26, 10:00=A0am, PerlFAQ Server <br...@theperlreview.com> wrote:
> =A0 =A0 The "Data::Dumper" module on CPAN (or the 5.005 release of Perl) =
is
> =A0 =A0 great for printing out data structures. The "Storable" module on =
CPAN
> =A0 =A0 (or the 5.8 release of Perl), provides a function called "dclone"=
that
> =A0 =A0 recursively copies its argument.
Er... I don't remember the details, but I
wasn't happy with the processing of file
descriptors (as part of a hash) by the
various cloning techniques (add Clone to
them...)
Some (I don't remember which) will create
a new fd, with an incremented number, not
bound to anything.
Not very useful imho. Agreed: hard to tell
what is a one-size-fit-all behaviour, but
"do something silently" and "debugging
will tell" is maybe not optimal.
Marc
------------------------------
Date: Sun, 25 Oct 2009 15:34:27 -0700 (PDT)
From: Prince Al <timothy.hill@gmail.com>
Subject: Re: File locking using threads
Message-Id: <4e9f66d8-cbfd-43ad-8b8d-aef195f0b903@l33g2000vbi.googlegroups.com>
On Oct 25, 9:21=A0pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> S**t happens;-) But what is actually the "same result"?
When I run the script, I get:
Thread 1: acquired lock!
Thread 2: acquired lock!
Thread 2: released lock!
Thread 1: released lock!
Which is obviously wrong as Thread 1 should complete before Thread 2
can obtain the lock...
> And
> are you sure that your home directory isn't on a NFS mounted
> partition or that flock() on the system you're testing this
> on works with NFS partitons?
No, I am not sure. However, there is no man page for flock. I have
lockf however - is this the same/similar? From the man page, it seems
to do a similar job, although I'm not sure it helps me any...
------------------------------
Date: Sun, 25 Oct 2009 23:06:55 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: File locking using threads
Message-Id: <f92fr6-kqd1.ln1@osiris.mauzo.dyndns.org>
Quoth jt@toerring.de (Jens Thoms Toerring):
> Prince Al <timothy.hill@gmail.com> wrote:
> > Many thanks for the replies so far - very much appreciated! I tried
> > your various suggestions on my Linux machine and they worked like a
> > charm, however, moving this code onto the work servers did not prove
> > quite so fruitful... This are running Solaris (HP-UX B.11.11 U) and
> > given the way most things are at my company, configured incorrectly!
>
> Out of curiosity, How was it mis-configured not to let you get a
> lock on a file? The only thing I can think of at the moment is
> that the file to be locked is on an NFS mounted disk and the
> normal (non-Perl but POSIX) flock() function often does not
> work with NFS - and usually Perl's flock() function is based on
> POSIX's flock() function.
No, not quite. There are two possibibilities here: perl's flock is based
on a true BSD flock(2), and perl's flock is based on POSIX fcntl(2)
locks (either directly or because your system emulates flock with
fcntl). AFAIK the only way to tell which is to ktrace/strace/truss/
whatever a program like
perl -e'flock STDIN, 1'
and see which gets called. True (BSD) flock is not in POSIX.
If you are using BSD flock:
You will not be able to lock over the network.
Locks will be inherited by forked processes.
The kernel will not protect you against deadlock.
If you have two fds open on the same file, and you have a lock on
one, you will not be able to acquire a lock on the other (that is, a
process can hold a lock against itself, but only by using multiple
fds).
If you are using POSIX fcntl locks:
You may be able to lock over the network, if your network's set up
right.
Locks will not be inherited by forked processes.
The kernel will protect you against some (possibly all) deadlocks,
so you must be ready to handle the EDEADLK error.
If you have two fds open on the same file, and you have a lock on
one, you *will* be able to acquire a lock on the other; and
unlocking either will unlock both (a process cannot hold a lock
against itself, not even against a different thread).
Ben
------------------------------
Date: Mon, 26 Oct 2009 08:24:24 -0000
From: "John" <john1949@yahoo.com>
Subject: math:trig - is there a Lenny package
Message-Id: <hc3mbm$842$1@news.albasani.net>
Hi
Is there is Debian Lenny package for Math::Trig and Math::Complex?
I've looked I cannot find it.
I can get the source myself, I know, but the package would be nicer.
Regards
John
------------------------------
Date: Mon, 26 Oct 2009 08:48:54 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: math:trig - is there a Lenny package
Message-Id: <hc3npm$h4g$1@aioe.org>
In article <hc3mbm$842$1@news.albasani.net>, John <john1949@yahoo.com> wrote:
>Hi
>
>Is there is Debian Lenny package for Math::Trig and Math::Complex?
>
>I've looked I cannot find it.
As you can see from
http://packages.debian.org/file:Math/Trig.pm
http://packages.debian.org/file:Math/Complex.pm
both of those are included in the perl-modules package, which is part of the
standard package set. You'd have to do something really weird to get a Debian
installation without them.
--
Alan Curry
------------------------------
Date: Mon, 26 Oct 2009 09:17:57 -0000
From: "John" <john1949@yahoo.com>
Subject: Re: math:trig - is there a Lenny package
Message-Id: <hc3pg2$ch2$1@news.albasani.net>
"Alan Curry" <pacman@kosh.dhis.org> wrote in message
news:hc3npm$h4g$1@aioe.org...
> In article <hc3mbm$842$1@news.albasani.net>, John <john1949@yahoo.com>
> wrote:
>>Hi
>>
>>Is there is Debian Lenny package for Math::Trig and Math::Complex?
>>
>>I've looked I cannot find it.
>
> As you can see from
> http://packages.debian.org/file:Math/Trig.pm
> http://packages.debian.org/file:Math/Complex.pm
>
> both of those are included in the perl-modules package, which is part of
> the
> standard package set. You'd have to do something really weird to get a
> Debian
> installation without them.
>
> --
> Alan Curry
Hi
Many thanks. Fair enough. I didn't stop to think that they were part of
the standard package.
Regards
John
------------------------------
Date: Mon, 26 Oct 2009 07:17:18 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Perl bioinformatics
Message-Id: <0f055c16-6bca-4c4d-94d8-60510cdc7a27@e34g2000vbm.googlegroups.com>
I'm not changing jobs, but I've been contacted about some contract
opportunities that (reportedly) are difficult but seem easy enough to
me, manipulating genome files to produce various kinds of reports,
graphs, etc. I have zero experience in this, so I'm just wondering ...
1. What are the career opportunities in bioinformatics using Perl?
2. Looking for books, I found the following:
a. Beginning Perl for Bioinformatics by James Tisdall
b. Mastering Perl for Bioinformatics by James D. Tisdall
c. Building Bioinformatics Solutions: with Perl, R and MySQL by
Conrad Bessant**
d. Perl Programming for Biologists by D. Curtis Jamison
e. Genomic Perl: From Bioinformatics Basics to Working Code by Rex A.
Dwyer
Looking at the tables of contents, reviews, and reader comments, I
believe that c. is probably the best value, but it's real hard to tell
without buying and reading the book. Anybody have any experiences
using any of these books? I'd like to conserve both time and money by
starting with the 'best' book.
Thanks, CC.
------------------------------
Date: Mon, 26 Oct 2009 07:32:22 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bioinformatics
Message-Id: <c9cbe5dsmj9l5r0dcj7effhsmuotk00uqq@4ax.com>
ccc31807 <cartercc@gmail.com> wrote:
>I'm not changing jobs, but I've been contacted about some contract
>opportunities that (reportedly) are difficult but seem easy enough to
>me, manipulating genome files to produce various kinds of reports,
>graphs, etc. I have zero experience in this, so I'm just wondering ...
The usual problem is the huge volume of data that needs processing.
Therefore typically the standard algorithms don't work any more and you
need a really strong background in data processing.
Perl is not necessariy the best choice here. Perl's powerful features
make it easy to write code that seems to do the job, but it won't scale
from the small test samples to the huge actual data set where you really
need special methods and optimizations.
A little while ago there was someone posting questions here regularly
about how to deal with genom sequences. If don't know if he is still
around, but maybe you can check the archives and contact him.
jue
------------------------------
Date: Mon, 26 Oct 2009 14:39:31 +0000 (UTC)
From: bks@panix.com (Bradley K. Sherman)
Subject: Re: Perl bioinformatics
Message-Id: <hc4cb3$k95$1@reader1.panix.com>
In article <0f055c16-6bca-4c4d-94d8-60510cdc7a27@e34g2000vbm.googlegroups.com>,
ccc31807 <cartercc@gmail.com> wrote:
>
>Looking at the tables of contents, reviews, and reader comments, I
>believe that c. is probably the best value, but it's real hard to tell
>without buying and reading the book. Anybody have any experiences
>using any of these books? I'd like to conserve both time and money by
>starting with the 'best' book.
>
The 'best' book is the one that engages you. It's hard to
predict.
For $22.95 you can get access to *all* the O'Reilly books
<http://my.safaribooksonline.com/>
including several on bioinformatics. There's a free trial!
You might want to check the used book stores for a textbook like
_The Molecular Biology of the Gene_, so that you can pick up some
biology.
--bks
------------------------------
Date: Mon, 26 Oct 2009 14:45:01 +0000 (UTC)
From: bks@panix.com (Bradley K. Sherman)
Subject: Re: Perl bioinformatics
Message-Id: <hc4cld$k95$2@reader1.panix.com>
In article <c9cbe5dsmj9l5r0dcj7effhsmuotk00uqq@4ax.com>,
Jürgen Exner <jurgenex@hotmail.com> wrote:
> ...
>The usual problem is the huge volume of data that needs processing.
>Therefore typically the standard algorithms don't work any more and you
>need a really strong background in data processing.
>Perl is not necessariy the best choice here. Perl's powerful features
>make it easy to write code that seems to do the job, but it won't scale
>from the small test samples to the huge actual data set where you really
>need special methods and optimizations.
> ...
This is not really fair. Most of bioinformatics is data wrangling
and Perl is exactly the right choice for that.
See, e.g.
<http://www.foo.be/docs/tpj/issues/vol1_2/tpj0102-0001.html>
--bks
------------------------------
Date: Sun, 25 Oct 2009 22:15:42 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: Shifting error codes
Message-Id: <hc2ime$cd0$1@aioe.org>
In article <7kjuhtF3a3gtfU1@mid.uni-berlin.de>,
Jens Thoms Toerring <jt@toerring.de> wrote:
>Marc Girod <marc.girod@gmail.com> wrote:
>
>As long as you can guarantee that the result isn't larger
>than 255 it's ok, otherwise things won't work as expected.
>
>> or only rightwards codes received from sub-processes?
>
>Sorry, but I don't understand what's meant by this.
He means the return value from perl's system(). perlfunc says:
The return value is the exit status of the program as returned
by the "wait" call. To get the actual exit value, shift right
by eight (see below).
I assume that this evil magic number is a leftover from perl's early years
when there were no modules, and no easy way to make the system's WIFEXITED,
WEXITSTATUS, and related macros available inside a perl script. Does anybody
know what might happen if you compiled perl on a POSIX system that didn't use
the same bit layout for an exit status? Would it translate the status code,
possibly losing information along the way if some of the bitfields are
differently sized? Or does it just give you the raw number, and let you trip
over the bad advice in perlfunc? Either way, something is wrong here.
Better just treat the return value of system() as a boolean and check
${^CHILD_ERROR_NATIVE} if you need details. At least it has reasonable
documented behavior.
--
Alan Curry
------------------------------
Date: Sun, 25 Oct 2009 23:14:57 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Shifting error codes
Message-Id: <ho2fr6-kqd1.ln1@osiris.mauzo.dyndns.org>
Quoth pacman@kosh.dhis.org (Alan Curry):
>
> I assume that this evil magic number is a leftover from perl's early years
> when there were no modules, and no easy way to make the system's WIFEXITED,
> WEXITSTATUS, and related macros available inside a perl script. Does anybody
> know what might happen if you compiled perl on a POSIX system that didn't use
> the same bit layout for an exit status? Would it translate the status code,
> possibly losing information along the way if some of the bitfields are
> differently sized? Or does it just give you the raw number, and let you trip
> over the bad advice in perlfunc? Either way, something is wrong here.
Check the source :). This has changed over the years, largely as a
result of pressure from the VMS people (VMS has W*, but doesn't use exit
codes looking anything like the POSIX ones). It turned out to be easier
to fix perl than to fix all the scripts assuming Unix semantics for $?.
Current behaviour is to extract the relevant bits using the proper W*
macros and then build up a fake $? value that looks the way you would
expect. ${^C_E_N} is there in case you need the *actual* return value.
> Better just treat the return value of system() as a boolean and check
> ${^CHILD_ERROR_NATIVE} if you need details. At least it has reasonable
> documented behavior.
It's documented that ($? >> 8) will be the lowest 8 bits of the process'
exit value. The signal and core stuff is non-portable, but then that's
to be expected. (It will be correct if the OS provides reasonable
definitions of the WTERMSIG and WCOREDUMP macros.)
Ben
------------------------------
Date: Mon, 26 Oct 2009 01:17:27 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: Shifting error codes
Message-Id: <hc2tb7$nbq$1@aioe.org>
In article <ho2fr6-kqd1.ln1@osiris.mauzo.dyndns.org>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth pacman@kosh.dhis.org (Alan Curry):
>>
>> I assume that this evil magic number is a leftover from perl's early years
>> when there were no modules, and no easy way to make the system's WIFEXITED,
>> WEXITSTATUS, and related macros available inside a perl script. Does anybody
>> know what might happen if you compiled perl on a POSIX system that didn't use
>> the same bit layout for an exit status? Would it translate the status code,
>> possibly losing information along the way if some of the bitfields are
>> differently sized? Or does it just give you the raw number, and let you trip
>> over the bad advice in perlfunc? Either way, something is wrong here.
>
>Check the source :). This has changed over the years, largely as a
>result of pressure from the VMS people (VMS has W*, but doesn't use exit
>codes looking anything like the POSIX ones). It turned out to be easier
>to fix perl than to fix all the scripts assuming Unix semantics for $?.
Unix semantics? The Unix definition is here:
http://www.opengroup.org/onlinepubs/9699919799/functions/waitpid.html
And that definition doesn't mandate any particular arrangement of bits. Unix
requires the use of W*() macros to examine an exit code, unless you're just
comparing it to 0 which is a special value.
"Shift by 8" is unwarranted chumminess with the implementation, as wrong as
hardcoding an assumption that EAGAIN==11, or O_NONBLOCK==0x800, or LOCK_EX==2
which used to also be encouraged by perlfunc, and is still sort of implied
to be correct there. (I wonder if that's subject to translation too)
>
>Current behaviour is to extract the relevant bits using the proper W*
>macros and then build up a fake $? value that looks the way you would
>expect. ${^C_E_N} is there in case you need the *actual* return value.
I see now that this is better documented in the perlvar entry for $?.
Before, I was looking at the perlfunc entry for system(). I don't see
anything that explicitly says the value returned by system is the same value
that gets put into $?. They're both described in similar terms, and they're
obviously strongly related, but since at least one of them is being mangled
from native format to "shift by 8" format, the situation is still not clear.
>
>> Better just treat the return value of system() as a boolean and check
>> ${^CHILD_ERROR_NATIVE} if you need details. At least it has reasonable
>> documented behavior.
>
>It's documented that ($? >> 8) will be the lowest 8 bits of the process'
>exit value. The signal and core stuff is non-portable, but then that's
>to be expected. (It will be correct if the OS provides reasonable
>definitions of the WTERMSIG and WCOREDUMP macros.)
So the you can litter your code with magic numebrs that match the magic
numbers that perl puts into $? or you can write something readable instead,
and as a bonus get the un-truncated exit value, by using
${^CHILD_ERROR_NATIVE} and the POSIX module.
But wait... according to the POSIX module's man page:
WEXITSTATUS WEXITSTATUS($?) returns the normal exit status
of the child process (only meaningful if
WIFEXITED($?) is true)
I hope that's a documentation bug. I hope it should really be
WEXITSTATUS(${^CHILD_ERROR_NATIVE}). Or does the POSIX module's WEXITSTATUS()
not actually do the same thing as the C-level WEXITSTATUS(), does it actually
expect the perl-mangled $? variable instead of the real status code? If that
documentation is correct, then I can see no way at all to portably get a
child process's full exit status in perl. What a clusterfsck.
--
Alan Curry
------------------------------
Date: Mon, 26 Oct 2009 02:02:26 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Shifting error codes
Message-Id: <iicfr6-v0f1.ln1@osiris.mauzo.dyndns.org>
Quoth pacman@kosh.dhis.org (Alan Curry):
> In article <ho2fr6-kqd1.ln1@osiris.mauzo.dyndns.org>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >
> >Quoth pacman@kosh.dhis.org (Alan Curry):
> >>
> >> I assume that this evil magic number is a leftover from perl's early years
> >> when there were no modules, and no easy way to make the system's WIFEXITED,
> >> WEXITSTATUS, and related macros available inside a perl script. Does anybody
> >> know what might happen if you compiled perl on a POSIX system that didn't use
> >> the same bit layout for an exit status? Would it translate the status code,
> >> possibly losing information along the way if some of the bitfields are
> >> differently sized? Or does it just give you the raw number, and let you trip
> >> over the bad advice in perlfunc? Either way, something is wrong here.
> >
> >Check the source :). This has changed over the years, largely as a
> >result of pressure from the VMS people (VMS has W*, but doesn't use exit
> >codes looking anything like the POSIX ones). It turned out to be easier
> >to fix perl than to fix all the scripts assuming Unix semantics for $?.
>
> Unix semantics? The Unix definition is here:
>
> http://www.opengroup.org/onlinepubs/9699919799/functions/waitpid.html
>
> And that definition doesn't mandate any particular arrangement of bits. Unix
> requires the use of W*() macros to examine an exit code, unless you're just
> comparing it to 0 which is a special value.
Unix is not POSIX, nor is it XPG (trademarks aside). There are a lot of
assumptions that are implied by 'Unix' that aren't covered by any
standard, such as 'by default C programs will be linked with -lc, which
lives in /lib/libc.so.*', '/dev contains device entries for all the
hardware in the system' and 'some version of perl will be available as
/usr/bin/perl'.
> "Shift by 8" is unwarranted chumminess with the implementation, as wrong as
> hardcoding an assumption that EAGAIN==11, or O_NONBLOCK==0x800, or LOCK_EX==2
> which used to also be encouraged by perlfunc, and is still sort of implied
> to be correct there.
It is. It's a shame that perl didn't acquire W* functions a little
earlier: I suspect that simple macros like LOCK_EX were easy enough to
do with h2ph, so everyone got into the habit of using them under Perl 4,
whereas function macros like WIFEXITED require h2xs, a real compiler,
and Perl 5.
> (I wonder if that's subject to translation too)
I don't think it is.
> >Current behaviour is to extract the relevant bits using the proper W*
> >macros and then build up a fake $? value that looks the way you would
> >expect. ${^C_E_N} is there in case you need the *actual* return value.
>
> I see now that this is better documented in the perlvar entry for $?.
> Before, I was looking at the perlfunc entry for system(). I don't see
> anything that explicitly says the value returned by system is the same value
> that gets put into $?. They're both described in similar terms, and they're
> obviously strongly related, but since at least one of them is being mangled
> from native format to "shift by 8" format, the situation is still not clear.
I think the code example in perldoc -f system makes it quite clear: this
is $?, not ${^C_E_N}.
> >> Better just treat the return value of system() as a boolean and check
> >> ${^CHILD_ERROR_NATIVE} if you need details. At least it has reasonable
> >> documented behavior.
> >
> >It's documented that ($? >> 8) will be the lowest 8 bits of the process'
> >exit value. The signal and core stuff is non-portable, but then that's
> >to be expected. (It will be correct if the OS provides reasonable
> >definitions of the WTERMSIG and WCOREDUMP macros.)
>
> So the you can litter your code with magic numebrs that match the magic
> numbers that perl puts into $? or you can write something readable instead,
> and as a bonus get the un-truncated exit value, by using
> ${^CHILD_ERROR_NATIVE} and the POSIX module.
>
> But wait... according to the POSIX module's man page:
>
> WEXITSTATUS WEXITSTATUS($?) returns the normal exit status
> of the child process (only meaningful if
> WIFEXITED($?) is true)
This documentation precedes the existance of ${^C_E_N}, and hasn't been
updated.
> I hope that's a documentation bug. I hope it should really be
> WEXITSTATUS(${^CHILD_ERROR_NATIVE}). Or does the POSIX module's WEXITSTATUS()
> not actually do the same thing as the C-level WEXITSTATUS(), does it actually
> expect the perl-mangled $? variable instead of the real status code?
It's unclear, and possibly incorrect. I *think* that as the code
currently stands, the POSIX::W* functions want a value looking like $?,
and will give incorrect results if passed ${^C_E_N} on a system where
these are different. I'm not at all sure what they will do on VMS, where
AFAICS they will end up passing a Perl-style $? value to the system W*
macro, which I suspect won't work at all. (It seems that the only
systems Perl supports that *don't* use 'normal' exit statusseses are VMS
and BeOS/Haiku.)
> If that
> documentation is correct, then I can see no way at all to portably get a
> child process's full exit status in perl. What a clusterfsck.
Well, you can reliably get 8 bits of exit status (all you can portably
assume) using ($? >> 8). That's kind-of the point of this whole mess.
Alternatively, you can use IPC::System::Simple, which attempts to
portably extract as much information as possible, including things like
detecting core dumps on systems where Configure didn't find the
WCOREDUMP macro and so the information doesn't make it back into $?.
Ben
------------------------------
Date: Mon, 26 Oct 2009 03:57:38 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: Shifting error codes
Message-Id: <hc36ni$dq$1@aioe.org>
In article <iicfr6-v0f1.ln1@osiris.mauzo.dyndns.org>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth pacman@kosh.dhis.org (Alan Curry):
>> In article <ho2fr6-kqd1.ln1@osiris.mauzo.dyndns.org>,
>> Ben Morrow <ben@morrow.me.uk> wrote:
>> >Check the source :). This has changed over the years, largely as a
>> >result of pressure from the VMS people (VMS has W*, but doesn't use exit
>> >codes looking anything like the POSIX ones). It turned out to be easier
>> >to fix perl than to fix all the scripts assuming Unix semantics for $?.
>>
>> Unix semantics? The Unix definition is here:
>>
>> http://www.opengroup.org/onlinepubs/9699919799/functions/waitpid.html
>>
>> And that definition doesn't mandate any particular arrangement of bits. Unix
>> requires the use of W*() macros to examine an exit code, unless you're just
>> comparing it to 0 which is a special value.
>
>Unix is not POSIX, nor is it XPG (trademarks aside). There are a lot of
So what you meant by "Unix semantics" as applied to system()/wait() then is
in fact "bit-for-bit compatibility with V7"? I'm not sure that's a better
definition than what the IEEE/OpenGroup people have come up with.
[...]
>macro, which I suspect won't work at all. (It seems that the only
>systems Perl supports that *don't* use 'normal' exit statusseses are VMS
>and BeOS/Haiku.)
Rampant binary compatibility allows you to get away with hardcoded magic
numbers instead of using the proper abstractions. This is great if you're a
sloppy coder, not so much if you're trying to do the right thing.
--
Alan Curry
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2651
***************************************
