[30518] in Perl-Users-Digest
Perl-Users Digest, Issue: 1761 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 4 17:48:44 2008
Date: Fri, 1 Aug 2008 13:09:13 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 1 Aug 2008 Volume: 11 Number: 1761
Today's topics:
Re: Extracting bits out of huge numbers <rvtol+news@isolution.nl>
Re: Extracting bits out of huge numbers <hjp-usenet2@hjp.at>
Re: FAQ 4.36 How can I expand variables in text strings <npc@zomg.tk>
Re: FAQ 4.36 How can I expand variables in text strings xhoster@gmail.com
Re: FAQ 4.42 How can I tell whether a certain element i <hjp-usenet2@hjp.at>
Re: How do I tell sendmail where to send bounced mail? <John.Smith@invalid.com>
Re: Perl - Gnuplot Topics merritt@chauvet.bmsc.washington.edu
Re: Perl - Gnuplot Topics <RedGrittyBrick@SpamWeary.foo>
Re: Perl - Gnuplot Topics <edgrsprj@ix.netcom.com>
Re: Perl - Gnuplot Topics <edgrsprj@ix.netcom.com>
Re: Perl - Gnuplot Topics merritt@chauvet.bmsc.washington.edu
Re: questions on XML::Simple <hjp-usenet2@hjp.at>
Re: Teradata Perl Connection Question. <glex_no-spam@qwest-spam-no.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 1 Aug 2008 17:44:46 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Extracting bits out of huge numbers
Message-Id: <g6vi2m.ls.1@news.isolution.nl>
Ben Morrow schreef:
> Ruud:
>> sisyphus:
>>> $and = (2 ** 16) + (2 ** 15) + (2 ** 14) + (2 ** 13) + (2 ** 12);
>>
>> Or as Ben Morrow suggested:
>>
>> my $mask = 0;
>> $mask |= 1 << $_ for 12 .. 16;
>
> I particularly don't like using 2**$N for bit operations, as it
> returns a floating-point result.
>
>> or just
>>
>> my $mask = 0x0001_F000;
>
> Well, yes :), but I was assuming the bits to mask in were not known
> until runtime.
Yeah, my "Or" was to be read as "Rather" and my "or just" was to be read
as "or if feasible".
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Fri, 1 Aug 2008 21:45:10 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Extracting bits out of huge numbers
Message-Id: <slrng96pu8.98m.hjp-usenet2@hrunkner.hjp.at>
On 2008-08-01 09:10, Dr.Ruud <rvtol+news@isolution.nl> wrote:
> sisyphus schreef:
>
>> $and = (2 ** 16) + (2 ** 15) + (2 ** 14) + (2 ** 13) + (2 ** 12);
>
> Or as Ben Morrow suggested:
>
> my $mask = 0;
> $mask |= 1 << $_ for 12 .. 16;
Or use the formula used by hofer in his original posting which doesn't
need a loop ;-)
hp
------------------------------
Date: Fri, 1 Aug 2008 17:47:19 +0200 (CEST)
From: npc <npc@zomg.tk>
Subject: Re: FAQ 4.36 How can I expand variables in text strings?
Message-Id: <g6vb67$49j$1@aioe.org>
On Fri, 01 Aug 2008 06:03:03 -0700, PerlFAQ Server wrote:
> 4.36: How can I expand variables in text strings?
I don't understand this faq entry. I'm probably misunderstanding it.
There is no mention of using "" at all. If its bad to use, it should
still be mentioned as being bad to use, and why.
> my $string = sprintf 'Say hello to %s and %s', $foo, $bar;
I'm guessing that using "" is viewed as a bad idea, can someone
enlighten me as to why? How is it worse than using sprintf?
Can "" and/or sprintf be exploited in some way even if I'm not forming
the string to run as an SQL query or system command or similar? is there
some malformed input that the script can take in, which can do something
malicious simply by being expanded into a string?
>
> However, for the one-off simple case where I don't want to pull out
> a full templating system, I'll use a string that has two Perl scalar
> variables in it. In this example, I want to expand $foo and $bar to
> their variable's values:
>
> my $foo = 'Fred';
> my $bar = 'Barney';
> $string = 'Say hello to $foo and $bar';
>
> One way I can do this involves the substitution operator and a
> double "/e" flag. The first "/e" evaluates $1 on the replacement
> side and turns it into $foo. The second /e starts with $foo and
> replaces it with its value. $foo, then, turns into 'Fred', and
> that's finally what's left in the string:
>
> $string =~ s/(\$\w+)/$1/eeg; # 'Say hello to Fred and
> Barney'
At this point I'm thoroughly confused. shall I banish the " key from my
keyboard? is the point to never use it? why?
>
> The "/e" will also silently ignore violations of strict, replacing
> undefined variable names with the empty string. Since I'm using the
> "/e" flag (twice even!), I have all of the same security problems I
> have with "eval" in its string form. If there's something odd in
> $foo, perhaps something like "@{[ system "rm -rf /" ]}", then I
> could get myself in trouble.
This is the only part I grok.
Please help me understand. Thanks.
------------------------------
Date: 01 Aug 2008 19:21:31 GMT
From: xhoster@gmail.com
Subject: Re: FAQ 4.36 How can I expand variables in text strings?
Message-Id: <20080801152133.782$aH@newsreader.com>
npc <npc@zomg.tk> wrote:
> On Fri, 01 Aug 2008 06:03:03 -0700, PerlFAQ Server wrote:
>
> > 4.36: How can I expand variables in text strings?
>
> I don't understand this faq entry. I'm probably misunderstanding it.
>
> There is no mention of using "" at all. If its bad to use, it should
> still be mentioned as being bad to use, and why.
"foo $x bar" is syntactic sugar for 'foo '.$x.'bar'.
So when using "", $x is never *in* the text string as far as perl
is concerned. It just looks like it is. This FAQ is about dynamic
interpolation, where the names (or positions) of the variables can change
during run time.
> > my $string = sprintf 'Say hello to %s and %s', $foo, $bar;
>
> I'm guessing that using "" is viewed as a bad idea, can someone
> enlighten me as to why? How is it worse than using sprintf?
I have no idea. This example doesn't fit the rest of the examples, where
variable names are dynamic. I see no reason to see that the above is
better than "", except that the sprintf argument can come from another
variable rather than being hardcoded.
foo('Say hello to %s and %s');
foo('%s, say hello to %s');
foo(scalar <STDIN>);
sub foo {
sprintf $_[0], $foo, $bar;
}
How would you do this using "" rather than sprintf in the foo sub?
>
> Can "" and/or sprintf be exploited in some way even if I'm not forming
> the string to run as an SQL query or system command or similar? is there
> some malformed input that the script can take in, which can do something
> malicious simply by being expanded into a string?
The goal is here is to give the input the ability to control not just the
values interpolated, but the thing into which they are interpolated.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Fri, 1 Aug 2008 22:00:17 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: FAQ 4.42 How can I tell whether a certain element is contained in a list or array?
Message-Id: <slrng96qqi.98m.hjp-usenet2@hrunkner.hjp.at>
On 2008-08-01 12:38, Justin C <justin.0805@purestblue.com> wrote:
> On 2008-08-01, PerlFAQ Server <brian@stonehenge.com> wrote:
>> 4.42: How can I tell whether a certain element is contained in a list or array?
>>
>> if( $item ~~ %hash )
>> {
>> say "The hash contains $item"
>> }
>
> I don't currently have access to 5.10, so can't check this out, but out
> of interest does the above apply to keys, to values, or to both?
Keys.
hp
------------------------------
Date: Fri, 01 Aug 2008 18:29:31 +0300
From: John <John.Smith@invalid.com>
Subject: Re: How do I tell sendmail where to send bounced mail?
Message-Id: <kqa6941bfhsgjfe1mdmm8dc2cs65afdasv@4ax.com>
scooter <verma.abhinav@gmail.com> wrote:
>
>You need to set the value of "Reply-to" to either a vaild address or
>"no_auto_replies@domain.com" etc.
>
>hth, Abhinav.
I did that with no help :(
Looking at return path of mails with valid recipient I notice that the "Reply-to"
is something that the ISP has and not what I use when sending the email. Could it
be that the ISP changes the headers?
>
>
>On Aug 1, 4:42 pm, John <John.Sm...@invalid.com> wrote:
>> I am using the following code to send email from a Perl script:
>>
>> open(MAIL,"|/usr/sbin/sendmail -t") || return 0;
>> select (MAIL);
>> print "To: mycustomer\@home.com\n";
>> print "From: me\@mybiz.biz\n";
>> print "Return-Path: me\@mybiz.biz\n";
>> print "Subject: Hello world\n";
>> print "\n";
>> print "It works!\n";
>> close(MAIL);
>> select (STDOUT);
>>
>> The code works just fine provided the From address is OK.
>> If the address is invalid (but lexically OK) I want to get a "bounced email
>> receiver is no longer" etc. note but I get nothing.
>>
>> The Return path does not seem to help.
>>
>> What should I do to get info what email bounced or were invalid?
------------------------------
Date: Fri, 1 Aug 2008 08:33:48 -0700 (PDT)
From: merritt@chauvet.bmsc.washington.edu
Subject: Re: Perl - Gnuplot Topics
Message-Id: <g6vacs$qo1$1@chauvet.bmsc.washington.edu>
In article <1PSdnQEBL4PRfg_VnZ2dnUVZ_r7inZ2d@earthlink.com>,
E.D.G. <edgrsprj@ix.netcom.com> wrote:
>If you have a response that contains information for both Perl and Gnuplot
>users then you might post to both groups. Otherwise you should probably
>post responses to just one group or the other.
>
>1. Using Perl And Gnuplot With Windows XP And Windows Vista
>2. Perl And Gnuplot Recommendations
>A. A Formal Perl - Gnuplot Interface
>B. A Real Time Version Of Gnuplot
>3. Perl .exe Program Assistance Needed
>
>1. USING PERL AND GNUPLOT WITH WINDOWS XP AND WINDOWS VISTA
>
>Gnuplot can be a powerful graphics program when used by itself or with Perl
>and probably any of a number of other programming languages. One of the
>advantages of using them together is that both are actively supported. When
>new versions of Perl are developed, older graphics modules might work and
>they might not. But once a Perl - Gnuplot interface is developed, Gnuplot
>programs should work with any Perl updates.
>
>Perl is great for fast, complex calculations and data array management.
>Gnuplot produces high quality graphics and appears to use relatively little
>computer memory.
>
>Using them together can be tricky. It probably took me a year of trying one
>thing or another to determine how to get the two programs to work together
>effectively with both Windows XP and Vista.
I think the operative word there is "Windows". Coordinating perl + gnuplot
is trivially easy on any unix-like system.
>So far I have not had much success with passing information from the Perl
>program to Gnuplot through a pipe. Instead I have been storing data and
>commands in files which Gnuplot then reads.
That is indeed the problem with Windows. Gnuplot is designed to
communicate via pipes, and Windows doesn't support this model well.
>B. A Real Time Version Of Gnuplot
>
>It would be helpful if a version of Gnuplot were developed that would enable
>the user to make small changes to the display screen without the need to
>completely replot all of the data.
All versions of gnuplot for at least the last 10 years have supported this
to some extent. The current development version goes substantially further
in this direction.
>For example, a vertical cursor could
>move one unit to the right or left on the screen. And as it moved Gnuplot
>would replace the original screen data where the cursor was located before
>the move. With simple plots my program combination will move a vertical
>cursor and redraw the entire screen about four times a second. With more
>complex plots the refresh rate slows dramatically and Gnuplot eventually
>crashes.
Gnuplot natively supports mouse/cursor interactions in the display window,
even when driven by an external script. Pressing 'r' in the plot window
toggles a large cross-hair that can be dragged along the plot, for example.
The mouse position in terms of plot coordinates are tracked in real time
and echoed to the bottom of the plot window. None of this requires any
special code on the perl side.
--
Ethan A Merritt
------------------------------
Date: Fri, 01 Aug 2008 17:19:46 +0100
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: Perl - Gnuplot Topics
Message-Id: <489337a4$0$26079$db0fefd9@news.zen.co.uk>
I see E.D.G. has been working on this for many years, using several
different languages and tools consecutively and concurrently. I can see
why a degree of notoriety has been attached to this activity (e.g.
http://www.crank.net/geology.html)
E.D.G. wrote:
> 1. USING PERL AND GNUPLOT WITH WINDOWS XP AND WINDOWS VISTA
>
> Using them together can be tricky. It probably took me a year of
> trying one thing or another to determine how to get the two programs
> to work together effectively with both Windows XP and Vista.
For get Perl to work with some existing program, I'd start by consulting
CPAN. If that proved fruitless, I'd read `perldoc -f system` and
`perldoc -f fork`.
To write a Perl program that interactively drives an external
interactive program, I'd investigate the Expect module.
>
> 2. PERL AND GNUPLOT RECOMMENDATIONS
>
> A. A Formal Perl Gnuplot Interface
>
I had no problem identifying Perl modules for working with
Gnuplot. For example: Graphics::GnuPlotIF and Chart::Graph::Gnuplot.
It seems to me that Perl culture makes it unlikely that anyone will
produce an interface that is usefully more formal than what exists already.
>
> B. A Real Time Version Of Gnuplot
>
> It would be helpful if a version of Gnuplot were developed that would
> enable the user to make small changes to the display screen without
> the need to completely replot all of the data.
AFAIK that is outside the goals of Gnuplot. I think I'd consider other
tools for a desktop application with a GUI that includes a "live"
dynamic graph with a high frame-rate.
>
> 3. PERL .EXE PROGRAM ASSISTANCE NEEDED
>
> Something that I need to learn how to do is create .exe versions of
> my Perl programs
I'd investigate
1) perl2exe
2) perldoc -q "compile my Perl"
This might be an XY problem.
http://www.perlmonks.org/index.pl?node_id=542341
Y = creating a .exe.
X = making a perl application easy to deploy.
--
RGB
I think it very likely that EDG has been given all these suggestions
before, but the lengthy essay in the original posting either didn't
mention them or didn't (for me) clearly say why they proved unsuitable.
Perhaps my reply will benefit other readers who are new to Perl.
------------------------------
Date: Fri, 1 Aug 2008 13:45:12 -0500
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Perl - Gnuplot Topics
Message-Id: <et-dnWKHHb4gxA7VnZ2dnUVZ_g6dnZ2d@earthlink.com>
Thanks for the response.
<merritt@chauvet.bmsc.washington.edu> wrote in message
news:g6vacs$qo1$1@chauvet.bmsc.washington.edu...
>
> I think the operative word there is "Windows". Coordinating perl +
> gnuplot
> is trivially easy on any unix-like system.
>
> That is indeed the problem with Windows. Gnuplot is designed to
> communicate via pipes, and Windows doesn't support this model well.
There is unfortunately no way to avoid using Perl, Gnuplot, and Windows with
this application as it is the operating system used by virtually all of the
scientists, government officials and researchers around the world who would
be using my main Perl program. As I said, I can get it to work sufficiently
well that it does what it needs to do and provides fast, versatile, and
valuable graphics features. But the combination of Perl, Gnuplot, and
Windows is not a perfect match.
> All versions of gnuplot for at least the last 10 years have supported this
> to some extent. The current development version goes substantially
> further
> in this direction.
I thought that I had checked on this before and had no success. The Replot
command won't work here as far as I can see because the Gnuplot program does
not automatically redraw what was erased by the last Replot command.
> Gnuplot natively supports mouse/cursor interactions in the display window,
--
> Ethan A Merritt
The applications I have developed are too complex and require keyboard
monitoring by Perl which then sends instructions to Gnuplot. For example,
after pressing "n," the up and down arrow keys can be used to increase or
decrease the number of line plots displayed on the monitor. "p" combined
with up and down arrow keys causes the all of the line plot displays to
scroll up and down. There are presently many other commands no built into
the program combination. And new commands are quite easy to add.
What results are very powerful Real Time control features that make it look
like Gnuplot is one of those advanced graphics programs used for aircraft
flight simulation for example. The Gnuplot programs themselves are quite
simple. Perl does all of the data manipulation. Gnuplot largely uses its
line, point, and label features to convert Perl data into boarders with tics
on them etc. It is easier to do it that way than try to use Gnuplot's
advanced automatic axis features.
After some investigation I discovered that ActiveState has a Perl
development kit for several hundred dollars that looks like it will create
.exe programs. That would be in my affordability range if it works with
Windows etc. and no problems.
------------------------------
Date: Fri, 1 Aug 2008 14:18:27 -0500
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Perl - Gnuplot Topics
Message-Id: <0YmdnYMya9cY_A7VnZ2dnUVZ_jCdnZ2d@earthlink.com>
"RedGrittyBrick" <RedGrittyBrick@SpamWeary.foo> wrote in message
news:489337a4$0$26079$db0fefd9@news.zen.co.uk...
>I see E.D.G. has been working on this for many years, using several
Many, many research hours have been invested in this program during the past
decade. It took quite a while to get Perl and Gnuplot to work smoothly
together during the past year. But it was well worth the effort. It
replaced generating text data and then manually loading them into an Excel
program that generated charts etc. The new combination is far more powerful
and saves tremendous amounts of time. I am expecting that hundreds,
thousands and perhaps even tens of thousands of researchers around the world
will begin using the finalized program when it becomes available for their
free use.
> For get Perl to work with some existing program, I'd start by consulting
> CPAN. If that proved fruitless, I'd read `perldoc -f system` and
> `perldoc -f fork`.
I did check CPAN but will look again and also check on perldoc -f etc.
> To write a Perl program that interactively drives an external
> interactive program, I'd investigate the Expect module.
I went looking for the Expect module and could not find it. So I will have
to make another try.
> I had no problem identifying Perl modules for working with
> Gnuplot. For example: Graphics::GnuPlotIF and Chart::Graph::Gnuplot.
I will take a look at them and see if they might be helpful.
> AFAIK that is outside the goals of Gnuplot. I think I'd consider other
> tools for a desktop application with a GUI that includes a "live"
> dynamic graph with a high frame-rate.
I did an Internet search long ago and looked at a number of programs before
choosing Gnuplot. It appeared to have the best combination of features
including the fact that it is actively supported and has its own Newsgroup.
I would not be opposed to trying a different graphics program if I could
locate one that works as well.
> I'd investigate
> 1) perl2exe
> 2) perldoc -q "compile my Perl"
Those look like good starting points. Also as I said in my other response,
some checking show that ActiveState has a development kit for a few hundred
dollars that is apparently supposed to create .exe programs for you. The
price would be worth it for me if it does what it needs to do.
>
> This might be an XY problem.
> http://www.perlmonks.org/index.pl?node_id=542341
> Y = creating a .exe.
> X = making a perl application easy to deploy.
One reason for occasionally requesting help with the same problem is because
attempts are usually made to solve several at a time. Some of the attempts
are successful and those matters are resolved. The repeats are for attempts
that failed for some reason. So, I am giving them another try. Those
system 'program' and system 'start program' startup procedures for Windows
XP and Vista solved a lot of problems when I finally learned how to get them
working.
------------------------------
Date: Fri, 1 Aug 2008 12:26:02 -0700 (PDT)
From: merritt@chauvet.bmsc.washington.edu
Subject: Re: Perl - Gnuplot Topics
Message-Id: <g6vo0a$t0r$1@chauvet.bmsc.washington.edu>
In article <et-dnWKHHb4gxA7VnZ2dnUVZ_g6dnZ2d@earthlink.com>,
E.D.G. <edgrsprj@ix.netcom.com> wrote:
>Thanks for the response.
>
><merritt@chauvet.bmsc.washington.edu> wrote in message
>news:g6vacs$qo1$1@chauvet.bmsc.washington.edu...
>>
>> I think the operative word there is "Windows". Coordinating perl +
>> gnuplot
>> is trivially easy on any unix-like system.
>>
>
>> That is indeed the problem with Windows. Gnuplot is designed to
>> communicate via pipes, and Windows doesn't support this model well.
>
>There is unfortunately no way to avoid using Perl, Gnuplot, and Windows with
>this application as it is the operating system used by virtually all of the
>scientists, government officials and researchers around the world who would
>be using my main Perl program. As I said, I can get it to work sufficiently
>well that it does what it needs to do and provides fast, versatile, and
>valuable graphics features. But the combination of Perl, Gnuplot, and
>Windows is not a perfect match.
If you have not looked at Octave, you probably should. It manages to drive
gnuplot even under Windows, and whatever tricks they used may be directly
relevant to your application as well.
>> All versions of gnuplot for at least the last 10 years have supported this
>> to some extent. The current development version goes substantially
>> further
>> in this direction.
>
>I thought that I had checked on this before and had no success. The Replot
>command won't work here as far as I can see because the Gnuplot program does
>not automatically redraw what was erased by the last Replot command.
Sorry, I don't follow what you mean by that. In particular I don't follow
what you mean "erased by the last replot command".
Replot does exactly what it sounds like; it re-executes the previous plot
command. You may have changed something in between (view angle, labels,
axis range, position on the canvas, etc). If so, the new plot may overlap
the old one, or sit beside it, or whatever. If you want the lines from the
previous plot to remain, the you tell gnuplot to use "multiplot" mode.
The recent change is to offer an alternative "refresh" command, which does the
same thing but without re-reading the underlying data. This allows it to work
through a pipe, and is needed by recent versions of Octave. It is also
relevant if you are plotting realtime data, where the data may have changed
since the previous plot command. "replot" would use the new data, since
reading from the data source was inherent in the previous command;
"refresh" instead skips this part and re-uses the old data.
[yeah, that may sounds backwards, but the behaviour of "replot" was already
established].
>> Gnuplot natively supports mouse/cursor interactions in the display window,
>
>The applications I have developed are too complex and require keyboard
>monitoring by Perl which then sends instructions to Gnuplot. For example,
>after pressing "n," the up and down arrow keys can be used to increase or
>decrease the number of line plots displayed on the monitor. "p" combined
>with up and down arrow keys causes the all of the line plot displays to
>scroll up and down. There are presently many other commands no built into
>the program combination. And new commands are quite easy to add.
OK, but that could still be programmed in gnuplot itself using the
"bind" command to reassign the meaning of keypress events. I don't know
whether that would result in faster response than doing it at the perl
layer, but you might want to experiment.
>What results are very powerful Real Time control features that make it look
>like Gnuplot is one of those advanced graphics programs used for aircraft
>flight simulation for example. The Gnuplot programs themselves are quite
>simple. Perl does all of the data manipulation. Gnuplot largely uses its
>line, point, and label features to convert Perl data into boarders with tics
>on them etc. It is easier to do it that way than try to use Gnuplot's
>advanced automatic axis features.
I don't know about "easier", since I don't know in detail what your
application needs to do. But you also mentioned a constraint on speed,
and I rather suspect it's faster to use gnuplot built-in operations when
they are available rather than emulating them in the perl layer.
--
Ethan A Merritt
------------------------------
Date: Fri, 1 Aug 2008 21:36:15 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: questions on XML::Simple
Message-Id: <slrng96pdi.98m.hjp-usenet2@hrunkner.hjp.at>
On 2008-07-31 16:49, xhoster@gmail.com <xhoster@gmail.com> wrote:
> Ben Morrow <ben@morrow.me.uk> wrote:
>> Quoth Jeff <dreamgear@gmail.com>:
>> > I used the XML::Simple module to read some xml, which works great.
>> >
>> > But when I write it back out with XMLout.. it's changed.
>> >
>> > For example the input that looks like this:
>> >
>> > <Summary>
>> > <TotalOrders>1</TotalOrders>
>> > <TotalLineItems>4</TotalLineItems>
>> > <TotalQuantity>158</TotalQuantity>
>> > </Summary>
>> >
>> > ends up looking like this:
>> >
>> > <Summary TotalLineItems="4" TotalOrders="1" TotalQuantity="158" />
>> >
>> >
>> > Is it possible to have it written out in the same format it was read
>> > from?
No, because XML::Simple doesn't keep all the necessary information.
>> See the NoAttr option.
>
> Use ForceArray when doing XMLin. I think this would be better than
> using NoAttr on XMLout. With ForceArray things that were attributes on the
> way in are still attributes on the way out, while tags on the way in are
> tags on the way out--rather than turning everything into tags.
Agreed. But it will still not preserve the order of elements:
<Summary>
<TotalLineItems>4</TotalLineItems>
<TotalOrders>1</TotalOrders>
<TotalQuantity>158</TotalQuantity>
</Summary>
hp
------------------------------
Date: Fri, 01 Aug 2008 10:36:57 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Teradata Perl Connection Question.
Message-Id: <48932d99$0$48214$815e3792@news.qwest.net>
Gary wrote:
> smallpond,
>
> Thank you for your reply.
>
> This is what I get when I run test.pl
>
> TdTestBulkload.pm line 4:
>
> This Perl hasn't been configured and built properly for the threads
> module to work. (The 'useithreads' configuration option hasn't been
> used.)
>
> Having threads support requires all of Perl and all of the XS modules
> in
> the Perl installation to be rebuilt, it is not just a question of
> adding
> the threads module. (In other words, threaded and non-threaded Perls
> are binary incompatible.)
>
> If you want to the use the threads module, please contact the people
> who built your Perl.
That seems like a pretty helpful error message.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1761
***************************************
