[32293] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 3560 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Dec 6 21:09:28 2011

Date: Tue, 6 Dec 2011 18:09:08 -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           Tue, 6 Dec 2011     Volume: 11 Number: 3560

Today's topics:
    Re: Command invoked by backticks hangs, silently - bypa <ben@morrow.me.uk>
    Re: Command invoked by backticks hangs, silently - bypa <jurgenex@hotmail.com>
    Re: Command invoked by backticks hangs, silently - bypa <rweikusat@mssgmbh.com>
    Re: Command invoked by backticks hangs, silently - bypa <nospam-abuse@ilyaz.org>
    Re: DBD::SQLite install with PPM, MD5 bootstrap paramet <ben@morrow.me.uk>
    Re: DBD::SQLite install with PPM, MD5 bootstrap paramet <cartercc@gmail.com>
    Re: DBD::SQLite install with PPM, MD5 bootstrap paramet <ben@morrow.me.uk>
    Re: DBD::SQLite install with PPM, MD5 bootstrap paramet <derykus@gmail.com>
    Re: Problem configuring OS/2 for installing CPAN packag <ben@morrow.me.uk>
    Re: Problem configuring OS/2 for installing CPAN packag <nospam-abuse@ilyaz.org>
    Re: Problem configuring OS/2 for installing CPAN packag <ben@morrow.me.uk>
    Re: Problem configuring OS/2 for installing CPAN packag <ben@morrow.me.uk>
    Re: simple xml - change tag name <fajfusio@wp.pl>
    Re: simple xml - change tag name <news@lawshouse.org>
    Re: simple xml - change tag name <ben@morrow.me.uk>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Mon, 05 Dec 2011 20:12:28 -0600
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Command invoked by backticks hangs, silently - bypassed and also solved, sort of
Message-Id: <sKudnRC6kqGR50DTnZ2dnUVZ8tmdnZ2d@bt.com>


Quoth Jürgen Exner <jurgenex@hotmail.com>:
> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> >In <G96dncJlBPUMPEHTnZ2dnUVZ8k2dnZ2d@giganews.com>, on 12/05/2011
> >   at 10:48 AM, Henry Law <news@lawshouse.org> said:
> >
> >>So anyone who finds themselves reading this in future remember: if 
> >>whatever you invoked via backticks talks to you, you won't see what
> >>it  says, and it will just wait for you to answer.
> >
> > `foo 2>bar`
> >
> >Will that capture the prompt?

That depends on whether 'foo' sends the prompt to stdout or stderr. With
a normal Unix shell, that will send stdout to Perl and stderr to a file
called 'bar'.

> I hope it doesn't. After all backticks are explicitely used to capture
> any output of the called process.
> If you don't want that behaviour but want to see the output on the
> screen, then don't use backticks but system().

That invocation sends nothing to the screen (unless foo opens /dev/tty,
or something). Also, a plain `foo` is designed to send foo's stderr to
the screen: that's pretty-much the whole point of stderr.

In Henry's original case, he was running

    `gzip -v ... 2>&1`

gzip prints its prompts to stderr, so if he had run

    `gzip -v ...`

instead the problem would have been immediately obvious. Unfortunately
the -v output goes to stderr as well (because *sometimes* gzip produces
compressed data on stdout), so that would rather defeat the purpose of
the backticks.

The moral of the story: well-behaved commands don't prompt unexpectedly,
*especially* when the file descriptor they're printing their prompts to
isn't connected to a terminal device.

Ben



------------------------------

Date: Tue, 06 Dec 2011 04:24:43 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Command invoked by backticks hangs, silently - bypassed and also solved, sort of
Message-Id: <s42sd7lo5ovq3pnsvfsg0arcsfbsdnj17a@4ax.com>

Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <iorqd7t6s7l731mc4hrrhc2hqrkp5oan9t@4ax.com>, on 12/05/2011
>   at 05:26 PM, J³rgen Exner <jurgenex@hotmail.com> said:
>
>>I hope it doesn't. After all backticks are explicitely used to
>>capture any output of the called process.
>
>Any output, or just STDOUT?

STDOUT

>>If you don't want that behaviour
>
>What behavior? Where is it documented that Perl overrides normal shell
>interpretation of ">" and "|" by the shell?

It doesn't. Backticks will capture whatever at the end of the whole
command still goes to STDOUT. 

And as I have learned in the meantime _THAT_ is the problem with gzip.
So please ignore my comment, apparently it is not applicable to your
specific problem.

jue 


------------------------------

Date: Tue, 06 Dec 2011 13:16:29 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Command invoked by backticks hangs, silently - bypassed and also solved, sort of
Message-Id: <87pqg1q1qq.fsf@sapphire.mobileactivedefense.com>

Ben Morrow <ben@morrow.me.uk> writes:

[...]

> The moral of the story: well-behaved commands don't prompt unexpectedly,
> *especially* when the file descriptor they're printing their prompts to
> isn't connected to a terminal device.

Well-behave programs also shouldn't force a user to confirm that
whatever the requested action will cause to happen should actually be
performed ...


------------------------------

Date: Tue, 6 Dec 2011 22:43:01 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Command invoked by backticks hangs, silently - bypassed and also solved, sort of
Message-Id: <slrnjdt6jk.ptt.nospam-abuse@panda.math.berkeley.edu>

On 2011-12-06, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> [...]
>
>> The moral of the story: well-behaved commands don't prompt unexpectedly,
>> *especially* when the file descriptor they're printing their prompts to
>> isn't connected to a terminal device.
>
> Well-behave programs also shouldn't force a user to confirm that
> whatever the requested action will cause to happen should actually be
> performed ...

I think you are barking at a wrong side of the tree.

  "Well-behave universes have a simple, beautiful, and correct answer to
  any problem."

Ilya


------------------------------

Date: Mon, 05 Dec 2011 20:31:02 -0600
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: DBD::SQLite install with PPM, MD5 bootstrap parameter
Message-Id: <AN2dnctRDp_740DTnZ2dnUVZ8rSdnZ2d@bt.com>


Quoth ccc31807 <cartercc@gmail.com>:
> 
> I've been trying most of the afternoon to get SQLite working with
> Perl. I've got both Perl64 (on Windows 7) and SQLite going, but they
> don't seem to communicate. DBI tells me that the SQLite DBD is
> available but not installed. Yeah.
> 
> Using PPM, I get this message when I try to install DBD::SQLite---
> Synchronizing Database ... done
> DBD-SQLite marked for install
> Installing package ...
>   Downloading DBD-SQLite-1.35 ... done
>   Unpacking DBD-SQLite-1.35 ... done
>   Generating HTML for DBD-SQLite-1.35 ... done
>   Updating files in site area ... failed
> Installing package failed
> ERROR: Digest::MD5 object version 2.51 does not match bootstrap
> parameter 2.36_01
> 
> When I try to installDigest::MD5, I get this message---
> DBD-SQLite unmarked for install
> Digest-MD5 marked for install
> Installing package ...
>   Downloading Digest-MD5-2.51 ... done
>   Unpacking Digest-MD5-2.51 ... done
>   Generating HTML for Digest-MD5-2.51 ... done
>   Updating files in site area ... failed
> Installing package failed
> ERROR: Attempt to reload Digest/MD5.pm aborted.
> Compilation failed in require

Have you tried completely uninstalling Digest::MD5, and then
reinstalling it?

Digest::MD5 consists of three files

    Digest/MD5.pm
    auto/Digest/MD5.bs
    auth/Digest/MD5.dll

of which the second is empty and entirely unimportant. If you untar the
tar.gz ppm is using (or re-download it by hand from the repo) and point
perl at that directory, will it load Digest::MD5? Has PPM somehow got
hold of a corrupted tarball?

If you then go in by hand and put those files in their right places in
your perl installation, does that work? This is not a good long-term
solution, since I don't think PPM will expect those files to be there,
but it may get PPM working long enough to reinstall Digest::MD5
properly.

> I can't use CPAN because my network administrator absolutely forbids
> both make and Mingw, so I seem to be stuck with PPM.

I would strongly recommend against trying to use CPAN.pm with ActivePerl
in any case. I know they've improved support in recent years, but IME
it's still pretty unreliable.

[This is completely general. If you're using a package manager, use it.
If you want to use CPAN.pm, build your own perl. The only exception I
know of is Strawberry Perl, which was designed to use CPAN.pm as its
package manager.]

Ben



------------------------------

Date: Tue, 6 Dec 2011 09:24:40 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: DBD::SQLite install with PPM, MD5 bootstrap parameter
Message-Id: <fd34dfca-702e-4da6-aeb2-2e0f2d1e7939@p16g2000yqd.googlegroups.com>

On Dec 5, 9:31=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:

Ben,

Thanks for your help. I bit the bullet and got Strawberry Perl, and
everything worked out of the box.

I'm on a virtual server, 64 bit, Windows 7, and this has been an
exercise in frustration from the very beginning. I'm no Perl expert,
but I know how to do my job, and I've run into roadblocks every step
of the way. Nothing works, Apache, SQLite, vim, PPM, CPAN, MSTSC,
Firefox, etc. and so on. I've been using these tools for years, and
it's a brave new world where the tools you've used fail.

Thanks again (and forgive my spouting off ... no one at work has any
sympathy.)

CC.


------------------------------

Date: Tue, 06 Dec 2011 11:57:07 -0600
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: DBD::SQLite install with PPM, MD5 bootstrap parameter
Message-Id: <pZCdnW7o_K_uykPTnZ2dnUVZ8jWdnZ2d@bt.com>


Quoth ccc31807 <cartercc@gmail.com>:
> On Dec 5, 9:31 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> 
> Ben,
> 
> Thanks for your help. I bit the bullet and got Strawberry Perl, and
> everything worked out of the box.
> 
> I'm on a virtual server, 64 bit, Windows 7, and this has been an
> exercise in frustration from the very beginning. I'm no Perl expert,
> but I know how to do my job, and I've run into roadblocks every step
> of the way. Nothing works, Apache, SQLite, vim, PPM, CPAN, MSTSC,
> Firefox, etc. and so on. I've been using these tools for years, and
> it's a brave new world where the tools you've used fail.
> 
> Thanks again (and forgive my spouting off ... no one at work has any
> sympathy.)
> 
> CC.




------------------------------

Date: Tue, 6 Dec 2011 10:42:12 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: DBD::SQLite install with PPM, MD5 bootstrap parameter
Message-Id: <7582bcb6-f17d-4fea-b55a-1539ee3ee24c@y12g2000vba.googlegroups.com>

On Dec 5, 6:31=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth ccc31807 <carte...@gmail.com>:
>
>
>
>
>
>
>
>
>
>
>
> > I've been trying most of the afternoon to get SQLite working with
> > Perl. I've got both Perl64 (on Windows 7) and SQLite going, but they
> > don't seem to communicate. DBI tells me that the SQLite DBD is
> > available but not installed. Yeah.
>
> > Using PPM, I get this message when I try to install DBD::SQLite---
> > Synchronizing Database ... done
> > DBD-SQLite marked for install
> > Installing package ...
> > =A0 Downloading DBD-SQLite-1.35 ... done
> > =A0 Unpacking DBD-SQLite-1.35 ... done
> > =A0 Generating HTML for DBD-SQLite-1.35 ... done
> > =A0 Updating files in site area ... failed
> > Installing package failed
> > ERROR: Digest::MD5 object version 2.51 does not match bootstrap
> > parameter 2.36_01
>
> > When I try to installDigest::MD5, I get this message---
> > DBD-SQLite unmarked for install
> > Digest-MD5 marked for install
> > Installing package ...
> > =A0 Downloading Digest-MD5-2.51 ... done
> > =A0 Unpacking Digest-MD5-2.51 ... done
> > =A0 Generating HTML for Digest-MD5-2.51 ... done
> > =A0 Updating files in site area ... failed
> > Installing package failed
> > ERROR: Attempt to reload Digest/MD5.pm aborted.
> > Compilation failed in require
>
> Have you tried completely uninstalling Digest::MD5, and then
> reinstalling it?
>
> Digest::MD5 consists of three files
>
> =A0 =A0 Digest/MD5.pm
> =A0 =A0 auto/Digest/MD5.bs
> =A0 =A0 auth/Digest/MD5.dll
>
> of which the second is empty and entirely unimportant. If you untar the
> tar.gz ppm is using (or re-download it by hand from the repo) and point
> perl at that directory, will it load Digest::MD5? Has PPM somehow got
> hold of a corrupted tarball?
>
> If you then go in by hand and put those files in their right places in
> your perl installation, does that work? This is not a good long-term
> solution, since I don't think PPM will expect those files to be there,
> but it may get PPM working long enough to reinstall Digest::MD5
> properly.
>
> > I can't use CPAN because my network administrator absolutely forbids
> > both make and Mingw, so I seem to be stuck with PPM.
>
> I would strongly recommend against trying to use CPAN.pm with ActivePerl
> in any case. I know they've improved support in recent years, but IME
> it's still pretty unreliable.
>
> [This is completely general. If you're using a package manager, use it.
> If you want to use CPAN.pm, build your own perl. The only exception I
> know of is Strawberry Perl, which was designed to use CPAN.pm as its
> package manager.]
>

Interestingly, I found Strawberry  even provides a
ppm which can access non-CPAN repositories...once
in a while useful for tricky/time-consuming modules:

PPM> set repository activestate http://activestate.com/MSWin32-x64/5.12/120=
0/package.xml
PPM> install Devel::NYTProf
 ...
Installing C:\strawberry\perl\site\lib\auto\Devel\NYTProf\NYTProf.bs

--
Charles DeRykus



------------------------------

Date: Tue, 06 Dec 2011 08:32:07 -0600
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Problem configuring OS/2 for installing CPAN packages
Message-Id: <zMednbgcVOD6ukPTnZ2dnUVZ8uqdnZ2d@bt.com>


Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <OtOdneN9eYaJ6kDTnZ2dnUVZ8kOdnZ2d@bt.com>, on 12/05/2011
>    at 07:59 PM, Ben Morrow <ben@morrow.me.uk> said:
> 
> >Weird. Did you put gcc in your path, or did you edit Config_heavy.pl?
> 
> The latter, to get the gcc in Paul Smedley's build environment.

OK. It *may* be worth putting the entry in Config_heavy.pl back to just
'gcc' and then running the build with U:\usr\bin first in your PATH,
since that seems to be the way Paul did things.

> >If you edited Config_heavy, which slashes did you use?
> 
> \

OK. That ought to be safer than the other way, in this case.

>  cc='U:\usr\bin\gcc.exe'
>  ccname='gcc'
>  cpprun='gcc -E'
>  cppstdin='gcc -E'
>  gccversion='3.3.5 (Bird Build 2007-06-10 14:30)'
>  ld='gcc'
>  libpth='/usr/lib /usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 /extras/lib
> /dev/qt/trunk/lib /openldap/lib /cups/lib'

I presume you have a mapping / -> U:\ set up for kLibc?

>  libspath=' /usr/lib /usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5
> /extras/lib /dev/qt/trunk/lib /openldap/lib /cups/lib'
> 
> config.pm has
> 
>     cc => 'U:\usr\bin\gcc.exe',
>     libpth => 'U:/usr/lib U:/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5
> u:/extras/lib u:/dev/qt/trunk/lib u:/openldap/lib u:/cups/lib',

I don't like the fact that this is different from the _heavy entry, even
if they do end up mapping to the same directory. I also don't know
whether it matters which slashes you use here, but I would *expect* that
true native paths (with backslashes) are always the safest option.

> >Does OS/2 allow you to run a command (from the cmd.exe prompt) 
> >using forward slashes in the path,
> 
> No.
> 
> From your question should I infer that i Need / rather than \ in the
> gcc path?

No, since this is intended to be passed to cmd.exe (in the end)
backslashes are correct.

My current theory (have you worked out yet that I'm mostly just
guessing?) is that, for some as-yet-unknown reason, gcc is invoking
as.exe with forward rather than backslashes in its name, and cmd is
complaining because it doesn't like that. So, things to check:

    - are there any entries in your PATH with forward slashes in?
    - do you have GCC_EXEC_PREFIX set in the environment?

The next thing I would try is setting 

    GCC_EXEC_PREFIX=U:\usr\i386-pc-os2-emx\bin\

(with backslashes, and with a trailing \) in the environment. That ought
to make gcc look exactly there and nowhere else for as.exe. If that
fails (and I don't know which versions of gcc support that env var) then
I would try putting

    cc='u:\usr\bin\gcc.exe -BU:\usr\i386-pc-os2-emx\bin\'

in Config_heavy.pl, to see if that works instead.

At some point you will probably need to take whichever set of changes
worked and apply them to the 'ld' entry as well.

> >Can you run gcc at all?
> 
> I don't know; I haven't tried to configure the one that comes with my
> system.

I don't mean the one that comes with your system, I mean the one perl's
trying to use. If you run

    U:\usr\bin\gcc.exe -o hello.exe hello.c

for some suitable hello.c, do you get a working executable, or does it
yell about being unable to find as.exe?

Ben



------------------------------

Date: Tue, 6 Dec 2011 22:39:56 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Problem configuring OS/2 for installing CPAN packages
Message-Id: <slrnjdt6ds.ptt.nospam-abuse@panda.math.berkeley.edu>

On 2011-12-06, Ben Morrow <ben@morrow.me.uk> wrote:
>> >If you edited Config_heavy, which slashes did you use?
>> 
>> \
>
> OK. That ought to be safer than the other way, in this case.

One should use / in perl on OS/2.

>> >Does OS/2 allow you to run a command (from the cmd.exe prompt) 
>> >using forward slashes in the path,
>> 
>> No.

Yes, it allows it - but one should quote it (same as on Win* - / is
cmd's word separator).

>> From your question should I infer that i Need / rather than \ in the
>> gcc path?

> No, since this is intended to be passed to cmd.exe (in the end)
> backslashes are correct.

cmd.exe has nothing to do with perl on os/2.

Hope this helps,
Ilya


------------------------------

Date: Tue, 06 Dec 2011 19:12:15 -0600
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Problem configuring OS/2 for installing CPAN packages
Message-Id: <IIqdnc1uPtXyIEPTnZ2dnUVZ8rmdnZ2d@bt.com>


Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <zMednbgcVOD6ukPTnZ2dnUVZ8uqdnZ2d@bt.com>, on 12/06/2011
>    at 08:32 AM, Ben Morrow <ben@morrow.me.uk> said:
> 
> >I presume you have a mapping / -> U:\ set up for kLibc?
> 
> No.

 ...OK. You will almost certainly need to change those paths to paths
which actually exist, then.

> >If that fails (and I don't know which versions of gcc support 
> >that env var) then I would try putting
> >    cc='u:\usr\bin\gcc.exe -BU:\usr\i386-pc-os2-emx\bin\'
> 
> Paul's emx or the one that came with my system?

Paul's. It shouldn't matter, since presumably they're both gas and
assembler versions tend to be much less critical than compiler versions,
but sticking to the same tools used to build perl is always safest.

> >I don't mean the one that comes with your system, I mean the one
> >perl's trying to use. If you run
> >    U:\usr\bin\gcc.exe -o hello.exe hello.c
> >for some suitable hello.c, do you get a working executable, or does
> >it yell about being unable to find as.exe?
> 
> Neither:
> 
>  [H:\]U:\usr\bin\gcc.exe -o hello.exe Q:\WATCOM\src\hello.c
>  Q:/WATCOM/src/hello.c: In function `main':
>  Q:/WATCOM/src/hello.c:4: warning: return type of `main' is not `int'
>  gcc.exe: gcc.exe: error executing U:/usr/i386-pc-os2-emx/bin/as.exe:
> No such file or directory

OK, so this part of the problem has nothing to do with perl. Once you've
got that gcc working on its own, it should work from perl. To do that, I
think you probably need to talk to Paul, if you can, or someone else
more familiar with this OS/2 setup than me.

Ben



------------------------------

Date: Tue, 06 Dec 2011 19:19:40 -0600
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Problem configuring OS/2 for installing CPAN packages
Message-Id: <Bd2dnT88cbmxIkPTnZ2dnUVZ8gydnZ2d@bt.com>


Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2011-12-06, Ben Morrow <ben@morrow.me.uk> wrote:
> >> >If you edited Config_heavy, which slashes did you use?
> >> 
> >> \
> >
> > OK. That ought to be safer than the other way, in this case.
> 
> One should use / in perl on OS/2.

Is there some strong reason for that, or is it just to avoid doubling
backslashes in Perl strings?

> >> >Does OS/2 allow you to run a command (from the cmd.exe prompt) 
> >> >using forward slashes in the path,
> >> 
> >> No.
> 
> Yes, it allows it - but one should quote it (same as on Win* - / is
> cmd's word separator).

Interesting. I never knew that...

> >> From your question should I infer that i Need / rather than \ in the
> >> gcc path?
> 
> > No, since this is intended to be passed to cmd.exe (in the end)
> > backslashes are correct.
> 
> cmd.exe has nothing to do with perl on os/2.

Does perl on OS/2 not use cmd for single-arg system? If I were to run
something like

    system "dir >nul";

what would be performing the redirection?

Ben



------------------------------

Date: Tue, 6 Dec 2011 03:24:51 -0800 (PST)
From: Krzysztof Poc <fajfusio@wp.pl>
Subject: Re: simple xml - change tag name
Message-Id: <60cab24b-a28f-4b60-8602-901fd5b50ddf@u5g2000vbd.googlegroups.com>

On Dec 5, 2:51=A0pm, Henry Law <n...@lawshouse.org> wrote:
> On 05/12/11 12:54, Krzysztof Poc wrote:
>
> > Hi
>
> > I would like to change the tag name in an XML document. Can I do that
> > using
> > XML::Simple. If so could you give me a simple example of how to do
> > that.
>
> XML::Simple won't do it directly (the word "rename" doesn't appear in
> its CPAN page!); its main function is to parse some XML and present its
> content as a Perl hash (or the other way round). =A0As you would have
> found if you'd tried it, your XML example will, with default settings,
> turn up like this:
> $somename =3D {
> =A0 =A0 =A0 =A0 =A0 =A0'name' =3D> ' John ',
> =A0 =A0 =A0 =A0 =A0 =A0'age' =3D> ' 25 '
> =A0 =A0 =A0 =A0 =A0};
>
> (where $somename is the variable you used for the XMLin function).
>
> What you want to do isn't hard, given that structure. =A0Something like
> this (untested) would work:
>
> =A0 =A0$somename->{surname} =3D $somename->{name};
> =A0 =A0delete $somename->{name};
>
> If you want to learn some other XML module to do this -- because there's
> more to your problem than you've explained so far, perhaps -- then fire
> away and someone here will help you debug your code. =A0Me, I'd use
> XML::Simple since I'm very familiar with it and the code above isn't
> hard. =A0If I had to do it a lot I might even write a function which got
> invoked like this
>
> rename_hash_key( $somename, { name=3D>'surname', otherkey=3D>'itsnewname'=
} );
>
> --
>
> Henry Law =A0 =A0 =A0 =A0 =A0 =A0Manchester, England

Thanks for help. It works. Unfortunately the output XML does not
resemble the
input XML. The format differs a lot. I used "AttrIndent =3D> 1" and it
still differs a
lot. Can I force Simple::XML to produce exactly the same text format
for output
as for input.

thanks for help


------------------------------

Date: Tue, 06 Dec 2011 14:07:10 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: simple xml - change tag name
Message-Id: <GOydnTqnI7ITvEPTnZ2dnUVZ8nKdnZ2d@giganews.com>

On 06/12/11 11:24, Krzysztof Poc wrote:

> Thanks for help. It works. Unfortunately the output XML does not
> resemble the
> input XML. The format differs a lot. I used "AttrIndent =>  1" and it
> still differs a
> lot. Can I force Simple::XML to produce exactly the same text format
> for output

One significant point about XML is that its textual format doesn't 
matter, at least not in every respect.  For example:

<sometag foo="bar" bar="blatz">
   <anothertag/>
</sometag>

is in XML terms exactly equivalent to

<sometag bar="blatz" foo="bar"><anothertag></anothertag></sometag>

So your exact-equivalence of the text format (a) doesn't really make 
sense, as far as you've explained it; and (b) isn't really the domain of 
an XML parser.

By the way, the POD for XML::Simple says says that it makes certain 
assumptions, including this one:

   You don't want fine-grained control of the formatting of generated XML

That should have told you what you wanted to know, if you'd read it.

-- 

Henry Law            Manchester, England


------------------------------

Date: Tue, 06 Dec 2011 08:42:46 -0600
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: simple xml - change tag name
Message-Id: <UN-dnd0LDr97tEPTnZ2dnUVZ8i2dnZ2d@bt.com>


Quoth Henry Law <news@lawshouse.org>:
> On 06/12/11 11:24, Krzysztof Poc wrote:
> 
> > Thanks for help. It works. Unfortunately the output XML does not
> > resemble the
> > input XML. The format differs a lot. I used "AttrIndent =>  1" and it
> > still differs a
> > lot. Can I force Simple::XML to produce exactly the same text format
> > for output
> 
> One significant point about XML is that its textual format doesn't 
> matter, at least not in every respect.  For example:
> 
> <sometag foo="bar" bar="blatz">
>    <anothertag/>
> </sometag>
> 
> is in XML terms exactly equivalent to
> 
> <sometag bar="blatz" foo="bar"><anothertag></anothertag></sometag>

No it isn't. Whitespace within an element is part of the character data
for that element (after newline normalisation). 

> So your exact-equivalence of the text format (a) doesn't really make 
> sense, as far as you've explained it; and (b) isn't really the domain of 
> an XML parser.

Preserving <foo/> vs. <foo></foo> is not the job of a XML parser.
Passing all the character data, including whitespace, is.

In practice, many applications of XML don't care about whitespace, and
XML::Simple was written for them. But a decent general-purpose XML
parser ought to preserve it.

Ben



------------------------------

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 3560
***************************************


home help back first fref pref prev next nref lref last post