[32296] in Perl-Users-Digest
Perl-Users Digest, Issue: 3563 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Dec 9 18:09:28 2011
Date: Fri, 9 Dec 2011 15:09:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 9 Dec 2011 Volume: 11 Number: 3563
Today's topics:
Re: Problem configuring OS/2 for installing CPAN packag <ben@morrow.me.uk>
Re: ways to check for octets outside of the safe ASCII <rweikusat@mssgmbh.com>
Re: ways to check for octets outside of the safe ASCII <ben@morrow.me.uk>
Re: ways to check for octets outside of the safe ASCII <rweikusat@mssgmbh.com>
Re: ways to check for octets outside of the safe ASCII <ben@morrow.me.uk>
xml::simple issue with the key <hillgoogle@charter.net>
Re: xml::simple issue with the key <glex_no-spam@qwest-spam-no.invalid>
Re: xml::simple issue with the key <hillgoogle@charter.net>
Re: xml::simple issue with the key <news@lawshouse.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 9 Dec 2011 18:20:40 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Problem configuring OS/2 for installing CPAN packages
Message-Id: <o40ar8-v431.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <qr18r8-r2l.ln1@anubis.morrow.me.uk>, on 12/09/2011
> at 12:37 AM, Ben Morrow <ben@morrow.me.uk> said:
>
> >What does the Makefile look like for a few lines each side of line
> >1301?
>
> # --- MakeMaker postamble section:
>
> test_cover : pure_all
> cover -delete
> HARNESS_PERL_SWITCHES=-MDevel::Cover $(MAKE) test
> cover
Well, that section comes straight out of the Makefile.PL, and the copy
in the tarball has tabs in the the right places. Are you sure you
haven't edited the Makefile.PL with an editor that has changed tabs into
spaces? If you haven't you may have a corrupted tarball, or your tar may
be making a mess of things.
> Note that changing the spaces to tab got rid of that error. However,
> in
>
> # --- MakeMaker makemakerdflt section:
> makemakerdflt : all
> $(NOECHO) $(NOOP)
>
> it just changed the text of the message. Could the line number 436 in
> the message actually refer to line 437? Does line 436 need to be
> \tcover\t-delete?
'cover' is a program (which you don't have, and don't need: it comes
with the perl module Test::Cover) which builds a test coverage report.
The only thing make cares about is that each command-to-be-executed line
begins with at least one tab.
Just for clarity: line 436 is the "\t$(NOECHO) $(NOOP)" line?
Does the generated Makefile contain both these lines, somewhere,
NOECHO = @
NOOP = $(SHELL) -c true
and is SHELL set to something sensible (probably the pdksh that came
with perl)? If you run that shell with arguments '-c true' does it
successfully do nothing? (I suspect pdksh has a 'true' builtin, so you
probably don't need an actual true.exe.)
Ben
------------------------------
Date: Fri, 09 Dec 2011 17:40:50 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: ways to check for octets outside of the safe ASCII range?
Message-Id: <87iplpve1p.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>
>> > $filename !~ /[^[:ascii:]]/
>> >
>> > is clearer, and works properly against Unicode strings.
>>
>> Additionally, it doesn't work (in the sense that it would solve the
>> problem).
> <snip>
>> A simpler way to test wheter a string contains 'non-printable octets'
>> would be
>>
>> $filename =~ /[^[:print:]]/
>
> You're right.
>
>> except -- unfortunately space and htab (0x20 and 9) are printable (I
>> don't quite understand why space is considered to be a 'safe'
>> character while \t is not, hence I assumed that ' ' was also supposed
>> to be excluded).
>
> Space is an ordinary single-width character like any other, it just
> happens not to have any ink in its glyph. Tab is a control character
> that (typically) produces a context-dependant amount of whitespace.
>
> For example, an app that wanted to know whether it was safe to assume 1
> column per byte would treat space like 'A', but not tab.
Both space and \t (and \v, \r and \n, here supposed to be C escape
sequence mapped to ASCII) are whitespace characters and an application
which wanted to know whether it was safe to assume that a filename can
be fed to something which breaks its input into words separated by
whitespace characters would treat them all differently from any
non-whitespace character (eg, encoding them in some form, such as URL
encoding, so that 'splitting on whitespace' produces the correct
results).
Depending on the unknown context of the original question, both
interpretations could make sense (arguably, yours make more sense
because it is not based on the assumption that space was erroneously
included).
>> >> This will probably also need a 'use bytes'.
>> >
>> > 'use bytes' is always wrong.
>>
>> A statement of the form 'xxx is always wrong' is always wrong when
>> referring to some kind of existing feature. The 'use bytes'
>> documentation states
>>
>> When "use bytes" is in effect [...] each string is treated as
>> a series of bytes
>
> Yes, I know that. The general opinion among those who actually know how
> these things work (which doesn't include me) is that both the design and
> the implementation are buggy, and the pragma needs to be deprecated and
> then removed. I'm not making these things up, I'm simply relaying the
> opinion of those perl developers who are actively working on perl's
> Unicode implementation.
If these people are not aware that Perl scalars don't necessarily
store 'character strings' but also arbitrary binary data, and if they
actually want to remove the ability to use them in this way from the
language based on their ignorance of the existance of a world beyond
text processing, they're crackpots and their opinions as irrelevant as
"laymen's babbling" about any topic usually is.
Sorry guys, computer networks do exist and XML is not the universal
messageing data format. You may be convinced that this is terribly
wrong and really shouldn't be in this way, but then - please - go find
yourself some soapbox and preach the true gospel to the nonbelievers
elsewhere, leaving people who have to interoperate with the real world
alone ...
[...]
>> Since the OP was looking for 'ASCII safety of an octet string',
>> treating a string as 'series of bytes' seems to be exactly what is
>> necessary for that. So, what's the problem with that (and, just out of
>> curiosity who believes this documented Perl feature should not be used
>> for what technical reasons which are applicable to actual problems?).
>
> Go find the relevant p5p threads if you want examples. There are quite a
> few of them, as I recall...
I don't even know what you consider to be relevant and I'm certainly
not in the mood for trying to guess what the unknown source you
claimed to be referring to could possibly be. That's a 08/15
propaganda trick: Stay vague enough that people have to supply
sensible interpretations of your statement using their own knowledge/
experience and thus mistakenly believe to agree with you while they're
actually agreeing with themselves.
He who refers to authorities should name them.
>> I admit that I'm so far rather convinced that 'not using use bytes' is
>> 'always wrong' for the problems I have to deal with (which usually
>> invovle strings of bytes and not 'characters' as arbitrarily defined,
>> redefined and undefined by some US committee).
>
> I was inclined to think the same thing, until I learned that it's not
> that simple and, while 'use bytes' seems like an attractive idea, it
> doesn't appear to be possible to make it work properly.
Perl has supported using scalars for binary data since ever and if the
people who 'work on the Perl unicode implementation' cannot make that
work correctly without breaking this feature, this would hint at the
fact that either 'unicode support' cannot be implemented correctly or
(more likely) the peope who happen to dabble in this area are not
competent enough to produce useful results.
------------------------------
Date: Fri, 9 Dec 2011 19:29:02 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ways to check for octets outside of the safe ASCII range?
Message-Id: <u44ar8-c741.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >
> >> except -- unfortunately space and htab (0x20 and 9) are printable (I
> >> don't quite understand why space is considered to be a 'safe'
> >> character while \t is not, hence I assumed that ' ' was also supposed
> >> to be excluded).
> >
> > Space is an ordinary single-width character like any other, it just
> > happens not to have any ink in its glyph. Tab is a control character
> > that (typically) produces a context-dependant amount of whitespace.
> >
> > For example, an app that wanted to know whether it was safe to assume 1
> > column per byte would treat space like 'A', but not tab.
>
> Both space and \t (and \v, \r and \n, here supposed to be C escape
> sequence mapped to ASCII) are whitespace characters and an application
> which wanted to know whether it was safe to assume that a filename can
> be fed to something which breaks its input into words separated by
> whitespace characters would treat them all differently from any
> non-whitespace character (eg, encoding them in some form, such as URL
> encoding, so that 'splitting on whitespace' produces the correct
> results).
That's (the negation of) isspace(3), not isprint(3). There will be
circumstances where you need to test both, of course; annoyingly, the
POSIX character class syntax doesn't make that very easy.
> >> A statement of the form 'xxx is always wrong' is always wrong when
> >> referring to some kind of existing feature. The 'use bytes'
> >> documentation states
> >>
> >> When "use bytes" is in effect [...] each string is treated as
> >> a series of bytes
> >
> > Yes, I know that. The general opinion among those who actually know how
> > these things work (which doesn't include me) is that both the design and
> > the implementation are buggy, and the pragma needs to be deprecated and
> > then removed. I'm not making these things up, I'm simply relaying the
> > opinion of those perl developers who are actively working on perl's
> > Unicode implementation.
>
> If these people are not aware that Perl scalars don't necessarily
> store 'character strings' but also arbitrary binary data, and if they
> actually want to remove the ability to use them in this way from the
> language based on their ignorance of the existance of a world beyond
> text processing, they're crackpots and their opinions as irrelevant as
> "laymen's babbling" about any topic usually is.
These people are not 'laymen'. They are the people writing perl. What
they think is, in the end, all that matters (unless you intend to fork
the perl codebase), since they are the ones who decide how perl actually
behaves.
> Sorry guys, computer networks do exist and XML is not the universal
> messageing data format. You may be convinced that this is terribly
> wrong and really shouldn't be in this way, but then - please - go find
> yourself some soapbox and preach the true gospel to the nonbelievers
> elsewhere, leaving people who have to interoperate with the real world
> alone ...
I think you need to look up the definition of 'straw man'. I also think
you need to calm down a bit, and read for comprehension rather than
just looking for a fight.
> >> Since the OP was looking for 'ASCII safety of an octet string',
> >> treating a string as 'series of bytes' seems to be exactly what is
> >> necessary for that. So, what's the problem with that (and, just out of
> >> curiosity who believes this documented Perl feature should not be used
> >> for what technical reasons which are applicable to actual problems?).
> >
> > Go find the relevant p5p threads if you want examples. There are quite a
> > few of them, as I recall...
>
> I don't even know what you consider to be relevant and I'm certainly
> not in the mood for trying to guess what the unknown source you
> claimed to be referring to could possibly be. That's a 08/15
> propaganda trick: Stay vague enough that people have to supply
> sensible interpretations of your statement using their own knowledge/
> experience and thus mistakenly believe to agree with you while they're
> actually agreeing with themselves.
>
> He who refers to authorities should name them.
This is not a formal debate, it's a technical discussion group.
Ultimately I couldn't care less whether you 'use bytes' in your code or
not; maybe you'll get lucky and nothing will go wrong, maybe you'll fall
into one of the bugs at just the wrong moment and end up with a
disaster. Either way it make no difference to me, I just thought you
might appreciate a warning that there are known bugs to fall into.
As far as authorities go, how about this section of 5.14's bytes.pm:
=head1 NOTICE
This pragma reflects early attempts to incorporate Unicode into perl
and has since been superseded. It breaks encapsulation (i.e. it
exposes the innards of how the perl executable currently happens to
store a string), and use of this module for anything other than
debugging purposes is strongly discouraged. If you feel that the
functions here within might be useful for your application, this
possibly indicates a mismatch between your mental model of Perl
Unicode and the current reality. In that case, you may wish to read
some of the perl Unicode documentation: L<perluniintro>,
L<perlunitut>, L<perlunifaq> and L<perlunicode>.
Is that authoritative enough for you?
See also, for instance, the thread containing
http://www.nntp.perl.org/group/perl.perl5.porters/2010/02/msg157091.html
where I was arguing pretty-much your point, and was persuaded that what
I wanted wasn't (entirely) possible. There are other threads: you can
find them for yourself.
> >> I admit that I'm so far rather convinced that 'not using use bytes' is
> >> 'always wrong' for the problems I have to deal with (which usually
> >> invovle strings of bytes and not 'characters' as arbitrarily defined,
> >> redefined and undefined by some US committee).
> >
> > I was inclined to think the same thing, until I learned that it's not
> > that simple and, while 'use bytes' seems like an attractive idea, it
> > doesn't appear to be possible to make it work properly.
>
> Perl has supported using scalars for binary data since ever and if the
> people who 'work on the Perl unicode implementation' cannot make that
> work correctly without breaking this feature, this would hint at the
> fact that either 'unicode support' cannot be implemented correctly or
> (more likely) the peope who happen to dabble in this area are not
> competent enough to produce useful results.
I don't like to say this often, or in public (it smacks of ingratitude),
but IMHO there were a *lot* of mistakes made in Perl's Unicode
implementation, starting with making it an obligatory part of the
language. However, this is something we've been living with since 5.6,
so there's no point making a fuss about it now.
As far the question of whether or not it's possible to implement Unicode
support correctly goes, I would say the jury is still very much out.
Perl is already running into areas where the Unicode Consortium has no
answer as to what the right behaviour is. (For instance, given that
\N{LATIN SMALL LIGATURE FI} matches /FI/i (which it does, according to
the specs), what should /(F)(I)/i return for the captures?)
This, to me, is just one more reason Unicode should have been kept out
of the core language and instead put in some optional module, but I
don't make the rules. As far as Perl is concerned, Larry does, and Larry
was *determined* (for entirely commendable, not-everyone-speaks-English
reasons) that Perl should have full Unicode support in the core.
Ben
------------------------------
Date: Fri, 09 Dec 2011 20:56:46 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: ways to check for octets outside of the safe ASCII range?
Message-Id: <871usdv4z5.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
[...]
>> If these people are not aware that Perl scalars don't necessarily
>> store 'character strings' but also arbitrary binary data, and if they
>> actually want to remove the ability to use them in this way from the
>> language based on their ignorance of the existance of a world beyond
>> text processing, they're crackpots and their opinions as irrelevant as
>> "laymen's babbling" about any topic usually is.
>
> These people are not 'laymen'. They are the people writing perl.
Unfortunately, these are not two mutually exclusive attributes: Just
because someone happens to be in the position where his possibly weird
personal ideas flow into 'open source projects' doesn't necessarily
mean that this someone has a clue about anything except 'effective
social networking'.
> What they think is, in the end, all that matters
What matters to me is the problems I can solve with the help of
Perl. That's something tangible. Other people's opinions, especially
if these seem to be 'somewhat disconnected from actual, observable
phenomenons' don't necessarily matter to me because they are opinions.
[...]
>> Sorry guys, computer networks do exist and XML is not the universal
>> messageing data format. You may be convinced that this is terribly
>> wrong and really shouldn't be in this way, but then - please - go find
>> yourself some soapbox and preach the true gospel to the nonbelievers
>> elsewhere, leaving people who have to interoperate with the real world
>> alone ...
>
> I think you need to look up the definition of 'straw man'.
I think you need to do that. Perl scalars can store binary
data. Binary data is stored in Perl scalars. This requires the ability
to treat the scalar as a sequence of otherwise lanuage uninterpreted
bytes.
[...]
>> He who refers to authorities should name them.
>
> This is not a formal debate, it's a technical discussion group.
> Ultimately I couldn't care less whether you 'use bytes' in your code or
> not; maybe you'll get lucky and nothing will go wrong, maybe you'll fall
> into one of the bugs at just the wrong moment and end up with a
> disaster. Either way it make no difference to me, I just thought you
> might appreciate a warning that there are known bugs to fall into.
Maybe, you attempt to sound really threatening ...
>
> As far as authorities go, how about this section of 5.14's bytes.pm:
>
> =head1 NOTICE
>
> This pragma reflects early attempts to incorporate Unicode into perl
> and has since been superseded. It breaks encapsulation (i.e. it
> exposes the innards of how the perl executable currently happens to
> store a string),
... but without having anything save 'crackpottery' to base that
upon. Perl scalars are not solely used to store text strings but also,
to work with binary data and this 'encapsulation' does not exist
there.
> and use of this module for anything other than
> debugging purposes is strongly discouraged. If you feel that the
> functions here within might be useful for your application, this
> possibly indicates a mismatch between your mental model of Perl
> Unicode and the current reality.
This, OTOH, is entirely true: So far, I had assumed that 'Perl
Unicode' is supposed to enable processing of unicode character string
data, not to prevent processing of other binary data which is not
character strings.
> In that case, you may wish to read
> some of the perl Unicode documentation: L<perluniintro>,
> L<perlunitut>, L<perlunifaq> and L<perlunicode>.
>
> Is that authoritative enough for you?
It tells me that the crackpot who believes that binary data doesn't
exist or at least Perl shouldn't have facilities for handling binary
data, is indeed in the position of causing tangible damage.
Depending on how this nonsense works out, I will have to reconsider my
descision of using Perl for system programming tasks.
> See also, for instance, the thread containing
> http://www.nntp.perl.org/group/perl.perl5.porters/2010/02/msg157091.html
> where I was arguing pretty-much your point, and was persuaded that what
> I wanted wasn't (entirely) possible.
You weren't. You were writing about escape sequences for character
classes (\d, \s and \w) and preventing these from matching unicode
characters. And that's IMHO the wrong thing to do: \d is supposed to
match 'a digit' and if you specifically want to match the digits 0 -
9, that can be done in some other way.
But I'm really referring to binary data. And 'the thread' is
suspiciously silent on that except that 'bytes is bad because it
enforces byte semantics and someone might use that erroneously !!1'.
> There are other threads: you can find them for yourself.
I have probably read through enough pointless handwaiving while
carefully avoiding to address the problem for some time to come.
[...]
> This, to me, is just one more reason Unicode should have been kept out
> of the core language and instead put in some optional module, but I
> don't make the rules. As far as Perl is concerned, Larry does, and Larry
> was *determined* (for entirely commendable, not-everyone-speaks-English
> reasons) that Perl should have full Unicode support in the core.
That sounds like a sensible descisions. Was he also determine to get
rid of facilities controlling whether something should or shouldn't be
treated as unicode, including the quite useful feature that Perl
scalars can function as extensible arrays with automatic memory
management but without any other 'magic semantics' attached to that?
Or is that another hobby horse of the former 2nd and 3rd line people
who never managed to force their weirdo politics onto language users
before Mr Larry Wall finally grew tired of them? [conjecture]
------------------------------
Date: Fri, 9 Dec 2011 22:17:50 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ways to check for octets outside of the safe ASCII range?
Message-Id: <e1ear8-pa61.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >
> > These people are not 'laymen'. They are the people writing perl.
>
> Unfortunately, these are not two mutually exclusive attributes: Just
> because someone happens to be in the position where his possibly weird
> personal ideas flow into 'open source projects' doesn't necessarily
> mean that this someone has a clue about anything except 'effective
> social networking'.
Insulting people whom you have never met but who have put a large amount
of time and effort, for free, into a software project you find useful
is, by my standards, extremely rude.
> I think you need to do that. Perl scalars can store binary
> data. Binary data is stored in Perl scalars. This requires the ability
> to treat the scalar as a sequence of otherwise lanuage uninterpreted
> bytes.
I am attempting to describe the current (and past, and likely future)
behaviour of perl, in the real world. In the real world, bytes.pm is
broken, has always been broken (regardless of what its documentation
used to say), and isn't going to get fixed.
You seem to be more interested in some fantasy world where you have
access to a fantasy version of perl that behaves as you believe it ought
to. I hope you're very happy there, but you must forgive me if I'm not
terribly interested in discussing it.
> It tells me that the crackpot who believes that binary data doesn't
> exist or at least Perl shouldn't have facilities for handling binary
> data, is indeed in the position of causing tangible damage.
>
> Depending on how this nonsense works out, I will have to reconsider my
> descision of using Perl for system programming tasks.
The situation was at its worst in 5.8.0, and has been getting (slowly)
better ever since. 5.14 was an important step forward.
> But I'm really referring to binary data. And 'the thread' is
> suspiciously silent on that except that 'bytes is bad because it
> enforces byte semantics and someone might use that erroneously !!1'.
*No*. The official position (insofar as such a thing exists) is
'bytes.pm is bad because it *does* *not* properly enforce byte
semantics'. In particular, it is impossible in practice to prevent
SvUTF8 scalars from leaking into a section of code under 'bytes', and at
that point you get ill-defined and rather uninituitive behaviour.
> > don't make the rules. As far as Perl is concerned, Larry does, and Larry
> > was *determined* (for entirely commendable, not-everyone-speaks-English
> > reasons) that Perl should have full Unicode support in the core.
>
> That sounds like a sensible descisions. Was he also determine to get
> rid of facilities controlling whether something should or shouldn't be
> treated as unicode,
Such facilities, obviously, did not exist before perl supported Unicode.
They have never existed in a form which actually worked. The best you
have ever been able to do (since 5.8) is keep your binary data in
strings with all characters <256, and be very careful to never apply
textual operations to them.
I don't like the situation any more than you do, but, like you, I don't
get a vote.
> including the quite useful feature that Perl
> scalars can function as extensible arrays with automatic memory
> management but without any other 'magic semantics' attached to that?
Perl has always had such a facility. It's called 'an array'.
> Or is that another hobby horse of the former 2nd and 3rd line people
> who never managed to force their weirdo politics onto language users
> before Mr Larry Wall finally grew tired of them? [conjecture]
What, exactly, are you referring to when you mention 'weirdo politics'?
I fail to see what anything political has to do with any of this.
Ben
------------------------------
Date: Fri, 9 Dec 2011 11:59:49 -0800 (PST)
From: "hillgoogle@charter.net" <hillgoogle@charter.net>
Subject: xml::simple issue with the key
Message-Id: <f37eab96-0b44-426f-acd1-b28669c9c61d@l19g2000yqc.googlegroups.com>
I have a hash defined like:
my %men = ();
my $men;
$men{'men1'} = {'man' => { 'id' => '5',
'man_name' => ['john doe'],
'man_nt_name' => ['jdxyz'],
'man_size' => ['large'] }
};
$men{'men2'} = {'man' => { 'id' => '7',
'man_name' => ['fred Doe'],
'man_nt_name' => ['fdabc'],
'man_size' => ['size'] }
};
and I am outputting the hash to xml as follows:
#open the file
open my $fh, '>:encoding(iso-8859-1)', $prodfile or die
"open($prodfile): $!";
# create object
my $xml = new XML::Simple (KeyAttr=>'man', RootName=>'root');
#output
$xml->XMLout(\%men, OutputFile => $fh);
What I am getting is:
<root>
<men1 man="man" id="5">
<man_name>john doe</man_name>
<man_nt_name>jdxyz</man_nt_name>
<man_size>large</man_size>
</men1>
<men2 man="man" id="7">
<man_name>fred Doe</man_name>
<man_nt_name>fdabc</man_nt_name>
<man_size>size</man_size>
</men2>
</root>
What I want is:
<root>
<man id="5">
<man_name>john doe</man_name>
<man_nt_name>jdxyz</man_nt_name>
<man_size>large</man_size>
</man>
<man id="7">
<man_name>fred Doe</man_name>
<man_nt_name>fdabc</man_nt_name>
<man_size>size</man_size>
</man>
</root>
You can see that I don't want the hash key in the xml output.
Any help is appreciated.
Mike
------------------------------
Date: Fri, 09 Dec 2011 20:36:01 +0000
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: xml::simple issue with the key
Message-Id: <4ee27131$0$9080$815e3792@news.qwest.net>
On 12/09/11 19:59, hillgoogle@charter.net wrote:
> I have a hash defined like:
>
> my %men = ();
> my $men;
> $men{'men1'} = {'man' => { 'id' => '5',
> 'man_name' => ['john doe'],
> 'man_nt_name' => ['jdxyz'],
> 'man_size' => ['large'] }
> };
> $men{'men2'} = {'man' => { 'id' => '7',
> 'man_name' => ['fred Doe'],
> 'man_nt_name' => ['fdabc'],
> 'man_size' => ['size'] }
> };
>
> and I am outputting the hash to xml as follows:
>
> #open the file
> open my $fh, '>:encoding(iso-8859-1)', $prodfile or die
> "open($prodfile): $!";
>
> # create object
> my $xml = new XML::Simple (KeyAttr=>'man', RootName=>'root');
>
> #output
> $xml->XMLout(\%men, OutputFile => $fh);
>
> What I am getting is:
> <root>
> <men1 man="man" id="5">
> <man_name>john doe</man_name>
> <man_nt_name>jdxyz</man_nt_name>
> <man_size>large</man_size>
> </men1>
> <men2 man="man" id="7">
> <man_name>fred Doe</man_name>
> <man_nt_name>fdabc</man_nt_name>
> <man_size>size</man_size>
> </men2>
> </root>
>
> What I want is:
> <root>
> <man id="5">
> <man_name>john doe</man_name>
> <man_nt_name>jdxyz</man_nt_name>
> <man_size>large</man_size>
> </man>
> <man id="7">
> <man_name>fred Doe</man_name>
> <man_nt_name>fdabc</man_nt_name>
> <man_size>size</man_size>
> </man>
> </root>
>
> You can see that I don't want the hash key in the xml output.
Then why are you putting it in the data structure?
XML:Simple converts your data structure, so modify the data structure
accordingly.
push( @{ $men{ 'man' } },
{'id' => '5',
'man_name' => ['john doe'],
'man_nt_name' => ['jdxyz'],
'man_size' => ['large'] } );
push( @{ $men{ 'man' } },{ 'id' => '7',
'man_name' => ['fred Doe'],
'man_nt_name' => ['fdabc'],
'man_size' => ['size'] }
);
[...]
<root>
<man id="5">
<man_name>john doe</man_name>
<man_nt_name>jdxyz</man_nt_name>
<man_size>large</man_size>
</man>
<man id="7">
<man_name>fred Doe</man_name>
<man_nt_name>fdabc</man_nt_name>
<man_size>size</man_size>
</man>
</root>
------------------------------
Date: Fri, 9 Dec 2011 13:29:13 -0800 (PST)
From: "hillgoogle@charter.net" <hillgoogle@charter.net>
Subject: Re: xml::simple issue with the key
Message-Id: <271e5f59-013c-4cf7-811c-a96809017e53@t38g2000yqe.googlegroups.com>
Nice ... that is exactly what I needed. TY !!!
So i was creating new structures instead of adding ...
Thanks, Mike
------------------------------
Date: Fri, 09 Dec 2011 21:38:18 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: xml::simple issue with the key
Message-Id: <cfmdnehpHcNX4n_TnZ2dnUVZ7vednZ2d@giganews.com>
On 09/12/11 19:59, hillgoogle@charter.net wrote:
> What I want is:
> <root>
> <man id="5">
> <man_name>john doe</man_name>
> <man_nt_name>jdxyz</man_nt_name>
> <man_size>large</man_size>
> </man>
> <man id="7">
> <man_name>fred Doe</man_name>
> <man_nt_name>fdabc</man_nt_name>
> <man_size>size</man_size>
> </man>
> </root>
Code up that XML, use XMLin on it, and the use Data::Dumper to print it
out. A bit of tuning with things like "forcearray" and "keyattr" and
you'll probably get a Perl structure that you can use as you wish
(though maybe not what you've currently got). You can assume that
XMLout will re-write the XML in the right way (but not, as in a recent
discussion, necessarily with the same arrangement of text, attributes
and white space).
Give that a try and see how you get on. This is not a rude put-down:
your question is a perfectly sensible one but this, in my experience, is
the best way to set about getting what you want.
--
Henry Law Manchester, England
------------------------------
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 3563
***************************************
