[31820] in Perl-Users-Digest
Perl-Users Digest, Issue: 3083 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Aug 17 18:09:22 2010
Date: Tue, 17 Aug 2010 15:09:06 -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 Tue, 17 Aug 2010 Volume: 11 Number: 3083
Today's topics:
Re: combining hashes <uri@StemSystems.com>
Re: combining hashes <derykus@gmail.com>
Re: combining hashes <hjp-usenet2@hjp.at>
Re: combining hashes <uri@StemSystems.com>
Re: combining hashes <rvtol+usenet@xs4all.nl>
Re: combining hashes <hjp-usenet2@hjp.at>
Re: combining hashes <kst-u@mib.org>
Re: combining hashes <kst-u@mib.org>
Re: combining hashes <hjp-usenet2@hjp.at>
Re: combining hashes <uri@StemSystems.com>
Re: combining hashes <ben@morrow.me.uk>
Re: combining hashes <tadmc@seesig.invalid>
Re: combining hashes <monkey@joemoney.net>
Re: combining hashes <monkey@joemoney.net>
Re: Warning message: Can't spawn ... No error <ben@morrow.me.uk>
Re: Warning message: Can't spawn ... No error <derykus@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 17 Aug 2010 14:19:58 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: combining hashes
Message-Id: <87sk2dumnl.fsf@quad.sysarch.com>
>>>>> "c" == ccc31807 <cartercc@gmail.com> writes:
c> As for using 'order' in a strange way, what about this (albeit in
c> another language):
c> select first, middle, last, address, city, state, zip, balance
c> from customer order by zip;
c> Database tables aren't intrinsically ordered, but the use of the word
c> 'order' has a specific meaning in SQL that creates a particular order
c> for the results.
and what does order do? how does perl get back the results? it SORTS the
selected records by zip. perl gets back an ARRAY of hashes (if you asked
dbi for hashes). there is no sorted hash. ordered means list or array.
>> But you have to *explicitly* order/sort the output. The hash itself has
>> no (useful) order.
c> Looking back on what I originally wrote, this is what I said -- you
c> can't use a common key to combine the values in two different hashes
c> unless you 'order' the key in the second hash by the key in the first
c> hash. The little code snippet I posted shows this explicitly.
huh? ordering isn't precedence either. the right hash has precedence
over the left hash. the order of the hashes controls the
precedence. there still is no order in the hashes themselves.
>> > To be real clear, specific, and unambiguous, when I'm working on a
>> > report and the items need to be ordered in some kind of way, I think
>> > 'hash.' When the order of the items doesn't matter and all I need is
>> > some kind of list, I think 'array.'
>>
>> You shouldn't do this. Think "how do I need to access the elements?". If
>> you need to access them either in sequence (in *order*!) or by a numeric
>> key, think array. If you need to access them by a string key, think
>> hash.
c> The sequence of an array isn't usually the way you want the items,
c> excepting inherently numeric items like DOW or MOY. In a hash, you
c> sort like this a lot:
jeez. the order in an array IS HOW YOU WANT to be ordered. you are
conflating data and slots. data is never ordered. SLOTS are ordered in
an array. you can change the order BASED on data but the data doesn't
tell you the order. the ARRAY has the order. containers are not their
data. this is something you need to learn. perl data slots (in hashes
and arrays) are NOT their data, but contain them.
c> $hash{$a}{last} cmp $hash{$b}{last} ||
c> $hash{$a}{first} cmp $hash{$b}{first} ||
c> $hash{$a}{middle} cmp $hash{$b}{middle} ||
c> $hash{$a}{suffix} cmp $hash{$b}{suffix}
that is not ordering a hash. it is ordering a LIST or ARRAY of
hashes. you can't order a hash. period.
c> You can tell me that a list of names by last, first, middle, and
c> suffix isn't an ordered list, but I don't have to believe you. The
c> underlying DATA may be unordered as the natively in a hash, but the
c> INFORMATION is certainly ordered, and there's a big difference between
c> DATA and INFORMATION.
i give up. you think the way you want, backwards, inside out,
whatever. you ask for help here and you don't seem to listen sometimes.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 17 Aug 2010 11:55:04 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: combining hashes
Message-Id: <d416dde4-fa28-4a84-8cc4-52afa92ec3a1@q21g2000prm.googlegroups.com>
On Aug 17, 7:49=A0am, ccc31807 <carte...@gmail.com> wrote:
> On Aug 17, 9:54=A0am, mer...@stonehenge.com (Randal L. Schwartz) wrote:
>
> > ccc31807> Yeah, I was wrong when I said that hashes were an ordered dat=
a
> > ccc31807> structure and that arrays were an unordered data structure, a=
nd I
> > ccc31807> acknowledge the error. But I was speaking as an end user, not=
as a
> > ccc31807> programmer, so my error (hopefully) can be seen as what it re=
ally is
> > ccc31807> -- speaking as a user rather than as a programmer.
>
> > This isn't even right speaking as "a user" though. =A0Unless you make u=
p
> > completely unusual meanings for "ordered". =A0Which at that point, you
> > have no intention of communication, since you're not interested in
> > recreating for me the state of the universe that you live in. End of
> > game.
>
> So what do you do when your customer specifies a report 'in order' by
> last, first, middle name, or by GPA and major, or inversely by last
> payment date and account balance? Tell him that he doesn't know know
> what 'order' means and that if he can't communicate properly he can't
> get his report?
>
> Emerson is quoted as saying that a foolish consistency is the
> hobgoblin of small minds. Judging by what some have posted here, I'm
> beginning to question mind size.
>
> I took the hit for speaking in error. I've also tried to be as clear
> as I could about the purpose of using specific data structures. In the
> universe where I live, I have to translate user specifications into
> program code. Sometimes I get confused. Sometimes my users get
> confused. Confusion isn't the end of the game, but actually the
> beginning of the game.
>
Exactly. And imagine the confusion when, before the game,
Yogi Berra ordered the team to line up "alphabetically
by height".
--
Charles DeRykus
------------------------------
Date: Tue, 17 Aug 2010 20:58:48 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: combining hashes
Message-Id: <slrni6lmv8.d06.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-17 17:24, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>> Suppose you have a number of sets S_1 ... S_n.
>> Then a relation R on S_1 x ... x S_n is a set of ordered tupels
>> (e_1, ..., e_n) where e_1 ∈ S_1, ... e_n ∈ S_n.
>>
>> All the sets can be different and there is no limit on the number of
>> sets.
>>
>> This kind of relation is what the "relational" in "relational databases"
>> is about. Each relation is a set of tupels, or, in other words, a table
>> (relational databases only handle finite sets). And since the "ordering"
>> in a database has already been mentioned, I'd like to point out that the
>> tupels in a relation have no natural order, and if you use SQL you need
>> to explicitely specify "order by" if you want a specific order.
>
> Yes, of course. I knew that really :).
I thought so. That was intended for a greater audience ;-).
hp
------------------------------
Date: Tue, 17 Aug 2010 15:03:08 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: combining hashes
Message-Id: <87r5hxt637.fsf@quad.sysarch.com>
>>>>> "CD" == C DeRykus <derykus@gmail.com> writes:
CD> Exactly. And imagine the confusion when, before the game,
CD> Yogi Berra ordered the team to line up "alphabetically
CD> by height".
yogi was a master logician compared to our dear ccc! :)
to paraphrase another yogism and very appropriate to this thread:
100% of coding is half mental! :)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 17 Aug 2010 21:14:42 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: combining hashes
Message-Id: <4c6adfa2$0$22933$e4fe514c@news.xs4all.nl>
Jürgen Exner wrote:
> If items are ordered, then by definition of ordered there is always
> (except for the first and last item) a predecessor and a successor of
> this element.
And key leads to value.
;)
--
Ruud
------------------------------
Date: Tue, 17 Aug 2010 21:41:16 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: combining hashes
Message-Id: <slrni6lpet.d06.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-17 17:17, ccc31807 <cartercc@gmail.com> wrote:
> On Aug 17, 10:51 am, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
>> End users know nothing about hashes and arrays. I don't see where end
>> users come into this.
>
> End users know how they want their data.
Yes. And so far none of my end users has asked me to deliver data "as a
hash". They may want it as CSV or Excel files or PDFs. They may want it
ordered by some criteria. But they don't care about arrays or hashes.
The closest thing to a hash an end user might ever see is a table in an
RDBMS with a unique key.
> As for using 'order' in a strange way, what about this (albeit in
> another language):
> select first, middle, last, address, city, state, zip, balance
> from customer order by zip;
> Database tables aren't intrinsically ordered, but the use of the word
> 'order' has a specific meaning in SQL that creates a particular order
> for the results.
Yes, the result of the query is ordered. But as you write yourself, the
table is not. Just because you *can* order something doesn't mean it
*is* ordered.
>> But you have to *explicitly* order/sort the output. The hash itself has
>> no (useful) order.
>
> Looking back on what I originally wrote, this is what I said -- you
> can't use a common key to combine the values in two different hashes
> unless you 'order' the key in the second hash by the key in the first
> hash. The little code snippet I posted shows this explicitly.
I haven't the slightest idea what "'order' the key in the second hash by
the key in the first hash" is supposed to mean, not even after looking
at the snippet you probably mean.
>> > To be real clear, specific, and unambiguous, when I'm working on a
>> > report and the items need to be ordered in some kind of way, I think
>> > 'hash.' When the order of the items doesn't matter and all I need is
>> > some kind of list, I think 'array.'
>>
>> You shouldn't do this. Think "how do I need to access the elements?". If
>> you need to access them either in sequence (in *order*!) or by a numeric
>> key, think array. If you need to access them by a string key, think
>> hash.
>
> The sequence of an array isn't usually the way you want the items,
Sometimes it is. Sometimes you get items in a specific order and you
want to keep them that way. Then you use an array, because a hash has no
order. So to use your sql example, that would be used something like
this:
my $customers
= $dbh->selectall_arrayref(
q{
select first, middle, last, address, city, state, zip, balance
from customer order by zip;
},
{ Slice => {} }
);
for (@$customers) {
...
}
You obviously care about the order (or you wouldn't have specified an
order by clause).
If you assign it to a hash(ref), like this:
my $customers
= $dbh->selectall_hashref(
q{
select id, first, middle, last, address, city, state, zip, balance
from customer order by zip;
},
'id' # need something unique here
);
for (values %$customers) {
...
}
you obviously don't care about the order and you should have omitted the
"order by zip". Why tell the database to order the result if you
immediately throw the order away?
> excepting inherently numeric items like DOW or MOY. In a hash, you
> sort like this a lot:
>
> $hash{$a}{last} cmp $hash{$b}{last} ||
> $hash{$a}{first} cmp $hash{$b}{first} ||
> $hash{$a}{middle} cmp $hash{$b}{middle} ||
> $hash{$a}{suffix} cmp $hash{$b}{suffix}
You do realize that what you are sorting here is a list (the list of
keys) - i.e. practically an array.
And if your customers were stored in an array in the first place you
would sort them like this:
sort {
$a->{last} cmp $b->{last} ||
$a->{first} cmp $b->{first} ||
$a->{middle} cmp $b->{middle} ||
$a->{suffix} cmp $b->{suffix}
} @customers;
>
> You can tell me that a list of names by last, first, middle, and
> suffix isn't an ordered list,
Of course it is ordered. A list has order. A hash does not. Do you
really not understand the difference between a list and a hash?
hp
------------------------------
Date: Tue, 17 Aug 2010 12:43:12 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: combining hashes
Message-Id: <lnocd1rpnz.fsf@nuthaus.mib.org>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Keith Thompson <kst-u@mib.org>:
>> ccc31807 <cartercc@gmail.com> writes:
>> [...]
>> > Let me recast my statement: the keys of a hash are ordered in the
>> > sense that the value of the key correlates to the content of the hash,
>> > while the indices of an array are ordered but the values contained in
>> > the array are not necessarily ordered, although they certain can be.
>>
>> I decided to look up the technical meaning of "ordered". foldoc.org
>> seems like a likely place to find a good definition. Here's what I
>> found:
>>
>> <http://foldoc.org/ordering>
>> An "ordering" is defined as a "relation".
>
> That definition is woefully incomplete.
Fair enough. Dictionaries tend not to be the best resource for learning
about a complex field.
Please note that I'm using "dictionary", "complex", and "field" with
their usual English meanings. 8-)}
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Tue, 17 Aug 2010 12:49:43 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: combining hashes
Message-Id: <lnk4nprpd4.fsf@nuthaus.mib.org>
ccc31807 <cartercc@gmail.com> writes:
> On Aug 17, 11:05Â am, Tad McClellan <ta...@seesig.invalid> wrote:
>> Imposing a particular ordering is known as "sorting".
>> So, you sort your data into the order specified by your customer.
>
> This is absolutely, one hundred percent correct.
>
> However, my users still specify their reports in some order. To do
> this, I use sort().
Of course. And it's the sort() that imposes an ordering that did not
exist in the hash.
> However, I still ordinarily think 'hash' when the instruction is 'in
> order' and think 'array' when it doesn't matter and all I need is
> something to hold a list.
Do you see how odd that is?
Ok, if you're storing a bunch of data and you want to extract it
in a specified order, sort() lets you create orders very flexibly;
you can sort numerically, by name, or by whatever criterion you
can express in a comparison function. The ordering of an array
is strictly by index, which is far less flexible. And you can
certainly store data in an array without caring about the order
(but there will be a well-defined order, even if you ignore it.)
It's not the hash that does the ordering, it's sort.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Tue, 17 Aug 2010 21:43:12 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: combining hashes
Message-Id: <slrni6lpig.d06.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-17 18:19, Uri Guttman <uri@StemSystems.com> wrote:
> c> $hash{$a}{last} cmp $hash{$b}{last} ||
> c> $hash{$a}{first} cmp $hash{$b}{first} ||
> c> $hash{$a}{middle} cmp $hash{$b}{middle} ||
> c> $hash{$a}{suffix} cmp $hash{$b}{suffix}
>
> that is not ordering a hash. it is ordering a LIST or ARRAY of
> hashes.
Actually it orders a list of keys of the hash %hash.
hp
------------------------------
Date: Tue, 17 Aug 2010 16:00:53 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: combining hashes
Message-Id: <87d3throui.fsf@quad.sysarch.com>
>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
PJH> On 2010-08-17 18:19, Uri Guttman <uri@StemSystems.com> wrote:
c> $hash{$a}{last} cmp $hash{$b}{last} ||
c> $hash{$a}{first} cmp $hash{$b}{first} ||
c> $hash{$a}{middle} cmp $hash{$b}{middle} ||
c> $hash{$a}{suffix} cmp $hash{$b}{suffix}
>>
>> that is not ordering a hash. it is ordering a LIST or ARRAY of
>> hashes.
PJH> Actually it orders a list of keys of the hash %hash.
true for that code but then it makes no sense either. what is being
sorted (passed in $a and $b)? you can't sort a single hash!
but if you pass in a list of hash refs and sort by a value INSIDE the
hashes, the hash refs will be reordered and not by any key. he isn't
doing exactly that but i seemed to imply it.
again, we can't take what ccc says about sorting, ordering and hashes at
face value. we must interpret what he says through alice's mirror of
words meaning what i mean them to mean! :)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 17 Aug 2010 21:43:11 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: combining hashes
Message-Id: <vr8rj7-vd03.ln1@osiris.mauzo.dyndns.org>
Quoth "Uri Guttman" <uri@StemSystems.com>:
>
> again, we can't take what ccc says about sorting, ordering and hashes at
> face value. we must interpret what he says through alice's mirror of
> words meaning what i mean them to mean! :)
Humpty Dumpty. Alice was just as confused by it as we are.
Ben
------------------------------
Date: Tue, 17 Aug 2010 16:32:30 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: combining hashes
Message-Id: <slrni6lvo4.q5i.tadmc@tadbox.sbcglobal.net>
Tad McClellan <tadmc@seesig.invalid> wrote:
> ccc31807 <cartercc@gmail.com> wrote:
>>
>> However, I still ordinarily think 'hash' when the instruction is 'in
>> order' and think 'array' when it doesn't matter and all I need is
>> something to hold a list.
>
>
> However, you still have an inversion in your thinking!
Upon further reflection, I am quite sure that the disconnect
is between how data is stored versus how it is output.
You can store it ordered in an array.
You can store it unordered in a hash.
You can sort the output of either into any order your customer requires.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Tue, 17 Aug 2010 17:35:35 -0400
From: monkeys paw <monkey@joemoney.net>
Subject: Re: combining hashes
Message-Id: <1oydnYkUacI1nfbRnZ2dnUVZ_gednZ2d@insightbb.com>
On 8/16/2010 4:00 PM, Dr.Ruud wrote:
> monkeys paw wrote:
>
>> I have two hashrefs, i want to combine them into one hash.
>> I think there is an easier way than what i am doing (shown below):
>>
>> $fc = {'a' => 'hash'};
>> $ref = {'another' => 'hash'};
>>
>> for (keys %{$fc}) {
>> $args{$_} = $fc->{$_};
>> }
>> for (keys %{$ref}) {
>> $args{$_} = $ref->{$_};
>> }
>
>
> my $combi = { %$fc, %$ref };
>
Thanks, i ended up using a hash instead of hashref:
my %combi = ( $%fc, %$ref);
------------------------------
Date: Tue, 17 Aug 2010 17:37:54 -0400
From: monkeys paw <monkey@joemoney.net>
Subject: Re: combining hashes
Message-Id: <1oydnYgUacKunPbRnZ2dnUVZ_gcAAAAA@insightbb.com>
On 8/16/2010 4:39 PM, sln@netherlands.com wrote:
> On Mon, 16 Aug 2010 15:53:59 -0400, monkeys paw<monkey@joemoney.net> wrote:
>
>> I have two hashrefs, i want to combine them into one hash.
>> I think there is an easier way than what i am doing (shown below):
>>
>> $fc = {'a' => 'hash'};
>> $ref = {'another' => 'hash'};
>>
>> for (keys %{$fc}) {
>> $args{$_} = $fc->{$_};
>> }
>> for (keys %{$ref}) {
>> $args{$_} = $ref->{$_};
>> }
>
> Yes, the easier way is this:
> $args = {'a' => 'hash', 'another' => 'hash'};
>
> Why do you ask?
>
> -sln
The hashrefs are individual return from a DBI->fetchrow_hashref(). I
need to combine both into one for later display. I was sure i had tried
the working method which sent me on the goose chase.
------------------------------
Date: Tue, 17 Aug 2010 19:40:06 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Warning message: Can't spawn ... No error
Message-Id: <6l1rj7-cfv2.ln1@osiris.mauzo.dyndns.org>
Quoth Dilbert <dilbert1999@gmail.com>:
> I have the following perl program to test return codes (I am running
> Strawberry Perl 5.12 under Windows Vista 64 bits):
>
> ===============
> use 5.012;
> use warnings;
>
> say 'Start';
> system qq{perl -e"exit -1"};
> say 'Stop';
> ===============
>
> Here is the output:
> ===============
> Start
> Can't spawn "perl -e"exit -1"": No error at C:\test.pl line 5.
> Stop
> ===============
>
> The program as such runs ok, but the problem is the warning message
> >>Can't spawn "perl -e"exit -1"": No error<< which I don't understand
> at all. I want to have warnings on in general, but this particular
> warning is not desired.
You can turn this particular warning (and a few others) off with no
warnings "exec". You will see an apparent exit value of 255, regardless
of what the program actually exitted with, though you should see the
real exitcode in ${^CHILD_ERROR_NATIVE}.
> Why should there be a warning at all if the
> return code is negative ? -- If I run the same program with "...exit
> 1;..." then everything is ok, i.e. no warning is emitted.
I wasn't aware negative exit codes were possible. They aren't on Unix:
the exit code section of the value returned by wait(2) is an unsigned
8-bit integer, so attempting to call exit(-1) will lead to the parent
seeing an exit code of 255.
Win32's native exit status is a DWORD. I believe DWORD is an unsigned
type, which would mean this section of win32_spawnvp:
DWORD status;
win32_msgwait(aTHX_ 1, &ProcessInformation.hProcess, INFINITE, NULL);
/* FIXME: if msgwait returned due to message perhaps forward the
"signal" to the process
*/
GetExitCodeProcess(ProcessInformation.hProcess, &status);
ret = (int)status;
is wrong, since it's casting a DWORD to a signed integer, and the caller
is assuming a negative return means an error. It should probably be
followed by something like
if (ret < 0) ret = PERL_MAX_INT;
or maybe just replaced with
ret = status > PERL_MAX_INT ? PERL_MAX_INT : (int)status;
Ben
------------------------------
Date: Tue, 17 Aug 2010 13:48:58 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Warning message: Can't spawn ... No error
Message-Id: <28972550-7622-4259-af2d-8efa1a63bd56@q40g2000prg.googlegroups.com>
On Aug 17, 11:40=A0am, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Dilbert <dilbert1...@gmail.com>:
>
>> ...
> You can turn this particular warning (and a few others) off with no
> warnings "exec". You will see an apparent exit value of 255, regardless
> of what the program actually exitted with, though you should see the
> real exitcode in ${^CHILD_ERROR_NATIVE}.
>
> > Why should there be a warning at all if the
> > return code is negative ? -- If I run the same program with "...exit
> > 1;..." then everything is ok, i.e. no warning is emitted.
>
> I wasn't aware negative exit codes were possible. They aren't on Unix:
> the exit code section of the value returned by wait(2) is an unsigned
> 8-bit integer, so attempting to call exit(-1) will lead to the parent
> seeing an exit code of 255.
>
> Win32's native exit status is a DWORD. I believe DWORD is an unsigned
> type, which would mean this section of win32_spawnvp:
>
> =A0 =A0 =A0 =A0 DWORD status;
> =A0 =A0 =A0 =A0 win32_msgwait(aTHX_ 1, &ProcessInformation.hProcess, INFI=
NITE, NULL);
> =A0 =A0 =A0 =A0 /* FIXME: if msgwait returned due to message perhaps forw=
ard the
> =A0 =A0 =A0 =A0 =A0 =A0"signal" to the process
> =A0 =A0 =A0 =A0 =A0*/
> =A0 =A0 =A0 =A0 GetExitCodeProcess(ProcessInformation.hProcess, &status);
> =A0 =A0 =A0 =A0 ret =3D (int)status;
>
> is wrong, since it's casting a DWORD to a signed integer, and the caller
> is assuming a negative return means an error. It should probably be
> followed by something like
>
> =A0 =A0 if (ret < 0) ret =3D PERL_MAX_INT;
>
> or maybe just replaced with
>
> =A0 =A0 ret =3D status > PERL_MAX_INT ? PERL_MAX_INT : (int)status;
>
And somewhat confusingly, backticks don't generate a
warning:
perl -wlE "say 'Start'; qx{$^X -e \"system exit -1\"};
say 'Stop: ',$?>>8"
Start
Stop: 255
--
Charles DeRykus
------------------------------
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 3083
***************************************
