[30615] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 1860 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Sep 17 21:09:42 2008

Date: Wed, 17 Sep 2008 18: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, 17 Sep 2008     Volume: 11 Number: 1860

Today's topics:
    Re: diverting from screen to file <jimsgibson@gmail.com>
    Re: GG diverting from screen to file <RedGrittyBrick@spamweary.invalid>
        language - plea for help (fidokomik\)
    Re: language - plea for help <rvtol+news@isolution.nl>
    Re: language - plea for help <jurgenex@hotmail.com>
        pack and byte length. <fabrice.gautier@gmail.com>
    Re: Perl Strings vs FileHandle <mshadabh@gmail.com>
    Re: Perl Strings vs FileHandle xhoster@gmail.com
    Re: Perl Strings vs FileHandle <someone@example.com>
    Re: Rename of FileName using PERL (fidokomik\)
    Re: Rename of FileName using PERL <ben@morrow.me.uk>
    Re: Requiring Lexical $_ / Obliterating Global $_? <rvtol+news@isolution.nl>
    Re: Requiring Lexical $_ / Obliterating Global $_? <ben@morrow.me.uk>
    Re: web wizard question xhoster@gmail.com
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

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

Date: Wed, 17 Sep 2008 10:21:18 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: diverting from screen to file
Message-Id: <170920081021186393%jimsgibson@gmail.com>

In article
<69003c8f-11d1-45b3-8de7-c217e02c4da7@k37g2000hsf.googlegroups.com>,
cartercc <cartercc@gmail.com> wrote:

> This may be totally off base, but it's a problem I currently face, and
> I don't know where to start. It's not necessarily a Perl problem, but
> it seems like something that Perl was designed to handle (at least in
> theory).
> 
> I have a remote application that is a data source but not a RDBMS. I
> have a local GUI client that connects with the remote application. I
> can use the local client to type in 'queries' which the client relays
> to the remote application and displays the results to the screen.
> Unfortunately, this is entirely transient and I don't have any means
> given by the client to save the results to a file. When I close to
> client, there's nothing left on my machine.
> 
> I would like to divert the stream coming in from the remote
> application to a file. I can confirm that the results are what I want
> and then rerun the 'query' to reproduce the results, but I need to
> have some persistency. The data does reach my local machine, but I
> don't know how to keep it. Any suggestions on where I should start?
> 
> The client is an .exe file, and all I know how to get from trying to
> read the client is an OD of the code. I even tried to disassemble it
> and all I got was an unreadable mess.

Your choices would seem to be: 1. modify the client to save data, 2.
modify the server to save data, or 3. put a "proxy" between the client
and the server.

If you can't do 1. or 2., then 3. is your only hope. Do you know the
protocol that the client uses to communicate with the server? If so,
you write a proxy program that looks like a server to the client and
looks like a client to the server, and it passes data requests from the
actual client to the actual server, and passes back the responses from
the actual server to the actual client.

If you don't know the protocol, then you can try to reverse engineer it
using some sort of packet sniffer, presuming that the communications
protocol is TCP/IP-based. Or you just use a packet sniffer, such as
tcpdump, to record all traffic between the client and server and figure
out how to extract the pertinent data.

This is not an enviable task. If the client/server protocol is a
proprietary one, it might even violate the terms-of-use to which you
have agreed.

Good luck!

-- 
Jim Gibson


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

Date: Wed, 17 Sep 2008 14:22:14 +0100
From: RedGrittyBrick <RedGrittyBrick@spamweary.invalid>
Subject: Re: GG diverting from screen to file
Message-Id: <48d10486$0$2509$da0feed9@news.zen.co.uk>


cartercc wrote:
> This may be totally off base, but it's a problem I currently face, and
> I don't know where to start. It's not necessarily a Perl problem, but
> it seems like something that Perl was designed to handle (at least in
> theory).
> 
> I have a remote application that is a data source but not a RDBMS. I
> have a local GUI client that connects with the remote application. I
> can use the local client to type in 'queries' which the client relays
> to the remote application and displays the results to the screen.
> Unfortunately, this is entirely transient and I don't have any means
> given by the client to save the results to a file. When I close to
> client, there's nothing left on my machine.
> 
> I would like to divert the stream coming in from the remote
> application to a file. I can confirm that the results are what I want
> and then rerun the 'query' to reproduce the results, but I need to
> have some persistency. The data does reach my local machine, but I
> don't know how to keep it. Any suggestions on where I should start?
> 
> The client is an .exe file, and all I know how to get from trying to
> read the client is an OD of the code. I even tried to disassemble it
> and all I got was an unreadable mess.
> 

Ideas:

1) Use wireshark to capture the data. I often find it's "follow TCP 
stream" feature is useful.

2) Create a proxy that sits between the client and server and which 
captures the data you want to "persist". This might be a Perl program or 
it might be something like socat.

http://www.dest-unreach.org/socat/doc/socat.html

   -v
     Writes the transferred data not only to their target streams, but
   also to stderr. The output format is text with some conversions for
   readability, and prefixed with "> " or "< " indicating flow
   directions.

   ...

   socat TCP4-LISTEN:www TCP4:www.domain.org:www

   Installs a simple TCP port forwarder. With TCP4-LISTEN it listens on
   local port "www" until a connection comes in, accepts it, then
   connects to the remote host (TCP4) and starts data transfer. It will
   not accept a second connection.

The docs contain examples for forking proxies and all sorts of 
potentially useful options.


-- 
RGB


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

Date: Wed, 17 Sep 2008 16:07:21 +0200
From: "Petr Vileta \(fidokomik\)" <stoupa@practisoft.cz>
Subject: language - plea for help
Message-Id: <gar2v4$eu$2@adenine.netfront.net>

I'm  writting some multilanguage application (Tbird2OE if you heard about it) 
and I need your help.
I'm trying to get locale language setting on Windows or Linux. On Windows I use

Win32::Locale::get_language()

but this function lie about some languages. For example Czech language should be 
'CZ' but this function return 'CS'.

On Linux I expect 'cs_cz' for Czech language but on some distro I get 'cs_cs'.

Can anybody help me to create conversion table? I want to use national domain 
names for my lanuage files, for example .cz, .de, .dk, .ru ... and '.en' for 
English.

Primarily I need most used world languages: German, French, Spanish ...

Many thanks.
-- 
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail.
Send me your mail from another non-spammer site please.)
Please reply to <petr AT practisoft DOT cz>


-- Posted on news://freenews.netfront.net - Complaints to news@netfront.net --


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

Date: Wed, 17 Sep 2008 16:23:45 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: language - plea for help
Message-Id: <garb6f.1es.1@news.isolution.nl>

Petr Vileta (fidokomik) schreef:

> Win32::Locale::get_language()
> 
> but this function lie about some languages. For example Czech
> language should be 'CZ' but this function return 'CS'.

CS is the iso2 for Czech, so I don't see the problem. 


> Can anybody help me to create conversion table? I want to use
> national domain names for my lanuage files, for example .cz, .de,
> .dk, .ru ... and '.en' for English.

The iso2 for Danish is "da", not "dk". 


I guess that you are confusing country codes and language codes. 

-- 
Affijn, Ruud

"Gewoon is een tijger."


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

Date: Wed, 17 Sep 2008 11:59:26 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: language - plea for help
Message-Id: <2qk2d45ipr1m4q416s31vauq301llkj84e@4ax.com>

"Petr Vileta \(fidokomik\)" <stoupa@practisoft.cz> wrote:
>I'm  writting some multilanguage application (Tbird2OE if you heard about it) 
>and I need your help.
>I'm trying to get locale language setting on Windows or Linux. On Windows I use
>
>Win32::Locale::get_language()
>
>but this function lie about some languages. For example Czech language should be 
>'CZ' but this function return 'CS'.
>
>On Linux I expect 'cs_cz' for Czech language but on some distro I get 'cs_cs'.
>
>Can anybody help me to create conversion table? I want to use national domain 
>names for my lanuage files, for example .cz, .de, .dk, .ru ... and '.en' for 
>English.

You may want to double check your codes. It seems you are confusing
language and country. Those are two very different things although they
might coincide for some locales..

jue


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

Date: Wed, 17 Sep 2008 17:19:04 -0700 (PDT)
From: Fabrice <fabrice.gautier@gmail.com>
Subject: pack and byte length.
Message-Id: <f1e52d4f-6f17-4c02-a6b8-0267a9abac1f@w24g2000prd.googlegroups.com>

Hi,

Whats the proper way to figure out the length , in bytes, of the
result of a pack command ?

That is: I use the pack command then write the result in a file, I
want to know the actual number of bytes written ?

Thanks



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

Date: Wed, 17 Sep 2008 06:37:40 -0700 (PDT)
From: shadabh <mshadabh@gmail.com>
Subject: Re: Perl Strings vs FileHandle
Message-Id: <08378034-a90e-425b-943f-e6c54c2ddcbc@x35g2000hsb.googlegroups.com>

On Sep 6, 6:08=A0pm, "John W. Krahn" <some...@example.com> wrote:
> shadabh wrote:
> > Hi all,
>
> > Just wanted to run this through Perl gurus to see if fit is correct?.
>
> > I have a file that could possibly be 1GB in variable length EBCDIC
> > data. I will read the file as EBCDIC data and based on some criteria
> > split it into 100 different files which will add up to the 1GB. This
> > way a particular copy book can be applied to easy of the split files.
>
> > The approach I am using is a filehandle ( IO::FileHandle and
> > $Strings), substr and write out to 100 different files after applying
> > the 'logic'. I will use two routine, one to read and one to write, I
> > have tested this out with 100MB file and it works fine. The question
> > though is there a memory limit to this, as we are using strings to
> > break the files. Or is there an alternative way to do this?
>
> > Comments, suggestions, improvements and alternatives will really help
> > to design the code. thanks
>
> You have to show us what "this" is first. =A0It is kind of hard to make
> comments, suggestions, improvements and alternatives to something that
> we cannot see.
>
> John
> --
> Perl isn't a toolbox, but a small machine shop where you
> can special-order certain sorts of tools at low cost and
> in short order. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--=
 Larry Wall- Hide quoted text -
>
> - Show quoted text -

Sure. Here is what I meant by 'this way'. Please comment. Thanks

while ($raw_data) {
					$var_len=3D$INIT_LEN+$AC_NUM_LENGTH;
					$val =3D substr $raw_data,$var_len,4;
					$asc_string =3D $val;
					eval '$asc_string =3D~ tr/\000-\377/' . $cp_037 . '/';
#					open(OUTF, '>>ebcdic_ID.txt');
#					#print OUTF $var_len, $asc_string, "\n";
#					close OUTF;
					open(PARM, '<TSY2_PARM.par') || die("Could not open the
parammeter file $PARM_FILE ! File read failed ..check iF file exits");
			   	$parm_data =3D <PARM>;
			   	if
			   	(($parm_data =3D~ m!($asc_string)!g) eq 1)	{
			   		$COPYBOOK_LEN =3D substr $parm_data,length($`)+4,4;
			   		print $COPYBOOK_LEN;
						close (PARM);
						$OUT_DATAFILE =3D 'EBCDIC_'.$asc_string.'.txt';
						$RECORD_LEN=3D $COPYBOOK_LEN+$HEADER_DATA;
						open(OUTF, ">>$OUT_DATAFILE")|| die("Could not open file. File
read failed ..check id file exits");
		      	print OUTF substr $raw_data, $INIT_LEN, $RECORD_LEN;
		      	close OUTF;
						$INIT_LEN =3D $INIT_LEN + $RECORD_LEN;
						print $INIT_LEN;
						print $var_len;
					}
					else  {
						print 'End of file reached or copy book is not a part of the
loading process', "\n";
						exit 0;
					}
}


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

Date: 17 Sep 2008 16:18:57 GMT
From: xhoster@gmail.com
Subject: Re: Perl Strings vs FileHandle
Message-Id: <20080917121859.177$eI@newsreader.com>

shadabh <mshadabh@gmail.com> wrote:
> On Sep 6, 6:08=A0pm, "John W. Krahn" <some...@example.com> wrote:
> > shadabh wrote:
> > > Hi all,
> >
> > > Just wanted to run this through Perl gurus to see if fit is correct?.
> >
> > > I have a file that could possibly be 1GB in variable length EBCDIC
> > > data. I will read the file as EBCDIC data and based on some criteria
> > > split it into 100 different files which will add up to the 1GB. This
> > > way a particular copy book can be applied to easy of the split files.
> >
> > > The approach I am using is a filehandle ( IO::FileHandle and
> > > $Strings), substr and write out to 100 different files after applying
> > > the 'logic'. I will use two routine, one to read and one to write, I
> > > have tested this out with 100MB file and it works fine. The question
> > > though is there a memory limit to this, as we are using strings to
> > > break the files. Or is there an alternative way to do this?

If you are loading the entire file in memory as a giant string, then
you will need enough memory to do so.  My favorite machine has enough
memory to do that with no problem.  We don't know how much memory your
machine has. ...

Where did $raw_data come from?

>
> while ($raw_data) {

As far as I can tell, $raw_data is never modified.  So the loop will be
infinite (or never iterate at all)

And is an indent size of 40 characters really a good idea?

>    $var_len=$INIT_LEN+$AC_NUM_LENGTH;
>    $val = substr $raw_data, $var_len,4;

So maybe do:

while (1) {
   $var_len=$INIT_LEN+$AC_NUM_LENGTH;
   $val = substr $raw_data, $var_len,4;
   last unless 4==length $val;

You do seem to have a conditional exit later on, but why wait until then
when you already know you are at the end?

The rest of the code is hideously difficult to read.  All cap variable
names make my eyes bleed.  So there is only so much time I'm willing to
spend staring at it.

Why reread $parm_data each time through the loop?  You are reading it from
the same file each time, so doesn't it have the same value?

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.


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

Date: Wed, 17 Sep 2008 09:39:06 -0700
From: "John W. Krahn" <someone@example.com>
Subject: Re: Perl Strings vs FileHandle
Message-Id: <HoaAk.5195$PS3.3909@newsfe06.iad>

shadabh wrote:
> On Sep 6, 6:08 pm, "John W. Krahn" <some...@example.com> wrote:
>> shadabh wrote:
>>> Hi all,
>>> Just wanted to run this through Perl gurus to see if fit is correct?.
>>> I have a file that could possibly be 1GB in variable length EBCDIC
>>> data. I will read the file as EBCDIC data and based on some criteria
>>> split it into 100 different files which will add up to the 1GB. This
>>> way a particular copy book can be applied to easy of the split files.
>>> The approach I am using is a filehandle ( IO::FileHandle and
>>> $Strings), substr and write out to 100 different files after applying
>>> the 'logic'. I will use two routine, one to read and one to write, I
>>> have tested this out with 100MB file and it works fine. The question
>>> though is there a memory limit to this, as we are using strings to
>>> break the files. Or is there an alternative way to do this?
>>> Comments, suggestions, improvements and alternatives will really help
>>> to design the code. thanks
>> You have to show us what "this" is first.  It is kind of hard to make
>> comments, suggestions, improvements and alternatives to something that
>> we cannot see.
>>
>> John
>> --
>> Perl isn't a toolbox, but a small machine shop where you
>> can special-order certain sorts of tools at low cost and
>> in short order.                            -- Larry Wall- Hide quoted text -
>>
>> - Show quoted text -
> 
> Sure. Here is what I meant by 'this way'. Please comment. Thanks
> 
> while ($raw_data) {

You don't modify $raw_data inside the loop so there is no point in 
testing it every time through the loop.

>     $var_len=$INIT_LEN+$AC_NUM_LENGTH;

     my $var_len = $INIT_LEN + $AC_NUM_LENGTH;

>     $val = substr $raw_data,$var_len,4;
>     $asc_string = $val;

     my $asc_string = substr $raw_data, $var_len, 4;

>     eval '$asc_string =~ tr/\000-\377/' . $cp_037 . '/';
> #   open(OUTF, '>>ebcdic_ID.txt');
> #   #print OUTF $var_len, $asc_string, "\n";
> #   close OUTF;
>     open(PARM, '<TSY2_PARM.par') || die("Could not open the
> parammeter file $PARM_FILE ! File read failed ..check iF file exits");

You are opening 'TSY2_PARM.par' but your error message says you are 
opening $PARM_FILE.  You should include the $! variable in the error 
message so you know *why* it failed to open.

     open my $PARM, '<', 'TSY2_PARM.par' or die "Could not open 
'TSY2_PARM.par' $!";

>     $parm_data = <PARM>;

You assign the same data to $parm_data every time so...

>     if (($parm_data =~ m!($asc_string)!g) eq 1) {

your pattern will always match at the same place every time through the 
loop so if the pattern is present you have an infinite loop.  You are 
not using the contents of $1 so the parentheses are superfluous.  The 
comparison test to the string '1' is superfluous.

     if ( $parm_data =~ /$asc_string/g ) {

>         $COPYBOOK_LEN = substr $parm_data,length($`)+4,4;

The use of $` is discouraged as it slows down *all* regular expressions 
in your program.

         my $COPYBOOK_LEN = substr $parm_data, $-[ 0 ] + 4, 4;

>         print $COPYBOOK_LEN;
>         close (PARM);
>         $OUT_DATAFILE = 'EBCDIC_'.$asc_string.'.txt';
>         $RECORD_LEN= $COPYBOOK_LEN+$HEADER_DATA;
>         open(OUTF, ">>$OUT_DATAFILE")|| die("Could not open file. File
> read failed ..check id file exits");

         open my $OUTF, '>>', $OUT_DATAFILE or die "Could not open 
'$OUT_DATAFILE' $!";

>         print OUTF substr $raw_data, $INIT_LEN, $RECORD_LEN;
>         close OUTF;
>         $INIT_LEN = $INIT_LEN + $RECORD_LEN;
>         print $INIT_LEN;
>         print $var_len;
>     }
>     else {
>         print 'End of file reached or copy book is not a part of the
> loading process', "\n";
>         exit 0;
>     }
> }

So, to summarise:

open my $PARM, '<', 'TSY2_PARM.par' or die "Could not open the 
parammeter file 'TSY2_PARM.par' $!";
my $parm_data = <$PARM>;
close $PARM;

while ( 1 ) {

     my $var_len = $INIT_LEN + $AC_NUM_LENGTH;
     my $asc_string = substr $raw_data, $var_len, 4;
     eval '$asc_string =~ tr/\000-\377/' . $cp_037 . '/';

     if ( $parm_data =~ /\Q$asc_string\E/g ) {

         my $COPYBOOK_LEN = substr $parm_data, $-[ 0 ] + 4, 4;
         my $OUT_DATAFILE = "EBCDIC_$asc_string.txt";
         my $RECORD_LEN   = $COPYBOOK_LEN + $HEADER_DATA;

         open my $OUTF, '>>', $OUT_DATAFILE or die "Could not open 
'$OUT_DATAFILE' $!";
         print $OUTF substr $raw_data, $INIT_LEN, $RECORD_LEN;
         close $OUTF;

         $INIT_LEN += $RECORD_LEN;
         print $COPYBOOK_LEN, $INIT_LEN, $var_len;
         }
     else {
         print "End of file reached or copy book is not a part of the 
loading process\n";
         last;
         }
     }

exit 0;

__END__


John
-- 
Perl isn't a toolbox, but a small machine shop where you
can special-order certain sorts of tools at low cost and
in short order.                            -- Larry Wall


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

Date: Wed, 17 Sep 2008 15:52:25 +0200
From: "Petr Vileta \(fidokomik\)" <stoupa@practisoft.cz>
Subject: Re: Rename of FileName using PERL
Message-Id: <gar2v2$eu$1@adenine.netfront.net>

Laarni wrote:
> Hi,
> 
> Anyone can help me on this query:
> 
> I need to rename all the files in the directory with this format:
> 
> Original FileName : txn.data
> New File Name : txn.0000000001.data (where 0000000001 come from the
> database table where column is seqquence number. The 0000000001 is
> incrementing)

$oldname = 'txn.data';
$seqnum = '0000000001';
$newname = getnewname($oldname, $seqnum);

sub getnewname
{
my ($old, $seq)=@_;
$old =~ s/^(.+)\.(.+)$/$1\.$seq\.$2/;
return $old;
}

-- 
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail.
Send me your mail from another non-spammer site please.)
Please reply to <petr AT practisoft DOT cz>


-- Posted on news://freenews.netfront.net - Complaints to news@netfront.net --


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

Date: Wed, 17 Sep 2008 15:11:31 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Rename of FileName using PERL
Message-Id: <jpf7q5-9n4.ln1@osiris.mauzo.dyndns.org>


Quoth Laarni <Laarni.Zosa@ubs.com>:
> 
> I need to rename all the files in the directory with this format:

perldoc -f rename
perldoc -f opendir
perldoc -f readdir

> Original FileName : txn.data
> New File Name : txn.0000000001.data (where 0000000001 come from the
> database table where column is seqquence number. The 0000000001 is
> incrementing)

perldoc DBI

Ben

-- 
Heracles: Vulture! Here's a titbit for you / A few dried molecules of the gall
   From the liver of a friend of yours. / Excuse the arrow but I have no spoon.
(Ted Hughes,        [ Heracles shoots Vulture with arrow. Vulture bursts into ]
 'Alcestis')        [ flame, and falls out of sight. ]         ben@morrow.me.uk


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

Date: Wed, 17 Sep 2008 16:38:56 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Requiring Lexical $_ / Obliterating Global $_?
Message-Id: <garc2p.1ko.1@news.isolution.nl>

Tim McDaniel schreef:

> I've never seen
>     for ($some_scalar) {...}
> While I've not read much Perl code written by others, I've not seen it
> in examples either. ... though when looking up something else in
> "man perlsyn", I see it's used there.
>
> It's also not intuitive to me.  I'm used to foreach iterating over a
> list.  My first thought was "you're guaranteed that there's no list.
> Why bother with a 'loop' that you know will run only once?"

What can be wrong with short lists?

The other way around happens to, people writing

   print $string
       . "\n"
   ;

where they could write

   print $string,
         "\n",
   ;

(the above need not be identical, for example when the stringification
of $string is overloaded)

-- 
Affijn, Ruud

"Gewoon is een tijger."



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

Date: Wed, 17 Sep 2008 16:49:00 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Requiring Lexical $_ / Obliterating Global $_?
Message-Id: <cgl7q5-uh8.ln1@osiris.mauzo.dyndns.org>


Quoth "Dr.Ruud" <rvtol+news@isolution.nl>:
> 
> The other way around happens to, people writing
> 
>    print $string
>        . "\n"
>    ;
> 
> where they could write
> 
>    print $string,
>          "\n",
>    ;
> 
> (the above need not be identical, for example when the stringification
> of $string is overloaded)

No, print still stringifies its arguments. However, $, makes them
different.

Ben

-- 
And if you wanna make sense / Whatcha looking at me for?          (Fiona Apple)
                            * ben@morrow.me.uk *


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

Date: 17 Sep 2008 15:51:00 GMT
From: xhoster@gmail.com
Subject: Re: web wizard question
Message-Id: <20080917115101.433$Ra@newsreader.com>

david <michaelgang@gmail.com> wrote:
> On Sep 16, 5:36=A0pm, xhos...@gmail.com wrote:
> > david <michaelg...@gmail.com> wrote:
> >
> > > But in
> > > every step of the wizard i have to give in the html for every control
> > > of the other steps a hidden field
> > > This makes it tedious
> >
> > use CGI;
> > my $cgi=3DCGI->new;
> > #.....
> > print $cgi->hidden('param_name');
> >

(please don't quote sigs.  Sig snipped)

> Thanks, I think this will do the trick. Something like this.
> foreach my $param_name ($cgi->param) {
>           print $cgi->hidden($param_name,$cgi->param($param_name));
> }

I think the below should work:

foreach my $param_name ($cgi->param) {
          print $cgi->hidden($param_name);
}

CGI.pm supports "sticky fields", which means if you used CGI both to
parse the submitted form and print a new form, it automatically uses
the values of just-parsed elements to populate the newly printed ones with
the same name.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.


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

Date: 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 1860
***************************************


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