[31265] in Perl-Users-Digest
Perl-Users Digest, Issue: 2510 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jul 8 03:09:44 2009
Date: Wed, 8 Jul 2009 00:09:08 -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 Wed, 8 Jul 2009 Volume: 11 Number: 2510
Today's topics:
Re: how to format output <rabbits77@my-deja.com>
Re: how to format output <rabbits77@my-deja.com>
Re: how to format output <peter@makholm.net>
Re: how to format output <ben@morrow.me.uk>
Re: how to format output <uri@stemsystems.com>
Re: how to format output <tadmc@seesig.invalid>
Re: HTTP::Cookies bug <russgoog@gmail.com>
Re: Perl scalars as numbers or character strings <kst-u@mib.org>
Re: Question on a 'perlsub' statement. (Alan Curry)
Re: Question on a 'perlsub' statement. <ben@morrow.me.uk>
Re: Question on a 'perlsub' statement. <somedeveloper@gmail.com>
Re: Question on a 'perlsub' statement. <uri@stemsystems.com>
WriteExcel module, parsing formula error <dn.perl@gmail.com>
Re: WriteExcel module, parsing formula error <nospam@somewhere.com>
Re: WriteExcel module, parsing formula error <jimsgibson@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 07 Jul 2009 13:50:06 -0400
From: rabbits77 <rabbits77@my-deja.com>
Subject: Re: how to format output
Message-Id: <aa6e1$4a538ad0$c650990a$18816@news.eurofeeds.com>
moonhkt wrote:
> Hi All
>
> How to format output ? I want output format in io2.txt file.
>
>
> $fn="io.txt"; # Input file
> $fout = ">io2.txt"; # Write to file
> $abc="String";
> open ( OUTFILE, $fout);
> open( IN, $fn) or die (" cannot open in.txt for reading: $!");
>
> format HEADER=
> @<<<<<<<<<@<<@<<
> $abc$so_type$code
>
> .
>
> while (my $line = <IN>) {
> print "$line";
> }
>
> print (OUTFILE "Output to file\n");
>
>
> close ( IN ) or die("Cannot close file: $!");
> close (OUTFILE) or die ("Can not close io2.txt");
I have only minimally changed your code. I have
purposely tried to touch what you wrote
as little as possible.
If you elaborate on what you want to do I could help
more.
The default naming convention for a format is that
it match the filehandle.
If you want the format HEADER to really be the
header the default naming convention for that is
to match the format followed by _TOP. In your case
OUTFILE_TOP.
$fn="io.txt"; # Input file
$fout = ">io2.txt"; # Write to file
$abc="String"; # Make sure all your variables
my $line; # used in the format are scoped
# correctly!
open(OUTFILE, $fout);
open(IN, $fn) or die (" cannot open in.txt for
reading: $!");
format OUTFILE_TOP=
@<<<<<<<<<@<<@<<
$abc$so_type$code
.
format OUTFILE=
@<<
$line
.
select(OUTFILE);
while ($line = <IN>) {
write;
}
print (OUTFILE "Output to file\n");
close ( IN ) or die("Cannot close file: $!");
close (OUTFILE) or die ("Can not close io2.txt");
------------------------------
Date: Tue, 07 Jul 2009 14:07:37 -0400
From: rabbits77 <rabbits77@my-deja.com>
Subject: Re: how to format output
Message-Id: <12421$4a538eeb$c650990a$25326@news.eurofeeds.com>
rabbits77 wrote:
> moonhkt wrote:
>> Hi All
>>
>> How to format output ? I want output format in io2.txt file.
>>
>>
>> $fn="io.txt"; # Input file
>> $fout = ">io2.txt"; # Write to file
>> $abc="String";
>> open ( OUTFILE, $fout);
>> open( IN, $fn) or die (" cannot open in.txt for reading: $!");
>>
>> format HEADER=
>> @<<<<<<<<<@<<@<<
>> $abc$so_type$code
>>
>> .
>>
>> while (my $line = <IN>) {
>> print "$line";
>> }
>>
>> print (OUTFILE "Output to file\n");
>>
>>
>> close ( IN ) or die("Cannot close file: $!");
>> close (OUTFILE) or die ("Can not close io2.txt");
>
> I have only minimally changed your code. I have purposely tried to touch
> what you wrote
> as little as possible.
> If you elaborate on what you want to do I could help
> more.
>
> The default naming convention for a format is that it match the filehandle.
> If you want the format HEADER to really be the header the default naming
> convention for that is
> to match the format followed by _TOP. In your case
> OUTFILE_TOP.
Oh, also, I will explicitly note that you need not
use the defaults!
You would change
$FORMAT_NAME(same thing as $~)
and/or
$FORMAT_TOP_NAME(same thing as $^)
A great tutorial and reference for formats is R.
Schwartz's Learning Perl(1st or 2nd edition).
From the third edition onwards formats are not
covered.
If things like $~ and $^ make you giddy than read
more on built in variables.
http://linux.die.net/man/1/perlvar
------------------------------
Date: Tue, 07 Jul 2009 20:37:34 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: how to format output
Message-Id: <8763e41gr5.fsf@vps1.hacking.dk>
rabbits77 <rabbits77@my-deja.com> writes:
> A great tutorial and reference for formats is R.
> Schwartz's Learning Perl(1st or 2nd edition).
> From the third edition onwards formats are not
> covered.
I wonder why?
//Makholm
------------------------------
Date: Tue, 7 Jul 2009 20:25:42 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: how to format output
Message-Id: <m2kci6-l9a.ln1@osiris.mauzo.dyndns.org>
Quoth Peter Makholm <peter@makholm.net>:
> rabbits77 <rabbits77@my-deja.com> writes:
>
> > A great tutorial and reference for formats is R.
> > Schwartz's Learning Perl(1st or 2nd edition).
> > From the third edition onwards formats are not
> > covered.
>
> I wonder why?
Formats are considered deprecated nowadays. There are many better
alternatives on CPAN. If you want the format-style fixed-width picture
approach, I rather like Perl6::Form (which, despite the name, is a
perfectly straightforward Perl 5 module).
Ben
------------------------------
Date: Tue, 07 Jul 2009 15:41:17 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: how to format output
Message-Id: <87vdm4qo0y.fsf@quad.sysarch.com>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> Quoth Peter Makholm <peter@makholm.net>:
>> rabbits77 <rabbits77@my-deja.com> writes:
>>
>> > A great tutorial and reference for formats is R.
>> > Schwartz's Learning Perl(1st or 2nd edition).
>> > From the third edition onwards formats are not
>> > covered.
>>
>> I wonder why?
BM> Formats are considered deprecated nowadays. There are many better
BM> alternatives on CPAN. If you want the format-style fixed-width picture
BM> approach, I rather like Perl6::Form (which, despite the name, is a
BM> perfectly straightforward Perl 5 module).
peter was being sarcastic to rabbit who didn't know why formats weren't
covered in more recent editions of learning perl. :) rabbit keeps
defending them regardless of the real world moving away from them. maybe
he should still use perl4?
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 07 Jul 2009 18:37:26 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: how to format output
Message-Id: <slrnh57mps.r8b.tadmc@tadmc30.sbcglobal.net>
Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
>
> BM> Quoth Peter Makholm <peter@makholm.net>:
> >> rabbits77 <rabbits77@my-deja.com> writes:
> >>
> >> > A great tutorial and reference for formats is R.
> >> > Schwartz's Learning Perl(1st or 2nd edition).
> >> > From the third edition onwards formats are not
> >> > covered.
> >>
> >> I wonder why?
>
> BM> Formats are considered deprecated nowadays. There are many better
> BM> alternatives on CPAN. If you want the format-style fixed-width picture
> BM> approach, I rather like Perl6::Form (which, despite the name, is a
> BM> perfectly straightforward Perl 5 module).
>
> peter was being sarcastic to rabbit who didn't know why formats weren't
> covered in more recent editions of learning perl. :) rabbit keeps
> defending them regardless of the real world moving away from them. maybe
> he should still use perl4?
perl 4 is a wonderful language!
Doesn't have all that confusing "software engineering" stuff
that you boys like so much.
You know nothing!
I am all-knowing!
And I am a professor too!
So there.
PurlBoy
------------------------------
Date: Tue, 7 Jul 2009 14:34:24 -0700 (PDT)
From: Russ in San Diego <russgoog@gmail.com>
Subject: Re: HTTP::Cookies bug
Message-Id: <351ce41f-b30d-4738-9554-e64241ff02b2@l5g2000pra.googlegroups.com>
On Jul 7, 12:12=A0am, Peter Makholm <pe...@makholm.net> wrote:
> Russ in San Diego <russg...@gmail.com> writes:
>
> > Does anyone know whether someone is maintaining HTTP::Cookies? =A0I'm
> > pretty sure I've found a bug, and have a tentative fix for it. =A0I
> > tried emailing the person who is listed as the maintainer (Gisle Aas)
> > at his ActiveState.com email address, but I never received a
> > response.
>
> Have you tried reporting the problem trough the CPAN Request Tracker?
> (rt.cpan.org).
>
> The latest version of HTTP::Cookies is from June 15 and Gisle Aas also
> added some correspondance to the RT at this date. So he is very much
> alive and maintaining the package.
>
> //Makholm
Excellent. I will try reporting this through CPAN.
------------------------------
Date: Tue, 07 Jul 2009 14:08:25 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: Perl scalars as numbers or character strings
Message-Id: <lnws6k19rq.fsf@nuthaus.mib.org>
sln@netherlands.com writes:
> On Mon, 06 Jul 2009 18:26:21 -0700, Keith Thompson <kst-u@mib.org> wrote:
>>sln@netherlands.com writes:
>>> On Mon, 06 Jul 2009 18:16:11 -0400, Uri Guttman
>>> <uri@stemsystems.com> wrote:
>>[...]
>>>>then you have an aversion to most popular languages today. c is still
>>>>used and is useful but it isn't good for dynamic data which is what web
>>>>apps typically need.
>>>
>>> WTF is a Web App, lol !!!!
>>
>><http://lmgtfy.com/?q=web+app>
>>
>>[...]
>
> You know i won't explore any links anybody types here.
> Wanna know why? Cause some jack-off like you points to a page that
> will load my machine with a virus.
Ok, fine. If you really want an answer to your question, go to
www.google.com and type "web app" into the search box, or do the
research in any other manner you like. And your accusation is
unfounded, untrue, and stupid. (I don't deny that some people would
post malicious links; I deny that I would do so or have done so,
and that you have any basis for assuming that I would or did.
> In lieu of a voice, I suggest you recant to yourself just exactly what
> C/C++/api's writtine on them (f***in all of them) are f***ing good for
> you moron.
Quoted text edited for content.
Plonk. (Since you probably won't look that up, it means I'm adding
you to my killfile and am unlikely to see anything you post in the
future.)
--
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: Wed, 8 Jul 2009 00:20:01 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: Question on a 'perlsub' statement.
Message-Id: <h30onh$jl9$1@aioe.org>
In article <slrnh56hun.ksc.tadmc@tadmc30.sbcglobal.net>,
Tad J McClellan <tadmc@seesig.invalid> wrote:
>
>The use of my() is a red herring. my() has no effect on context.
>
> ($foo) = <STDIN>;
> $foo = <STDIN>;
>
>readline() has exactly the same context as when you put a my infront:
>
> my($foo) = <STDIN>;
> my $foo = <STDIN>;
Although I've seen this enough times that it's no longer surprising, I still
find it annoyingly counter-intuitive, and sympathize with those who don't get
it. Let's see if I can explain why.
To understand the comparison made above, you have to see similarity between
this strange pair:
($foo) = <STDIN>;
my($foo) = <STDIN>;
In the first, the left operand of the assignment operator is a parenthesized
expression. In the second, the left operand of the assignment operator is a
function call (by the rule "if it looks like a function, it is a function")
which is not parenthesized. If it was parenthesized, it would look like one
of these:
(my($foo)) = <STDIN>;
(my $foo) = <STDIN>;
It's much harder to accept that the parentheses have an effect reaching all
the way to the other side of the assignment operator, when they are not in
contact with it, and are busy performing an unrelated duty: making the my()
function call look like a function call.
--
Alan Curry
------------------------------
Date: Wed, 8 Jul 2009 02:11:34 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Question on a 'perlsub' statement.
Message-Id: <6b8di6-6mj2.ln1@osiris.mauzo.dyndns.org>
Quoth pacman@kosh.dhis.org (Alan Curry):
> In article <slrnh56hun.ksc.tadmc@tadmc30.sbcglobal.net>,
> Tad J McClellan <tadmc@seesig.invalid> wrote:
> >
> >The use of my() is a red herring. my() has no effect on context.
> >
> > ($foo) = <STDIN>;
> > $foo = <STDIN>;
> >
> >readline() has exactly the same context as when you put a my infront:
> >
> > my($foo) = <STDIN>;
> > my $foo = <STDIN>;
>
> Although I've seen this enough times that it's no longer surprising, I still
> find it annoyingly counter-intuitive, and sympathize with those who don't get
> it. Let's see if I can explain why.
>
> To understand the comparison made above, you have to see similarity between
> this strange pair:
> ($foo) = <STDIN>;
> my($foo) = <STDIN>;
>
> In the first, the left operand of the assignment operator is a parenthesized
> expression. In the second, the left operand of the assignment operator is a
> function call (by the rule "if it looks like a function, it is a function")
No. my (and local) are among the few exceptions to 'if it looks like a
function', which is one reason why I *always* put a space between the
'my' and the open paren. For example, a sub called 'my' will always be
simply ignored, without even a warning. The other syntax keywords like
'if' and 'while' are the same: presumably you don't interpret
if ($x == 1) {
as a function call?
> It's much harder to accept that the parentheses have an effect reaching all
> the way to the other side of the assignment operator, when they are not in
> contact with it, and are busy performing an unrelated duty: making the my()
> function call look like a function call.
The parens are only there to get a list on the LHS of =. It is that list
which changes the behaviour of the RHS, as usual in Perl. The 'function
call' is a red herring.
The only thing here which is *actually* confusing is that
($x) = ...;
makes the LHS into a list of one element, one of the two cases (the
other being the empty list ()) where parens *are* necessary to construct
a list.
Ben
------------------------------
Date: Tue, 7 Jul 2009 21:53:23 -0700 (PDT)
From: SomeDeveloper <somedeveloper@gmail.com>
Subject: Re: Question on a 'perlsub' statement.
Message-Id: <a924b146-c714-48df-98fe-29d182e6cbbc@i18g2000pro.googlegroups.com>
On Jul 7, 6:08=A0pm, Tad J McClellan <ta...@seesig.invalid> wrote:
> SomeDeveloper <somedevelo...@gmail.com> wrote:
> > Hello,
>
> > The following is an excerpt from the 'perlsub' man page (line
> > numbering mine):
>
> > =A0 =A0 =A0 =A0 1. | So
> > =A0 =A0 =A0 =A0 2. | =A0 =A0 =A0 =A0 =A0 =A0my ($foo) =3D <STDIN>; =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0# WRONG?
> > =A0 =A0 =A0 =A0 3. | =A0 =A0 =A0 =A0 =A0 =A0my @FOO =3D <STDIN>;
> > =A0 =A0 =A0 =A0 4. |
> > =A0 =A0 =A0 =A0 5. | =A0 =A0 =A0 =A0both supply a list context to the r=
ight-hand side,
> > while
> > =A0 =A0 =A0 =A0 6. |
> > =A0 =A0 =A0 =A0 7. | =A0 =A0 =A0 =A0 =A0 =A0my $foo =3D <STDIN>;
> > =A0 =A0 =A0 =A0 8. |
> > =A0 =A0 =A0 =A0 9. | =A0 =A0 =A0 =A0supplies a scalar context.
>
> > If on Line 2 a list context is being supplied to the rhs, the I/O
> > operator would read multiple lines. (I verified that it indeed is
> > reading multiple lines.) So far so good.
>
> > Now, once the the input (consisting of multiple lines) stands read,
> > why wouldn't (or rather: shouldn't) this text get assigned in its
> > entirety (complete with '\n' characters) to $foo? Just like the result
> > of join('', <STDIN>) ?
>
> Because the readline (<>) does not know, nor does it need to know,
> where its result is going.
>
> readline() does exactly the same thing (returns a list of all lines
> on the handle) for any of these:
>
> =A0 =A0 my($foo) =3D <STDIN>;
> =A0 =A0 my($foo, $bar) =3D <STDIN>;
> =A0 =A0 my @foo =3D <STDIN>;
> =A0 =A0 join('', <STDIN>);
> =A0 =A0 push @lines, <STDIN>;
> =A0 =A0 print for <STDIN>;
>
> > It appears to me that the list context or scalar context by itself is
> > not sufficient in determining the behavior.
>
> It _is_ sufficient.
>
> > But rather "who or what is
> > providing this context" also matters.
>
> If it behaved as you suggested, _then_ that would matter.
>
> That is, readline() would need to know who/what is providing the
> context before it would know what behavior it should exhibit. It
> would need to know "am i being assigned to a one-item list or not?".
>
> And that is almost surely the reason why it behaves the way it does
> rather than they way you want it to.
>
> > As a user, I was expecting that since parentheses with the 'my'
> > modifier are used only to declare multiple lexicals in one-shot, Line
> > 2 =A0SHOULD essentially HAVE behaved like Line 7.
>
> The use of my() is a red herring. my() has no effect on context.
>
> =A0 =A0 ($foo) =3D <STDIN>;
> =A0 =A0 $foo =3D <STDIN>;
>
> readline() has exactly the same context as when you put a my infront:
>
> =A0 =A0 my($foo) =3D <STDIN>;
> =A0 =A0 my $foo =3D <STDIN>;
>
> --
> Tad McClellan
> email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
Consider this example.
#!/usr/bin/perl
use warnings;
use strict 'vars';
my $x;
print "list context...\n";
($x) =3D <STDIN>; # Here, I must press Ctrl-D explicitly.
print "value =3D '$x'\n";
print "----\n";
print "scalar context...\n";
$x =3D <STDIN>; # Here, control returns after my first <ENTER>.
print "value =3D '$x'\n";
Here's the run...
$ ./misc.pl
list context...
This is line 1 of input.
This is line 2 of input!!!!
value =3D ' This is line 1 of input.
'
----
scalar context...
This is line 1 of input.
value =3D ' This is line 1 of input.
'
I fully understand that 'my' has no effect on scalar vs list context
being provided to the rhs. What I did (and do) not understand is the
semantics. Here's how I thought (and still think) how Perl should've
worked:
1. Perl encounters the statement:
($x) =3D <STDIN>
2. Perl provides a list context to the rhs.
3. The <> operator becomes aware of its list context, and begins
expecting/reading (possibly) multiple lines of input until Ctrl-D is
seen.
4. Perl holds the input read so far in some internal temporary.
5. Perl sees that there is only 1 variable -- $x -- in the list on
the lhs, and so assigns the entire input text to $x, much like the
behavior of join('', <STDIN>).
But, apparently, what is happening in step 5 above is that Perl picks
up only the first line from the text input and discards the rest!
This appears to me to be more than the semantics of an assignment
operator: after the r-value (a multi-line text input) is ready to be
assigned to the l-value (the $x var), Perl kind of intervenes and
parses the first line out of the r-value.
I can obviously re-calibrate my intuition based on this behavior but I
before I did so, I thought I'd try to get some better/logical
rationale of the goings-on here.
(Thanks to all those responded so far.)
------------------------------
Date: Wed, 08 Jul 2009 01:17:34 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Question on a 'perlsub' statement.
Message-Id: <87tz1nn47l.fsf@quad.sysarch.com>
>>>>> "S" == SomeDeveloper <somedeveloper@gmail.com> writes:
S> use warnings;
S> use strict 'vars';
S> my $x;
S> print "list context...\n";
S> ($x) = <STDIN>; # Here, I must press Ctrl-D explicitly.
this reads ALL lines from stdin to eof but only assigns the first one to
$x. each line is passed to perl when you hit enter. you need to hit ^D
to send an eof so perl know it finished reading ALL the lines. then
there is no more data to be read.
S> $x = <STDIN>; # Here, control returns after my first <ENTER>.
this resets eof and reads one line. the line isn't seen by perl until
you hit enter due to unix line buffering. perl sees the one line and
assigns it to $x and continues as you would expect.
nothing odd has happened. you don't seem to understand unix line
buffering or how perl deals with STDIN.
S> I fully understand that 'my' has no effect on scalar vs list context
S> being provided to the rhs. What I did (and do) not understand is the
S> semantics. Here's how I thought (and still think) how Perl should've
S> worked:
S> 1. Perl encounters the statement:
S> ($x) = <STDIN>
S> 2. Perl provides a list context to the rhs.
S> 3. The <> operator becomes aware of its list context, and begins
S> expecting/reading (possibly) multiple lines of input until Ctrl-D is
S> seen.
S> 4. Perl holds the input read so far in some internal temporary.
S> 5. Perl sees that there is only 1 variable -- $x -- in the list on
S> the lhs, and so assigns the entire input text to $x, much like the
S> behavior of join('', <STDIN>).
more like perl reads STDIN and parses it into a list of lines all the
way to seeing EOF (^D). then it assigns the list to ($x) which only
takes the first line and puts it into $x. <> knows only about context
and its input, not how its results get assigned.
S> But, apparently, what is happening in step 5 above is that Perl
S> picks up only the first line from the text input and discards the
S> rest!
no. it reads all of the input and puts it into a list. the list is
assigned to a short list of vars ($x) so it assigns the first line and
discards the rest. <> has NOTHING to do with the discarding, the list
assignment has all to do with it.
look at this:
@x = <> ; # type in input as you did before
($x) = @x ;
the same thing happens and the assignment of all the lines in @x to ($x)
causes only the first line to be assigned to $x. in your example there
just is no @x var to hold the lines. perl holds those lines on the stack
during the assignment to ($x).
S> This appears to me to be more than the semantics of an assignment
S> operator: after the r-value (a multi-line text input) is ready to be
S> assigned to the l-value (the $x var), Perl kind of intervenes and
S> parses the first line out of the r-value.
nope. not parsed at all. each perl op is separated and just passes its
values to the next op. <> reads a line or lines to eof based on
context. those lines are put on the stack and passed to the next op
which is assignment. assignment sees a one element list and assigns the
first element on the stack to that list. no different than this:
($x) = 1 .. 3 ;
$x will be 1 but perl will generate 1,2,3 on the stack first.
S> I can obviously re-calibrate my intuition based on this behavior but I
S> before I did so, I thought I'd try to get some better/logical
S> rationale of the goings-on here.
you are just thinking too much. it is much simpler than you
realize. separate each op and then string them together with the stack
holding intermediate results. most all dynamic langs generally do
this. passing complex context like how many elements to even read or
parse is tricky. perl6 will be able to do this due to lazy lists and
such and it will pass deeper context like list lengths. perl5 doesn't do this.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 7 Jul 2009 13:39:04 -0700 (PDT)
From: "dn.perl@gmail.com" <dn.perl@gmail.com>
Subject: WriteExcel module, parsing formula error
Message-Id: <657cf183-daee-4ea4-aa45-6b81573d7936@a37g2000prf.googlegroups.com>
I am reading a set of strings, and then writing them out to an Excel
sheet using WriteExcel module. Some strings seem to have the format of
a formula, and the module is trying to parse them and failing. I would
like to write the strings as they are, but can live with it if I just
force such strings to be blank and then print them.
if( $subject is problematic ) # $subject =~ m/^=.*=$/ do I
need to trap this condition?
then $subjct = "" ; ==> this will also do.
There are two values for which the statement is failing.
my $normal_format = $workbook->add_format();
A) $subject = "==Contract==" ;
$$rh_worksheet->write( $current_row , $current_col++ ,
$subject , $normal_format ) ;
B) $subject = "=?iso-8859-1?Q?Entrada y registro - =BFC=F3mo cambio mi
contrase=F1a??=" ;
$$rh_worksheet->write( $current_row , $current_col++ ,
$subject , $normal_format ) ;
Even if I print a blank for these problematic subject-strings, my
problem is solved. Being able to print them as they are would be
ideal. When does the module consider a string to be a formula and try
to parse it? If it begins with "=" sign? Or when it begin and ends
with "=" character? Or something else?
Thanks in advance.
------------------------------
Date: Tue, 7 Jul 2009 18:48:57 -0400
From: "Thrill5" <nospam@somewhere.com>
Subject: Re: WriteExcel module, parsing formula error
Message-Id: <h30jl1$3nh$1@news.eternal-september.org>
The module is only a wrapper to access the Excel OLE routines and Excel
treats any cell content that begins with an equal sign as a formula. You
could try quoting the string before adding it to force it to be interpreted
as a string instead of a formula.
$subject = qq("$subject") if ($subject =~ /^=/);
<dn.perl@gmail.com> wrote in message
news:657cf183-daee-4ea4-aa45-6b81573d7936@a37g2000prf.googlegroups.com...
>
> I am reading a set of strings, and then writing them out to an Excel
> sheet using WriteExcel module. Some strings seem to have the format of
> a formula, and the module is trying to parse them and failing. I would
> like to write the strings as they are, but can live with it if I just
> force such strings to be blank and then print them.
>
> if( $subject is problematic ) # $subject =~ m/^=.*=$/ do I
> need to trap this condition?
> then $subjct = "" ; ==> this will also do.
>
> There are two values for which the statement is failing.
>
> my $normal_format = $workbook->add_format();
>
> A) $subject = "==Contract==" ;
> $$rh_worksheet->write( $current_row , $current_col++ ,
> $subject , $normal_format ) ;
>
> B) $subject = "=?iso-8859-1?Q?Entrada y registro - =BFC=F3mo cambio mi
> contrase=F1a??=" ;
> $$rh_worksheet->write( $current_row , $current_col++ ,
> $subject , $normal_format ) ;
>
> Even if I print a blank for these problematic subject-strings, my
> problem is solved. Being able to print them as they are would be
> ideal. When does the module consider a string to be a formula and try
> to parse it? If it begins with "=" sign? Or when it begin and ends
> with "=" character? Or something else?
>
>
> Thanks in advance.
>
------------------------------
Date: Tue, 07 Jul 2009 17:58:33 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: WriteExcel module, parsing formula error
Message-Id: <070720091758339954%jimsgibson@gmail.com>
In article
<657cf183-daee-4ea4-aa45-6b81573d7936@a37g2000prf.googlegroups.com>,
<"dn.perl@gmail.com"> wrote:
> I am reading a set of strings, and then writing them out to an Excel
> sheet using WriteExcel module. Some strings seem to have the format of
> a formula, and the module is trying to parse them and failing. I would
> like to write the strings as they are, but can live with it if I just
> force such strings to be blank and then print them.
Are you talking about the Spreadsheet::WriteExcel module?
If so, then according to the documentation for the write module:
"Excel makes a distinction between data types such as strings, numbers,
blanks, formulas and hyperlinks. To simplify the process of writing
data the write() method acts as a general alias for several more
specific methods:
write_string()
write_number()
write_blank()
write_formula()
write_url()
write_row()
write_col()
The general rule is that if the data looks like a something then a
something is written. Here are some examples in both row-column and A1
notation:"
The documentation then shows that if you use the write method to write
a string that begins with an equal sign, it will use the write_formula
method to write it to the workbook, with these examples:
$worksheet->write('A12', '=A3 + 3*A4' ); # write_formula()
$worksheet->write('A13', '=SIN(PI()/4)' ); # write_formula()
So, you might try forgoing use of the general write method and use the
write_string method instead.
--
Jim Gibson
------------------------------
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 2510
***************************************
