[28066] in Perl-Users-Digest
Perl-Users Digest, Issue: 9430 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 6 14:10:17 2006
Date: Thu, 6 Jul 2006 11:10:10 -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 Thu, 6 Jul 2006 Volume: 10 Number: 9430
Today's topics:
perl to fortran thoughts <usenet@technologydynamics.com>
Re: perl to fortran thoughts <bart@nijlen.com>
Re: perl to fortran thoughts <boss@gregerhaga.net>
Re: perl to fortran thoughts <boss@gregerhaga.net>
Re: perl to fortran thoughts <usenet@technologydynamics.com>
Re: perl to fortran thoughts <usenet@technologydynamics.com>
Re: perl to fortran thoughts xhoster@gmail.com
Re: perl to fortran thoughts <bart@nijlen.com>
Re: perl to fortran thoughts <usenet@technologydynamics.com>
Re: perl to fortran thoughts <sherm@Sherm-Pendleys-Computer.local>
Re: perl to fortran thoughts xhoster@gmail.com
Re: perl to fortran thoughts <usenet@technologydynamics.com>
Re: Professional IDE for a cross-platform Perl applicat <catdogbeloved@yahoo.com>
Question on characterposition on a line <"v.niekerk at hccnet.nl">
Re: Question on characterposition on a line anno4000@radom.zrz.tu-berlin.de
Re: Question on characterposition on a line khadhar@gmail.com
Re: Question on characterposition on a line <tadmc@augustmail.com>
Re: Question on characterposition on a line <"v.niekerk at hccnet.nl">
Re: Reg: "pattern match read eof" error <ced@blv-sam-01.ca.boeing.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 06 Jul 2006 14:17:48 GMT
From: Jim Burns <usenet@technologydynamics.com>
Subject: perl to fortran thoughts
Message-Id: <7j5qa2ts5728ttth2077rb80rd8lp6em6k@4ax.com>
Hi all,
I need some feedback on an issue. I use a perl script provided by a third
party that processes an html form. When I recreated the html form on my
end, initially identical to the third party form, things worked perfectly.
But then I set out to rearrange the html form elements in a better order on
the web page and the form broke inconsistently.
In chasing down this problem I discovered the form /never/ broke if the html
form elements were in the original order.
Now this has be terribly confused. I've been writing software for 15 yrs
and this immediately bothered me since the UI layers input elements should
have no effect on any backend processing.
But, allowing that I'm not web/cgi/perl expert, I must be missing something
on the technical end here.
My premise is that since any perl script would decode the input to get
access to the $name,$value pairs that make up the html's UI control names
and data, that it was unconscionable that the perl script ignore the UI
control names and process the data in an expected order. This is just
against all best practices in my experience. After all, in a normal
programming environment we don't tend to have data outside variables to hold
on to them with (variables, references, memory addresses).
I wrote the third party nicely asking for help and explaining what I thought
was the problem and the short answer I received was,
I briefly examined this perl script and determined tthat, in
this case, the order is important because the perl is piping
the input directly into a Fortran program, which is doing the
real work.
Ok so the only way I can see this explanation working is if the perl script
is somehow, literally, a mere conduit for the browser input and passes it on
to this fortran program without ever looking at, considering or touching the
data. This would be like using data without the variables that tell us the
type of that data or what that data is for.
Can this be done? I don't think so, can anyone provide some explanation if
so?
And, even so, then aren't we still back at the same point and doesn't my
same assertion hold? If the perl script merely streams the input from the
browser directly into another process then logically one could subtract the
perl script from the analysis and assert that the fortran program should be
properly decoding the input, using the UI element names AND their data and
processing the input properly based on the data name rather than expecting a
certain order.
In the end I just can't seem to justify how this third party can suggest
that it's not good practice at their end to be handling the input in this
way. And I assert there can be no way in which they MUST do it this way.
Thoughts?
If you want to see an example, you can visit,
my page: <http://www.ascentaviation.net/test_sunmoon.php>
their original: <http://aa.usno.navy.mil/data/docs/RS_OneDay.html#forma>
Many, many thanks in advance.
Jim
------------------------------
Date: 6 Jul 2006 08:13:23 -0700
From: "Bart Van der Donck" <bart@nijlen.com>
Subject: Re: perl to fortran thoughts
Message-Id: <1152198803.032881.109960@p79g2000cwp.googlegroups.com>
Jim Burns wrote:
> I need some feedback on an issue. I use a perl script provided by a third
> party that processes an html form. When I recreated the html form on my
> end, initially identical to the third party form, things worked perfectly.
> But then I set out to rearrange the html form elements in a better order on
> the web page and the form broke inconsistently.
> [...]
One workaround is to define 2 forms on your web page: one intended for
screen, and one intended for the submit action. Both forms can then be
populated with elements in the order you like. Something like this:
<!-- form that is submitted -->
<form method="get" action="http://www.google.com/" name="f1">
<input type="hidden" name="year">
<input type="hidden" name="month">
<input type="hidden" name="day">
<input type="hidden" name="state">
<input type="hidden" name="city">
</form>
<!-- form shown on screen -->
<form method="get" onSubmit="return false;" name="f2">
<input type="text" name="day">
<input type="text" name="month">
<input type="text" name="year">
<input type="text" name="city">
<input type="text" name="state">
<input type="button" value="Get data" onClick="
document.forms['f1'].year.value = document.forms['f2'].year.value;
document.forms['f1'].month.value = document.forms['f2'].month.value;
document.forms['f1'].day.value = document.forms['f2'].day.value;
document.forms['f1'].city.value = document.forms['f2'].city.value;
document.forms['f1'].state.value = document.forms['f2'].state.value;
document.forms['f1'].submit();
">
</form>
Hope this helps,
--
Bart
------------------------------
Date: Thu, 06 Jul 2006 18:44:57 +0300
From: Greger <boss@gregerhaga.net>
Subject: Re: perl to fortran thoughts
Message-Id: <f%9rg.15066$D8.8512@reader1.news.jippii.net>
Jim Burns wrote:
> Hi all,
>
> I need some feedback on an issue. I use a perl script provided by a third
> party that processes an html form. When I recreated the html form on my
> end, initially identical to the third party form, things worked perfectly.
> But then I set out to rearrange the html form elements in a better order
> on the web page and the form broke inconsistently.
>
> In chasing down this problem I discovered the form /never/ broke if the
> html form elements were in the original order.
>
> Now this has be terribly confused. I've been writing software for 15 yrs
> and this immediately bothered me since the UI layers input elements should
> have no effect on any backend processing.
>
> But, allowing that I'm not web/cgi/perl expert, I must be missing
> something on the technical end here.
>
> My premise is that since any perl script would decode the input to get
> access to the $name,$value pairs that make up the html's UI control names
> and data, that it was unconscionable that the perl script ignore the UI
> control names and process the data in an expected order. This is just
> against all best practices in my experience. After all, in a normal
> programming environment we don't tend to have data outside variables to
> hold on to them with (variables, references, memory addresses).
>
> I wrote the third party nicely asking for help and explaining what I
> thought was the problem and the short answer I received was,
>
> I briefly examined this perl script and determined tthat, in
> this case, the order is important because the perl is piping
> the input directly into a Fortran program, which is doing the
> real work.
>
> Ok so the only way I can see this explanation working is if the perl
> script is somehow, literally, a mere conduit for the browser input and
> passes it on to this fortran program without ever looking at, considering
> or touching the
> data. This would be like using data without the variables that tell us
> the type of that data or what that data is for.
>
> Can this be done? I don't think so, can anyone provide some explanation
> if so?
>
> And, even so, then aren't we still back at the same point and doesn't my
> same assertion hold? If the perl script merely streams the input from the
> browser directly into another process then logically one could subtract
> the perl script from the analysis and assert that the fortran program
> should be properly decoding the input, using the UI element names AND
> their data and processing the input properly based on the data name rather
> than expecting a certain order.
>
> In the end I just can't seem to justify how this third party can suggest
> that it's not good practice at their end to be handling the input in this
> way. And I assert there can be no way in which they MUST do it this way.
>
> Thoughts?
>
> If you want to see an example, you can visit,
>
> my page: <http://www.ascentaviation.net/test_sunmoon.php>
> their original: <http://aa.usno.navy.mil/data/docs/RS_OneDay.html#forma>
>
>
> Many, many thanks in advance.
>
>
> Jim
if the order of elements really is dependent of the successful outcome of
the fortran program then throw it away. No matter if you POST or GET to the
program the order of parameters should not matter. If you just want to
process a simple form then this is done dead simple in perl, and also php
of course.
--
Qx RSS Reader 1.2.6a released
RSS Reader for Linux.
http://www.gregerhaga.net/qxrss-1.2.6-dox
------------------------------
Date: Thu, 06 Jul 2006 18:45:39 +0300
From: Greger <boss@gregerhaga.net>
Subject: Re: perl to fortran thoughts
Message-Id: <U%9rg.15067$D8.4618@reader1.news.jippii.net>
Greger wrote:
> Jim Burns wrote:
>
>> Hi all,
>>
>> I need some feedback on an issue. I use a perl script provided by a
>> third
>> party that processes an html form. When I recreated the html form on my
>> end, initially identical to the third party form, things worked
>> perfectly. But then I set out to rearrange the html form elements in a
>> better order on the web page and the form broke inconsistently.
>>
>> In chasing down this problem I discovered the form /never/ broke if the
>> html form elements were in the original order.
>>
>> Now this has be terribly confused. I've been writing software for 15 yrs
>> and this immediately bothered me since the UI layers input elements
>> should have no effect on any backend processing.
>>
>> But, allowing that I'm not web/cgi/perl expert, I must be missing
>> something on the technical end here.
>>
>> My premise is that since any perl script would decode the input to get
>> access to the $name,$value pairs that make up the html's UI control names
>> and data, that it was unconscionable that the perl script ignore the UI
>> control names and process the data in an expected order. This is just
>> against all best practices in my experience. After all, in a normal
>> programming environment we don't tend to have data outside variables to
>> hold on to them with (variables, references, memory addresses).
>>
>> I wrote the third party nicely asking for help and explaining what I
>> thought was the problem and the short answer I received was,
>>
>> I briefly examined this perl script and determined tthat, in
>> this case, the order is important because the perl is piping
>> the input directly into a Fortran program, which is doing the
>> real work.
>>
>> Ok so the only way I can see this explanation working is if the perl
>> script is somehow, literally, a mere conduit for the browser input and
>> passes it on to this fortran program without ever looking at, considering
>> or touching the
>> data. This would be like using data without the variables that tell us
>> the type of that data or what that data is for.
>>
>> Can this be done? I don't think so, can anyone provide some explanation
>> if so?
>>
>> And, even so, then aren't we still back at the same point and doesn't my
>> same assertion hold? If the perl script merely streams the input from
>> the browser directly into another process then logically one could
>> subtract the perl script from the analysis and assert that the fortran
>> program should be properly decoding the input, using the UI element names
>> AND their data and processing the input properly based on the data name
>> rather than expecting a certain order.
>>
>> In the end I just can't seem to justify how this third party can suggest
>> that it's not good practice at their end to be handling the input in this
>> way. And I assert there can be no way in which they MUST do it this way.
>>
>> Thoughts?
>>
>> If you want to see an example, you can visit,
>>
>> my page: <http://www.ascentaviation.net/test_sunmoon.php>
>> their original:
>> <http://aa.usno.navy.mil/data/docs/RS_OneDay.html#forma>
>>
>>
>> Many, many thanks in advance.
>>
>>
>> Jim
> if the order of elements really is dependent of the successful outcome of
> the fortran program then throw it away. No matter if you POST or GET to
> the program the order of parameters should not matter. If you just want to
> process a simple form then this is done dead simple in perl, and also php
> of course.
errr, the other way*grin*
--
Qx RSS Reader 1.2.6a released
RSS Reader for Linux.
http://www.gregerhaga.net/qxrss-1.2.6-dox
------------------------------
Date: Thu, 06 Jul 2006 15:52:41 GMT
From: Jim Burns <usenet@technologydynamics.com>
Subject: Re: perl to fortran thoughts
Message-Id: <vbcqa2p13rne1ucu18gtugdblmre4bnc56@4ax.com>
On 6 Jul 2006 08:13:23 -0700, "Bart Van der Donck" <bart@nijlen.com> wrote:
>One workaround is to define 2 forms on your web page: one intended for
>screen, and one intended for the submit action. Both forms can then be
>populated with elements in the order you like. Something like this:
>
Very cool idea, thanks. It doesn't help me understand why the USNO wants to
assert the way it's processing the form MUST be done that way but I like the
workaround.
/jim
------------------------------
Date: Thu, 06 Jul 2006 16:08:49 GMT
From: Jim Burns <usenet@technologydynamics.com>
Subject: Re: perl to fortran thoughts
Message-Id: <elcqa2tdls057088npnl4tjopuomrclld2@4ax.com>
On Thu, 06 Jul 2006 14:17:48 GMT, Jim Burns <usenet@technologydynamics.com>
wrote:
>I need some feedback on an issue. I use a perl script provided by a third
...
>In the end I just can't seem to justify how this third party can suggest
>that it's not good practice at their end to be handling the input in this
>way. And I assert there can be no way in which they MUST do it this way.
Thanks for the responses so far. I replied to my message because in
re-reading it I noticed this error in the above paragraph,
In the end I just can't seem to justify how this third
party can suggest that it is good practice at their end
to be handling the input in this way.
I had my logic backwards.
As far as my complaint and Greger's response goes, I think we're pretty much
seeing it the same way. But, while I usually speak to things directly and
am a stickler for the abolutes of best practices first and the discernment
to known when to bend or break them (rather than the ugly alternative of
sloppy first and tidying up later as needed), I've learned that there's
usually no absolute that usually can't be broken, either by re-thinking or
re-defining something. (see Bart's idea. Neat!)
But I'm just trying to see what I may not be seeing. Could it be simply a
matter of them being dependent upon the ill-designed fortran script without
any power or inclination to fix or modify it? I believe it could be. But I
also received,
Also, we have a very limited staff and resources, so we
cannot allocate much effort to research a problem that
appears to be on your end
which is primarilly what drives me to want to provide a thoughtful response.
So far from what I've been able to determine, it's fundamentally wrong to
suggest it's a problem "at my end."
Thanks for any additional thoughts,
/jim
------------------------------
Date: 06 Jul 2006 16:27:05 GMT
From: xhoster@gmail.com
Subject: Re: perl to fortran thoughts
Message-Id: <20060706122809.471$Ft@newsreader.com>
Jim Burns <usenet@technologydynamics.com> wrote:
> Hi all,
>
> I need some feedback on an issue. I use a perl script provided by a
> third party that processes an html form. When I recreated the html form
> on my end, initially identical to the third party form, things worked
> perfectly. But then I set out to rearrange the html form elements in a
> better order on the web page and the form broke inconsistently.
>
> In chasing down this problem I discovered the form /never/ broke if the
> html form elements were in the original order.
If you hire and pay the programmers, you can fire them for not following
best (or even good) practices. Otherwise, tough tatas. It is what it is.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 6 Jul 2006 09:42:55 -0700
From: "Bart Van der Donck" <bart@nijlen.com>
Subject: Re: perl to fortran thoughts
Message-Id: <1152204175.687331.278490@s26g2000cwa.googlegroups.com>
Jim Burns wrote:
> [...]
> But I'm just trying to see what I may not be seeing. Could it be simply a
> matter of them being dependent upon the ill-designed fortran script without
> any power or inclination to fix or modify it? I believe it could be. But I
> also received,
>
> Also, we have a very limited staff and resources, so we
> cannot allocate much effort to research a problem that
> appears to be on your end
>
> which is primarilly what drives me to want to provide a thoughtful response.
> So far from what I've been able to determine, it's fundamentally wrong to
> suggest it's a problem "at my end."
The problem is not at your end. The Perl script should read out the
offered data by parsing the name/value pairs; and that procedure should
not depend on the order of those pairs (which would be at least risky
IMO).
But there's a chance Perl does the job right. It could maybe go wrong
when Perl passes the data further to the Fortran program. Difficult to
tell without looking at the code, of course.
--
Bart
------------------------------
Date: Thu, 06 Jul 2006 16:49:22 GMT
From: Jim Burns <usenet@technologydynamics.com>
Subject: Re: perl to fortran thoughts
Message-Id: <fcfqa2557ktkkkuqodb7gg7uoq1vqb758v@4ax.com>
On 06 Jul 2006 16:27:05 GMT, xhoster@gmail.com wrote:
>If you hire and pay the programmers, you can fire them for not following
>best (or even good) practices. Otherwise, tough tatas. It is what it is.
Well that's a childish remark. For starters, I'm trying to understand their
response; I'm allowing that they see something I don't. So on that level
alone your response is valueless as it has nothing to do with what I've
actually asked of this group. Great job!
Moreover, there's nothing wrong with me providing feedback to the third
party as to what I see wrong with their script and its form processing.
Again, perfectly valid and acceptable. Which begs the question of whether
sticking your nose in and not contributing to the point is merely for your
warped enjoyment. Again, great job!
/jim
------------------------------
Date: Thu, 06 Jul 2006 13:05:09 -0400
From: Sherm Pendley <sherm@Sherm-Pendleys-Computer.local>
Subject: Re: perl to fortran thoughts
Message-Id: <m2wtaqr7ei.fsf@Sherm-Pendleys-Computer.local>
"Bart Van der Donck" <bart@nijlen.com> writes:
> Jim Burns wrote:
>
>> [...]
>> But I'm just trying to see what I may not be seeing. Could it be simply a
>> matter of them being dependent upon the ill-designed fortran script without
>> any power or inclination to fix or modify it? I believe it could be. But I
>> also received,
>>
>> Also, we have a very limited staff and resources, so we
>> cannot allocate much effort to research a problem that
>> appears to be on your end
>>
>> which is primarilly what drives me to want to provide a thoughtful response.
>> So far from what I've been able to determine, it's fundamentally wrong to
>> suggest it's a problem "at my end."
>
> The problem is not at your end. The Perl script should read out the
> offered data by parsing the name/value pairs; and that procedure should
> not depend on the order of those pairs (which would be at least risky
> IMO).
It sounds to me like the Perl script is written to loop through the request
inputs with something like this:
foreach $input ( @{$req->params} ) {
That is, it sounds like it's getting the list of input names from the form
itself, instead of using a hard-coded list. It also sounds (to me) like the
downstream Fortran app was written to rely on the arbitrary ordering that
happened to appear in the first version of the form.
The *correct* solution would obviously to fix the broken Fortran so that it's
not dependent on the order of the input items. Apparently that's not possible,
maybe even for political, financial or other non-technical reasons.
So, a workaround might be to simply hard-code the list of inputs to pass
along, in the order in which the Fortran app expects them. If you go with
this solution, an explanatory comment is definitely in order! For example:
# Warning! Change this list at your own risk!
# Inputs must be passed to the Fortran app in this exact order
foreach $input ( qw/foo bar baz/ ) {
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: 06 Jul 2006 17:06:38 GMT
From: xhoster@gmail.com
Subject: Re: perl to fortran thoughts
Message-Id: <20060706130743.018$QP@newsreader.com>
Jim Burns <usenet@technologydynamics.com> wrote:
> On 06 Jul 2006 16:27:05 GMT, xhoster@gmail.com wrote:
>
> >If you hire and pay the programmers, you can fire them for not following
> >best (or even good) practices. Otherwise, tough tatas. It is what it
> >is.
>
> Well that's a childish remark.
Ask a childish question...
> For starters, I'm trying to understand
> their response;
What is there to understand? You want them to fix their code, they don't
want to.
> I'm allowing that they see something I don't. So on that
> level alone your response is valueless as it has nothing to do with what
> I've actually asked of this group. Great job!
I answered what seemed to be your question. No, it isn't good practise,
but it is what it is. Isn't that you were asking?
> Moreover, there's nothing wrong with me providing feedback to the third
> party as to what I see wrong with their script and its form processing.
> Again, perfectly valid and acceptable.
Feel free to provide your feedback to them. But why you are providing your
feedback to them to us? We are not them.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 06 Jul 2006 17:48:15 GMT
From: Jim Burns <usenet@technologydynamics.com>
Subject: Re: perl to fortran thoughts
Message-Id: <bdhqa2h3mrqjqlnp96u8gp6c76a7nev32t@4ax.com>
>It sounds to me like the Perl script is written to loop through the request
>inputs with something like this:
>
> foreach $input ( @{$req->params} ) {
>
>That is, it sounds like it's getting the list of input names from the form
>itself, instead of using a hard-coded list. It also sounds (to me) like the
>downstream Fortran app was written to rely on the arbitrary ordering that
>happened to appear in the first version of the form.
>
>The *correct* solution would obviously to fix the broken Fortran so that it's
>not dependent on the order of the input items. Apparently that's not possible,
>maybe even for political, financial or other non-technical reasons.
As I thought about it, not being good with perl, I figured there was a way
via an associative array to peel off the values of the input without regard
to the names of the UI controls, the variables if you will, that provide
context and meaning.
Alternatively, in my limited perl experience, I've also decoded the input
and grabbed BOTH the $name and $value parts of the input. In php I'd simply
refer to $_REQUEST['control_name'] to retrieve the data for that
control_name.
So, even with the fortran, if the perl script decodes the form input but, as
I descibed first, ignores the $name portion, then I still fault the perl
script since whether or not the fortran requires a particular order the perl
script in this case only plays into this by passing the need to handle the
order up to the UI level.
We call on services all the time, be they simply library calls or OS
services, etc. And the order of our parameters to a function matters.
That's not the problem in and of itself. But if the perl script does decode
the input it should've been written to fully pull apart the names and value
from the input (UI) and call the fortran correctly. Right?
Alternatively, based on the response I got, I was allowing that somehow the
perl script was literally doing /nothing/ but passing on the input. Now,
not being an expert in what this data stream really looks like, I'll just
accept it, but then that means the fortran code a) understands the input
from the web browser, which at least generally dates it with regard to any
expectation that it's still maintainable and b) if a is true, begs the
question of why the need for the perl script in the middle, and c) now has
the responsibility to parse the input.
If it's not clear, my /reason/ for writing was to understand the response I
received from them since I have trouble believing it's accurate. Aside from
assuming the third party no longer can maintain the fortran code, is there
anything I may be missing to suggest that what they're telling me doesn't
constitute bad decision making on their end. After all, they've blamed me,
which is as logically short-sighted as attacking me for trying to understand
what's going on here. Quite simply I am considering their side and trying
to find any way which might validate their assertion that it's at my end or,
by implication, that I'm simply asking for too much (i.e. the simpleton
response of "it is what it is"). For them to have come this far in
providing this script but then constrain me to a particular order at the UI
level is not only bad design but constraining. I /am/ able to assume they
/want/ to provide the service since they are, so it should not be
unacceptable to provide them with constructive criticism on that service or
how it might be better provided. Forcing the UI layer to maintain a
specific order to that the data is passed from browser to server in a
particular order is almost offensive. In fact, is it even wise with regard
to the specification that one place a dependency indirectly upon the
browser's form layout by placing a dependency on the order that form data is
passed to the server? I've not consulted the spec on this but I'd guess
it's not.
Thanks,
/jim
------------------------------
Date: 6 Jul 2006 07:55:30 -0700
From: "Bob" <catdogbeloved@yahoo.com>
Subject: Re: Professional IDE for a cross-platform Perl application
Message-Id: <1152197723.025264.236730@b68g2000cwa.googlegroups.com>
My son,
You can go along with your peers, but let me give you a word of advise
before you go. Being right or wrong is not up to you to decide. You may
think to be right, but the facts may prove otherwise. Always look at
the facts first, then judge soundly and be prepared when your judgement
fails or new facts prove you wrong. This happens all the times. Do not
be upset when it does.
Bob
------------------------------
Date: Thu, 06 Jul 2006 11:22:17 +0200
From: Huub <"v.niekerk at hccnet.nl">
Subject: Question on characterposition on a line
Message-Id: <44acd65e$0$8889$e4fe514c@dreader31.news.xs4all.nl>
Hi,
I've been looking on CPAN for a way to determine the position of a
character on a line, but I can't find it. My goal is to print
address-labels with 3 labels horizontally. I haven't found a module
providing functions like this.
Thanks for hints and/or directions,
Huub
------------------------------
Date: 6 Jul 2006 09:44:31 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Question on characterposition on a line
Message-Id: <4h44bvF1p54spU1@news.dfncis.de>
Huub <"v.niekerk at hccnet.nl"> wrote in comp.lang.perl.misc:
> Hi,
>
> I've been looking on CPAN for a way to determine the position of a
> character on a line, but I can't find it.
What does it mean to "determine the character position"? Query
where a certain character will go? Make sure a character goes
into a certain position? Position as in line/column? In pixels?
Characters? Printer points? Inches? Something else entirely?
> My goal is to print
> address-labels with 3 labels horizontally.
Labels with three labels? Should that be "lines"? If so, why do you
need to determine character positions (in whatever sense) for that?
> I haven't found a module
> providing functions like this.
As far as I am concerned, you have entirely failed to make clear what
functions you are looking for.
Anno
------------------------------
Date: 6 Jul 2006 02:48:55 -0700
From: khadhar@gmail.com
Subject: Re: Question on characterposition on a line
Message-Id: <1152179335.171610.37790@m73g2000cwd.googlegroups.com>
Huub wrote:
> Hi,
>
> I've been looking on CPAN for a way to determine the position of a
> character on a line, but I can't find it. My goal is to print
> address-labels with 3 labels horizontally. I haven't found a module
> providing functions like this.
>
> Thanks for hints and/or directions,
>
> Huub
Hi Hubb,
Perl has three functions index(), rindex(), and substr().
I guess you can use any of these.
you can take the line into a variable aas a string and process.
Hope this helps.
Thaufeeq.
------------------------------
Date: Thu, 6 Jul 2006 06:53:06 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Question on characterposition on a line
Message-Id: <slrneapud2.g1g.tadmc@magna.augustmail.com>
Huub <> wrote:
> I've been looking on CPAN for a way to determine the position of a
> character on a line, but I can't find it.
perldoc -f index
> My goal is to print
> address-labels with 3 labels horizontally.
perldoc -f printf
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 06 Jul 2006 14:00:37 +0200
From: Huub <"v.niekerk at hccnet.nl">
Subject: Re: Question on characterposition on a line
Message-Id: <44acfb67$0$8811$e4fe514c@dreader32.news.xs4all.nl>
>
> Hi Hubb,
>
> Perl has three functions index(), rindex(), and substr().
> I guess you can use any of these.
>
> you can take the line into a variable aas a string and process.
>
> Hope this helps.
>
> Thaufeeq.
>
Thank you.
------------------------------
Date: Thu, 6 Jul 2006 08:06:11 GMT
From: Charles DeRykus <ced@blv-sam-01.ca.boeing.com>
Subject: Re: Reg: "pattern match read eof" error
Message-Id: <J1z2IF.5qy@news.boeing.com>
Dinakar wrote:
> Hi,
> I am using the Telnet module for Cisco Routers Testing Automation.
> Recently i am facing an issue with it on one machine. Script is
> quitting the execution printing "pattern match read eof at line 3030".
> Code at line 3030 is "$session->cmd("exit")".
> Here i am exiting from Cisco Router to the Solaris machine.
> The same code is working fine in other solaris machines. It is
> giving the warning "pattern match read eof at line 3030" to the command
> "$session->cmd("exit")". But it is not quitting the execution.
I'd guess the "exit" terminates the Cisco login session so your
Net::Telnet instance no longer finds a prompt and complains.
(In the future, you need to include a minimal amount of code to
demo the problem and provide some context so problems can be
spotted.)
--
Charles DeRykus
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#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 V10 Issue 9430
***************************************
