[28068] in Perl-Users-Digest
Perl-Users Digest, Issue: 9432 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 6 21:05:47 2006
Date: Thu, 6 Jul 2006 18:05:05 -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: 9432
Today's topics:
Accepting XML input <bill@ts1000.us>
Re: Accepting XML input <mritty@gmail.com>
Re: Accepting XML input <glex_no-spam@qwest-spam-no.invalid>
Re: Accepting XML input <tadmc@augustmail.com>
Re: Get the reference to an array from a function... <mritty@gmail.com>
Getting Net::SFTP handle takes FOR-FLIPPIN-EVER usenet@DavidFilmer.com
How to make env-vars effective on return from perl modu <owen@uvsoftware.ca>
I made my first real perl script ilikesluts@gmail.com
Re: I made my first real perl script usenet@DavidFilmer.com
Re: I made my first real perl script krakle@visto.com
Re: I made my first real perl script usenet@DavidFilmer.com
Re: perl to fortran thoughts xhoster@gmail.com
Re: perl to fortran thoughts <usenet@technologydynamics.com>
Re: perl to fortran thoughts axel@white-eagle.invalid.uk
Re: perl to fortran thoughts axel@white-eagle.invalid.uk
Re: Question on characterposition on a line axel@white-eagle.invalid.uk
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 6 Jul 2006 12:09:22 -0700
From: "Bill H" <bill@ts1000.us>
Subject: Accepting XML input
Message-Id: <1152212962.280711.163100@p79g2000cwp.googlegroups.com>
Can anyone point me to some documentation and / or examples on how to
process XML input using perl on a web server and then generating XML
output?
The scenerio is that a website will be passing XML input to perl code
running on my server, my perl program will process that input and then
send back results in XML
Bill H www.ts1000.us
------------------------------
Date: 6 Jul 2006 12:17:47 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: Accepting XML input
Message-Id: <1152213467.840462.162510@s16g2000cws.googlegroups.com>
Bill H wrote:
> Can anyone point me to some documentation and / or examples on how to
> process XML input using perl on a web server and then generating XML
> output?
>
> The scenerio is that a website will be passing XML input to perl code
> running on my server, my perl program will process that input and then
> send back results in XML
Check out the XML::Simple module on CPAN:
http://search.cpan.org/~grantm/XML-Simple-2.14/lib/XML/Simple.pm
Only two real functions you have to know: XMLin() and XMLout().
XMLin() takes your XML string and gives you a Perl data structure to
manipulate however you choose. XMLout() takes a Perl data structure,
and produces the corresponding XML string.
Paul Lalli
------------------------------
Date: Thu, 06 Jul 2006 14:32:35 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Accepting XML input
Message-Id: <Fxdrg.5$eF6.925@news.uswest.net>
Bill H wrote:
> Can anyone point me to some documentation and / or examples on how to
> process XML input using perl on a web server and then generating XML
> output?
>
> The scenerio is that a website will be passing XML input to perl code
> running on my server, my perl program will process that input and then
> send back results in XML
You don't mention how the XML will be passed to your "perl code" or how
your program will "send back" the results.. I'm assuming you have a CGI
interface.
Take a look at CPAN ( http://search.cpan.org ) or simply use a search
engine and find examples pertaining to your particular server.
Possible modules in CPAN that may help: CGI, XML::Simple, XML::Writer,
possibly SOAP::Lite.
Perl-XML FAQ: http://perl-xml.source-forge.net/faq/
------------------------------
Date: Thu, 6 Jul 2006 14:33:24 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Accepting XML input
Message-Id: <slrneaqpc4.hdv.tadmc@magna.augustmail.com>
Bill H <bill@ts1000.us> wrote:
> Can anyone point me to some documentation and / or examples on how to
> process XML input using perl on a web server and then generating XML
> output?
http://search.cpan.org/search?q=XML
See also:
http://lists.perl.org/showlist.cgi?name=perl-xml
> The scenerio is that a website will be passing XML input to perl code
> running on my server, my perl program will process that input and then
> send back results in XML
Sounds like a Web Service. There are CPAN modules to help with that too.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 6 Jul 2006 11:55:22 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: Get the reference to an array from a function...
Message-Id: <1152212121.944219.85310@p79g2000cwp.googlegroups.com>
howa wrote:
> John W. Krahn =E5=AF=AB=E9=81=93=EF=BC=9A
> > test() returns a list and \test() will return a list of references to t=
he
> > items in the original list. Only the last item will be stored in the s=
calar
> > because that is the way that scalar assignment works with a list.
> >
> >>\test() will return a list of references to the items in the original l=
ist.>
> in fact, what does "\test()" means as it is not the reference to the
> list returning from the function?
It means exactly what John said: it would return a list of references
to the items. That is, if the items are ($x, $y, $z), then \($x, $y,
$z) is the same as (\$x, \$y, \$z). But since you were calling \test()
in a scalar context, you were effectively doing:
$test =3D (\$x, \$y, \$z);
In scalar context, the comma operator returns its right-most element.
In this case, that's \$z. In your case, that's a reference to the
value 3.
Please note there is no such thing as a "reference to a list".
Paul Lalli
------------------------------
Date: 6 Jul 2006 17:34:57 -0700
From: usenet@DavidFilmer.com
Subject: Getting Net::SFTP handle takes FOR-FLIPPIN-EVER
Message-Id: <1152232497.821120.111880@s26g2000cwa.googlegroups.com>
Kindly consider the following script which I am having a problem with:
#!/usr/bin/perl
use strict; use warnings;
use Net::SFTP;
my %args = qw{ user myuserid password mypassword debug 1 };
$args{'ssh_args'} = [protocol => 2];
my $sftp = Net::SFTP->new('123.456.78.90', %args) or die $!;
__END__
The script works fine, but on one particular machine it takes about a
minute to get the SFTP handle. The identical script runs instantly on
another (inferior) machine.
So, naturally, I would suspect a problem with that particular machine
that would have nothing to do with my script (maybe a routing issue,
etc), EXCEPT two things make me think the problem somehow involves the
Net::SFTP module itself:
1. "sftp" from a shell (same parameters) connects instantly.
2. I can get a Net::SSH::Perl handle (same %args) instantly.
With debug mode turned on, I observe that there are long pauses at
three points. I've posted the debug output (with pauses indicated)
below. I see no obvious reason for any performance problems (I'm
running on a new and lightly loaded p520 (POWER5) AIX box). As I said,
I can get a Net::SSH::Perl handle instantly (and Net::SFTP uses N:S:P).
If anyone has any suggestions on what the problem might be with using
Net::SFTP from this particular machine, please let me know. Here's my
Net::SFTP debug output (with pauses indicated):
server: Reading configuration data /myuserid/.ssh/config
server: Reading configuration data /etc/ssh_config
server: Connecting to server123.mycompany.com, port 22.
server: Remote protocol ver 1.99, remote ver OpenSSH_3.6.1p2
server: Net::SSH::Perl Version 1.29, protocol version 2.0.
server: No compat match: OpenSSH_3.6.1p2.
server: Connection established.
server: Sent key-exchange init (KEXINIT), wait response.
server: Algorithms, c->s: 3des-cbc hmac-sha1 none
server: Algorithms, s->c: 3des-cbc hmac-sha1 none
>>long pause........................................................
server: Entering Diffie-Hellman Group 1 key exchange.
server: Sent DH public key, waiting for reply.
server: Received host key, type 'ssh-dss'.
server: Host 'server123.mycompany.com' is known and matches host key
server: Computing shared secret key.
>>long pause........................................................
server: Verifying server signature.
>>long pause........................................................
server: Waiting for NEWKEYS message.
server: Enabling incoming encryption/MAC/compression.
server: Send NEWKEYS, enable outgoing encryption/MAC/compression.
server: Sending request for user-authentication service.
server: Service accepted: ssh-userauth.
server: Trying empty user-authentication request.
server: Authentication methods that can continue:
publickey,password,keyboard-interactive.
server: Next method to try is publickey.
server: Next method to try is password.
server: Trying password authentication.
server: Login completed, opening dummy shell channel.
server: channel 0: new [client-session]
server: Requesting channel_open for channel 0.
server: channel 0: open confirm rwindow 0 rmax 32768
Establishing SFTP connection with server server123.mycompany.com:
channel 1: new [client-session]
server: Requesting channel_open for channel 1.
server: Sending subsystem: sftp
server: Requesting service subsystem on channel 1.
server: channel 1: open confirm rwindow 0 rmax 32768
server: sftp: Sending SSH2_FXP_INIT
server: sftp: Remote version: 3
SFTP connected
--
David Filmer (http://DavidFilmer.com)
------------------------------
Date: 6 Jul 2006 17:30:16 -0700
From: "Owen_Townsend" <owen@uvsoftware.ca>
Subject: How to make env-vars effective on return from perl module subrtn ?
Message-Id: <1152232216.861097.126720@p79g2000cwp.googlegroups.com>
How can I make env-vars set in package subrtns effective on return to
perl script ?
I have included testenv1.pl & testexport1.pm below
testenv1.pl calls subrtn exportfile in testexport1.pm to set env-var
LOGICALfilename=PhysicalFileName
- this works for Micro Focus COBOL programs with 'external' on the
select assign statements
- BUT why does it not work for $symbols referenced in the perl script ?
- I specify 'use Env;' which should make env-vars available to perl
script ?
- which works for symbols such as $HOME already set,
- but does not seem to work for $SYMBOLs set in the subrtn
- makes no sense if COBOL can get it (via getenv I assume) why not the
perl script ?
#!/usr/bin/perl
# testenv1 - perl script to test 'use Env'
# - why efective only for symbols already in env
# - why NOT for symbols added to env by script ???
use Env; use testexport1;
print("HOME=$HOME\n"); #<-- 'use Env' works for symbols already defined
exportfile("SORTIN","ar/sales.items"); #<-- subrtn adds SORTIN to env
#=====================================
# - exportfile subrtn adds $SYMBOLS to the environment
# - effective for COBOL which gets symbol defs from environment
# cobrun program <-- my COBOL programs do see $SYMBOLs set in
exportfile subrtn
#===========
# - BUT why are these $SYMBOLS not seen by perl script ? (via 'use
Env;') ?
print("DEBUG1: SORTIN=$SORTIN\n"); #<-- $SORTIN is still null ?
$SORTIN = $ENV{SORTIN}; #<-- redefine here (already done in subrtn)
print("DEBUG2: SORTIN=$SORTIN\n"); #<-- now we see it
exit(0);
#
#-----------------------------------------------------------------------
# testexport1.pm - perl subrtns to support perl scripts converted from
MVS JCL
# - see doc at: www.uvsoftware.ca/mvs2unix.htm
# - export files for Micro Focus COBOL
# - export LOGICAL-filename $SYMBOLS with
physical-filenames
#
# profile should include following so perl modules will be found
# export PERL5LIB=$UV/perlm:$PERL5LIB # perl modules 'use'd by perl
scripts
# ===================================
#
package testexport1;
use Env; Exporter;
our (@Export, @ISA);
@ISA = qw(Exporter);
@EXPORT = qw(exportfile);
#
# exportfile CUSTMAS ap/customer.master #<-- JCL/script call
# =====================================
# export CUSTMAS=ap/customer.master #<-- result
# =================================
#Note - main reason for using this function (vs coding export directly)
# is to display the DDname & DSNname on the console log
#
sub exportfile
{
$lfd=$_[0]; $lbl=$_[1]; # capture args into named variables
#
if ( "$lfd" && "$lbl" ) { ; }
else { print("exportfile requires 2 args: DDNname=$lfd,
DSName=$lbl\n");
exit(81);
}
#
$ENV{$lfd} = "$lbl"; # export LogicalName = PhysicalName
#=================== # COBOL programs need LFD in environment
#
# display lfd & lbl with filesize
$fsize = (-s "$RUNDATA/$lbl");
$fmsg = sprintf("file: %s=%s bytes=%d",$lfd,$lbl,$fsize);
print("$fmsg\n");
return(0);
}
------------------------------
Date: 6 Jul 2006 13:23:31 -0700
From: ilikesluts@gmail.com
Subject: I made my first real perl script
Message-Id: <1152217411.266327.183840@k73g2000cwa.googlegroups.com>
I made my first real perl script for work and I really like perl. It's
easy to use and I can do a lot with it quickly.
------------------------------
Date: 6 Jul 2006 16:43:05 -0700
From: usenet@DavidFilmer.com
Subject: Re: I made my first real perl script
Message-Id: <1152229385.119774.160780@s16g2000cws.googlegroups.com>
ilikesluts@gmail.com wrote:
> I made my first real perl script for work and I really like perl. It's
> easy to use and I can do a lot with it quickly.
Welcome to Perl and to this newsgroup.
Since you are new to both, you probably don't realize that the regular
participants in this particular Perl newsgroup encourage folks to post
messages here in accordance with the group's posting guidelines, which
represent a consensus of this group's regular participants and are
kindly maintained by Tad McClellan for the benefit of the CLPMisc
community. You may read these guidelines here:
http://www.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
I'm glad you found Perl to be easy and effective.
--
David Filmer (http://DavidFilmer.com)
------------------------------
Date: 6 Jul 2006 17:08:49 -0700
From: krakle@visto.com
Subject: Re: I made my first real perl script
Message-Id: <1152230929.242813.288070@k73g2000cwa.googlegroups.com>
usenet@DavidFilmer.com wrote:
> Since you are new to both, you probably don't realize that the regular
> participants in this particular Perl newsgroup encourage folks to post
> messages here in accordance with the group's posting guidelines, which
> represent a consensus of this group's regular participants and are
> kindly maintained by Tad McClellan for the benefit of the CLPMisc
> community. You may read these guidelines here:
> http://www.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
"This newsgroup, commonly called clpmisc, is a technical newsgroup
intended to be used for discussion of Perl related issues (except job
postings), whether it be comments or questions."
Technically his post is a comment about Perl so it falls within the
guidlines set fourth by Superior Perl God & Anti-Social Activist Tad
McClellan...
Anyhoo... Once I saw the thread was by "ilikesluts" I knew it was a
troll...
------------------------------
Date: 6 Jul 2006 17:50:08 -0700
From: usenet@DavidFilmer.com
Subject: Re: I made my first real perl script
Message-Id: <1152233408.315985.180950@s26g2000cwa.googlegroups.com>
krakle@visto.com wrote:
> Technically his post is a comment about Perl so it falls within the guidlines
I wasn't criticizing the post. I only wished to welcome him to the
group (and, perhaps, avoid posts like that in the future...)
> Anyhoo... Once I saw the thread was by "ilikesluts"
I hadn't noticed the handle. Hmmmm. Makes you wonder what line of work
the OP is writing Perl scripts for...
> I knew it was a troll...
Like you?
--
David Filmer (http://DavidFilmer.com)
------------------------------
Date: 06 Jul 2006 18:40:36 GMT
From: xhoster@gmail.com
Subject: Re: perl to fortran thoughts
Message-Id: <20060706144140.997$N1@newsreader.com>
Jim Burns <usenet@technologydynamics.com> wrote:
> >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.
Sure, that is possible, but you probably wouldn't use an associative array
to do it that way.
> 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.
Sure, something like that is also possible, using CGI.pm for example.
> 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.
OK.
> 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?
In an ideal world, sure.
> 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,
Well, understand it well enough to work under a certain restricted set of
circumstances.
> which at least generally dates it with regard
> to any expectation that it's still maintainable and
I have no idea what that means.
> b) if a is true, begs
> the question of why the need for the perl script in the middle,
Maybe there is no need for it but they did it that way because they were
used to writing Perl CGI and not Fortran CGI. Maybe they use the Perl to
format the output or something.
> and c)
> now has the responsibility to parse the input.
Yeah, OK, for sufficiently loose meanings of "responsibility".
> 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.
There is no particular reason to think it is not, and there is no
particular reason to think that it is.
> 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.
I don't think they ever invited you to critique their decision making.
And if the decision was between "slap something together in 2 hours, or
don't do it at all" they very well may have made the right decision.
> After all, they've
> blamed me,
They said the problem was on your end, which is not the same thing as
blaming you. And they are right. Their code works from their form. It
doesn't work from your form. In a perfect world, it would work from your
form, but that doesn't change the fact that the problem is illicited by
your form and not by theirs. Especially consider that we've seen nothing
to suggest that they encourage or welcome other people's forms pointing to
their CGI.
> 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
If you are truly considering their side, then how much validation does it
take that you are asking too much other than them saying that you are
asking 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,
You are justified in assuming they want to provide that service *from their
form*. That is all. Or at least that is all you have shown us.
> so it should not be unacceptable to provide them with constructive
> criticism on that service or how it might be better provided.
You have done so, they responded, and now you are whining here because you
didn't like their response.
> 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.
I haven't consulted the spec either, but it probably isn't wise.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 06 Jul 2006 20:09:09 GMT
From: Jim Burns <usenet@technologydynamics.com>
Subject: Re: perl to fortran thoughts
Message-Id: <bipqa2p9vorg9tsqqkqm1drcp12bvegq6u@4ax.com>
On 06 Jul 2006 18:40:36 GMT, xhoster@gmail.com wrote:
--snip--
I started to answer your comments inline but as I trimmed the reply,
deciding what I wanted to respond to, I found myself realizing you've turned
this thread toward the irrelevant BS you seem to want to bitch about.
Through your replies you've misrepresented, whether intentionally or
ignorantly, the context, full meaning and intention of my remarks. Ignoring
my explanations, you've created your own contexts to discuss points of your
own design and derailed this thread. In contrast, I've found every other
reply helpful, maybe you should take note.
In my conversation it doesn't matter whether they "invited" my critique or
not, you're just being an ass here. Their abbreviated response is not
accurate your drivel on the matter notwithstanding. Of course their code
works on their form, everything balanced just as they expect, I never argued
this but the software is still flawed and to consider fixing it is valid
your philosophizing tripe aside. They don't have to change or fix their
form at all, I've never argued otherwise but a design bug is a design bug
regardless of your blather and they opened further discussion by providing
an inaccurate, or at the very least dismissive response. The difference
between the best decision and a right decision is above your head I see.
>You have done so, they responded, and now you are whining here because you
>didn't like their response.
Actually, I'm not whining at all, I'm just exploring the issue /I/ wanted to
explore. And since I have to make some assumptions about what their real
constraints may be I came here first. And unless you're planning a trip to
Houston and are asking for my address please don't start puffing out your
chest. And unless that's the case, I'm done with you.
/jim
------------------------------
Date: Fri, 07 Jul 2006 00:22:34 GMT
From: axel@white-eagle.invalid.uk
Subject: Re: perl to fortran thoughts
Message-Id: <ePhrg.3523$5K2.1634@fed1read03>
Jim Burns <usenet@technologydynamics.com> wrote:
> 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.
No need to even involve a hash... it just needs a QUERY_STRING
(assuming that method is being used) to be split and the values
then split from the names. From the sounds of it this or something
similar is what is happening.
Have you tried experimenting with the form... e.g. keeping the original
order of the elements and seeing if the application still works?
> 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.
It is obviously a very badly written Perl CGI script and probably has
little or no data verification... which into question its security.
> 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?
Yes and run sanity checks on the data.
> 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.
It sounds as if the Fortran program is a legacy application, perhaps
involved in some heavy number crunching.
I cannot imagine anyone being perverse enough to write a CGI interface
in Fortran since it is a language totally unsuited for this purpose so
(a) is extremely unlikely.
Axel
------------------------------
Date: Fri, 07 Jul 2006 00:44:31 GMT
From: axel@white-eagle.invalid.uk
Subject: Re: perl to fortran thoughts
Message-Id: <P7irg.3524$5K2.1016@fed1read03>
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. 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!
Why should you only expect follow-ups that specifically answer your
questions only?
> 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!
Perhaps you should not post to Usenet if you do not want other people
to make post post-followups that do not specifically answer your
questions or that raise matters that are not of interest to you only.
Xho was perfectly correct in what he said.
Essentially you are using a third-party application which breaks
when you try to change one part of it. Of course you can provide
feedback, but trying to understand exactly how the data is being
processed is not really your concern... it is obviously a proprietary
system and most people have no reason to disclose how such systems
work and very good reasons to keep the workings as a black box to
outsiders... security being one of them.
Axel
------------------------------
Date: Fri, 07 Jul 2006 00:51:05 GMT
From: axel@white-eagle.invalid.uk
Subject: Re: Question on characterposition on a line
Message-Id: <Zdirg.3525$5K2.951@fed1read03>
anno4000@radom.zrz.tu-berlin.de wrote:
> 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 think the OP means print labels onto paper which comes with rows of
three sticky labels.
>> I haven't found a module
>> providing functions like this.
It might well be worth looking at using formats for this sort of job,
since that also allows good vertical control. See:
perldoc perlform
Axel
------------------------------
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 9432
***************************************
