[28978] in Perl-Users-Digest
Perl-Users Digest, Issue: 222 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 14 14:11:01 2007
Date: Wed, 14 Mar 2007 11:09: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 Wed, 14 Mar 2007 Volume: 11 Number: 222
Today's topics:
Re: ActiveState Perl User Guide -- how can I add an ent clyde.ingram@edl.uk.eds.com
Re: ActiveState Perl User Guide -- how can I add an ent <ben@morrow.me.uk>
Re: ActiveState Perl User Guide -- how can I add an ent clyde.ingram@edl.uk.eds.com
Re: ActiveState Perl User Guide -- how can I add an ent clyde.ingram@edl.uk.eds.com
Counting occurences using a variable <jesse_hardy@premierinc.com>
Re: gluing client and server <blank@yahoo.com>
Re: Importing an hash in a lexical scope <stefano.sabatini-lala@poste.it>
Re: Importing an hash in a lexical scope <uri@stemsystems.com>
Installing librairies (window OS) ernond_paul@yahoo.fr
Retrieving pre-set enviroment variables in DOS not work <girishbhat6620@gmail.com>
Re: Retrieving pre-set enviroment variables in DOS not <blank@yahoo.com>
Re: Retrieving pre-set enviroment variables in DOS not anno4000@radom.zrz.tu-berlin.de
Re: Retrieving pre-set enviroment variables in DOS not <girishbhat6620@gmail.com>
Re: Retrieving pre-set enviroment variables in DOS not <girishbhat6620@gmail.com>
Retrieving the value of an Selected Item from a Listbox <doni.sekar@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 14 Mar 2007 06:52:24 -0700
From: clyde.ingram@edl.uk.eds.com
Subject: Re: ActiveState Perl User Guide -- how can I add an entry to the list of Programs?
Message-Id: <1173880344.099637.178030@b75g2000hsg.googlegroups.com>
On 5 Mar, 20:50, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth clyde.ing...@edl.uk.eds.com:
>
> > But how can I install my own executable Perl program/script such that
> > a documentation entry appears for the new program in the Programs
> > section of the User Guide?
>
>
> A third option would be to package your script up into a proper
> distribution, use MakeMaker to create a PPD, and install that using PPM.
How should I exploit Ben's 3rd option: packaging and using MakeMaker?
So far, I have a package for a .pm file: I created the framework
using:
module-starter --module=MyModule --author=... --email=...
and I shovelled my code and POD into the framework lib/MyModule.pm.
This installs very nicely using commands:
nmake
nmake install
with the new HTML page (from my POD source) appearing nicely under the
ActiveState Modules section.
Better still, I can configure links to an HTML page for a new Perl
program, say myprog.pl, which appears under the ActiveState Programs
section. Following Ben's good advice, myprog.pl installs using the
verbose commands:
pod2html --infile=c:/mystuff/myprog.pl --outfile=c:/Perl/html/bin/
myprog.pl --htmlroot=file:///c:/Perl/html
perl -eActivePerl::DocTools -eActivePerl::DocTools::WriteTOC
However, instead of the last 2 commands, I'd like to construct an
installable module for myprog.pl. Perhaps bundle it somehow with
MyModule.pm.
How can I do this?
The manual for ExtUtils::MakeMaker::Tutorial itemises a bin directory
at the same level as the MANIFEST, Makefile.PL, lib, etc. Oddly, it
gives no clues on how to use the bin directory. So i dropped
myprog.pl into the bin, added "bin/myprog.pl" to the MANIFEST, and re-
ran:
perl Makefile.PL
nmake
nmake install
No luck. myprog.pl did no appear in the ActiveState help; no
myprog.pl or myprog.html files appeared under c:/Perl.
Have I got to define something in Makefile.PL to do with INST_SCRIPT
or INSTALLSCRIPT, for example?
Thank-you,
Clyde
------------------------------
Date: Wed, 14 Mar 2007 15:53:08 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ActiveState Perl User Guide -- how can I add an entry to the list of Programs?
Message-Id: <4cilc4-fu8.ln1@osiris.mauzo.dyndns.org>
Quoth clyde.ingram@edl.uk.eds.com:
> On 5 Mar, 20:50, Ben Morrow <b...@morrow.me.uk> wrote:
> > Quoth clyde.ing...@edl.uk.eds.com:
> >
> > > But how can I install my own executable Perl program/script such that
> > > a documentation entry appears for the new program in the Programs
> > > section of the User Guide?
> >
> >
> > A third option would be to package your script up into a proper
> > distribution, use MakeMaker to create a PPD, and install that using PPM.
>
> How should I exploit Ben's 3rd option: packaging and using MakeMaker?
>
> So far, I have a package for a .pm file: I created the framework
> using:
>
> module-starter --module=MyModule --author=... --email=...
>
> and I shovelled my code and POD into the framework lib/MyModule.pm.
> This installs very nicely using commands:
>
> nmake
> nmake install
>
> with the new HTML page (from my POD source) appearing nicely under the
> ActiveState Modules section.
>
> Better still, I can configure links to an HTML page for a new Perl
> program, say myprog.pl, which appears under the ActiveState Programs
> section. Following Ben's good advice, myprog.pl installs using the
> verbose commands:
>
> pod2html --infile=c:/mystuff/myprog.pl --outfile=c:/Perl/html/bin/
> myprog.pl --htmlroot=file:///c:/Perl/html
> perl -eActivePerl::DocTools -eActivePerl::DocTools::WriteTOC
>
> However, instead of the last 2 commands, I'd like to construct an
> installable module for myprog.pl. Perhaps bundle it somehow with
> MyModule.pm.
> How can I do this?
>
> The manual for ExtUtils::MakeMaker::Tutorial itemises a bin directory
> at the same level as the MANIFEST, Makefile.PL, lib, etc. Oddly, it
> gives no clues on how to use the bin directory. So i dropped
> myprog.pl into the bin, added "bin/myprog.pl" to the MANIFEST, and re-
> ran:
>
> perl Makefile.PL
> nmake
> nmake install
perldoc ExtUtils::MakeMaker says you need to add an entry
EXE_FILES => ['bin/myprog.pl'],
to your Makefile.PL. Recommended practice would be to puth the bulk of
your code into the module, and have the executable just parse the
command-line and call into the module. Remember to put POD in the
executable as well, as this is what will appear under the executables
section of the TOC.
Ben
--
I've seen things you people wouldn't believe: attack ships on fire off
the shoulder of Orion; I watched C-beams glitter in the dark near the
Tannhauser Gate. All these moments will be lost, in time, like tears in rain.
Time to die. ben@morrow.me.uk
------------------------------
Date: 14 Mar 2007 09:18:22 -0700
From: clyde.ingram@edl.uk.eds.com
Subject: Re: ActiveState Perl User Guide -- how can I add an entry to the list of Programs?
Message-Id: <1173889102.238676.309750@n76g2000hsh.googlegroups.com>
On 14 Mar, 13:52, clyde.ing...@edl.uk.eds.com wrote:
> i dropped
> myprog.pl into the bin, added "bin/myprog.pl" to the MANIFEST, and re-
> ran:
>
> perl Makefile.PL
> nmake
> nmake install
>
> No luck. myprog.pl did no appear in the ActiveState help; no
> myprog.pl or myprog.html files appeared under c:/Perl.
Part solution: I dropped myprog.pl into blib/bin, and re-ran:
perl Makefile.PL
nmake
nmake install
This time, myprog.pl appears under the Programs section in ActiveState
Perl help page, as required.
However, links are broken again. When I click on a link which POD
defined like this:
L<MyModule|site::lib::MyModule>
my browser (Firefox) complains of failure to find:
/C:/Perl/html//mystuff/MyModule/blib/html/site/lib/MyModule.html
The link should resolve to:
C:/Perl/html/site/lib/MyModule.html
Now, this works when I use the pod2html command, specifying --
htmlroot="file:///C:/Perl/html".
How do I configure my Makefile.PL to override the default htmlroot, to
get the same effect as the --htmlroot switch on the pod2html command?
Regards,
Clyde
------------------------------
Date: 14 Mar 2007 09:59:25 -0700
From: clyde.ingram@edl.uk.eds.com
Subject: Re: ActiveState Perl User Guide -- how can I add an entry to the list of Programs?
Message-Id: <1173891565.344273.101290@n76g2000hsh.googlegroups.com>
On 14 Mar, 15:53, Ben Morrow <b...@morrow.me.uk> wrote:
> perldoc ExtUtils::MakeMaker says you need to add an entry
>
> EXE_FILES => ['bin/myprog.pl'],
>
> to your Makefile.PL. Remember to put POD in the
> executable as well, as this is what will appear under the executables
> section of the TOC.
Done. And its web page appears nicely in the ActiveState Programs
panel.
Thank-you for such a fast response.
But I still have the problem of how Makefile.PL is to redefine the
htmlroot, in the way that pod2html uses the --htmlroot switch.
Details are on a separate posting of 40 minutes ago.
Regards,
Clyde
------------------------------
Date: 14 Mar 2007 05:22:15 -0700
From: "jesse" <jesse_hardy@premierinc.com>
Subject: Counting occurences using a variable
Message-Id: <1173874935.502591.313450@n76g2000hsh.googlegroups.com>
I have a master file that gets added to everyday, with backup
failures. The file has server name and what failed. I want to open
the file and read the first line then check the rest of the file for
any more occurrences of that exact failure. Then I want to move to
the second line and repeat the proccess until I have read through the
entire file. When I move down the file I want to ignore lines that
have already been counted. I would also like to be able to ignore
lines if the failure didn't occur the day I am checking for, ie if it
failed today but didn't fail tomorrow then I don't want it to show up
on my report(this is a like to have but it's not mandatory). The file
looks like this;
server2 c:\\
server1 d:\\
server5 e:\\
server1 d:\\
This is the meat of the script that I have that of course is not
working right;
while (<FAILED>){
chomp;
s/#.*//;
next if /^(\s)*$/;
push @failures, $_;
foreach $elem ( @failures ){
next if $seen{$elem}++;
print OUTPUT "$elem has failed $seen{$elem}
times\n";
}
}
------------------------------
Date: Wed, 14 Mar 2007 10:01:52 +0100
From: Matija Papec <blank@yahoo.com>
Subject: Re: gluing client and server
Message-Id: <et8dl9$6ps$1@ss408.t-com.hr>
Sherm Pendley wrote:
>> I would like to use older mysql client but unfortunately it doesn't
>> understand newer authentication
>
> Configure the database to use old-style passwords. Problem solved.
>
> <http://dev.mysql.com/doc/refman/5.0/en/old-client.html>
Tnx, but I don't have the rights to configure the database.
------------------------------
Date: Wed, 14 Mar 2007 12:38:38 +0100 (CET)
From: Stefano Sabatini <stefano.sabatini-lala@poste.it>
Subject: Re: Importing an hash in a lexical scope
Message-Id: <slrnevfnft.43h.stefano.sabatini-lala@santefisi.caos.org>
Hi Guri, and thanks for your reply.
On 2007-03-13, Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "SS" == Stefano Sabatini <stefano.sabatini-lala@poste.it> writes:
>
> SS> For example I would like to define somewhere an hash like:
> SS> my %hash = (one => 1, two => 2, three => 3, four => 4);
>
> SS> and then be able to access the variables $one, $two, $three after
> SS> importing them:
> SS> {
> SS> # import the hash
> SS> ...
> SS> print "One is $one, two is $two, three is $three and so on";
> SS> }
>
> that is a very foolish idea in several ways. first, you can't import
> into lexical scope, only into the symbol table. second, the whole point
> of hashes is not to have individual variables for each value when they
> are related. what you are asking for is symbolic (as i said, lexical
> won't even work) references which are a very bad idea.
>
> SS> I successfully achieved to import an hash into the current package using
> SS> this incantation:
>
> SS> foreach (keys %hash) {
> SS> *$_ = \$hash{$_};
> SS> }
>
> was use strict enabled? won't work then.
well, I was using no strict there.
is there a better way to import an hash in the main package (without
disabling the strict pragma), or is this a bad practice to avoid?
>
> SS> I also tried this:
>
> SS> {
> SS> my $keys_str;
> SS> foreach (keys %hash) { $keys_str.= "\$$_, " };
>
> SS> # here it evals the code in the evalled code lexycal environment, which is
> SS> # (unfortunately) not the current lexycal environment, so the
> SS> # lexycal binding is immediately discarded
>
> SS> eval "my ($keys_str)";
>
> nasty.
>
> SS> no strict;
> SS> # this cause the creation of global (package) variables
> SS> # and don't warn 'cause of the no strict pragma
> SS> foreach (keys %hash) {
> SS> eval "\$$_ = $hash{$_};";
> SS> }
> SS> }
>
> again nasty.
well, I agree, and indeed it was just an experiment, and I'd think twice
before to put it in production code.
> SS> but after some debugging and thinkering I realized it can't work (as
> SS> explained in the comments above).
>
> why do you think you need to do this? will it make your code much
> cleaner or easier? since you MUST know the names of the hash keys in
> advance since you want to refer to them by name (in whatever scope), why
> would a general import help? all you save would be typing the name of
> the hash.
I have this problem. There is portion of user defined code (via a
code reference) loaded at run-time, and an hash containing options values
used in that code, which again is defined by the user at run-time.
I would like the user to use all the variables defined in the hash as
they were defined as regular variables in the code environment, rather
than hash entries.
For example:
my %options= (name => "John Doe",
programming_language_used => "Perl",
vice => "nastiness");
then I would like to access these values in the code in this way:
my $funref = {
print "My name is $name, I'm programming in $programming_language_used, ",
"my vice is $vice";
}
rather than like this:
my $funref = {
# $options is a reference to the options hash
my ($options) = @_;
print "My name is $options->{name}, ",
"I'm programming in $options->{programming_language_used}, ",
"my vice is $options->{vice}";
}
but, basing on what you said, I see it would be better (easier on the
programmer, *safer*) the latter, even if it is sligthly more prolisse.
> SS> So I'm thinking maybe it's not possible at all to achieve my goal, or
> SS> maybe I can't simply see how.
>
> you can't in a lexical scope. it is dumb in the symbol table.
>
> SS> Any help or suggestion will be highly appreciated.
>
> don't do it at all. use the hash as it is. you won't gain much at all
> doing what you want. you may think you do but there are other
> ways. since you MUST know the names you will be using, why not just do
> this:
>
> my $first = $hash{first} ;
>
> and so on. do that in the tightest scope just before where you use
> $first. and if you only use $first one time then don't even do that,
> just use the hash.
OK, and many thanks for your knowledgable help.
as I said I was experimenting, but it seems that the solution I was
contriving wasn't a good one.
Cheers
--
Stefano Sabatini
Linux user number 337176 (see http://counter.li.org)
------------------------------
Date: Wed, 14 Mar 2007 10:21:19 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Importing an hash in a lexical scope
Message-Id: <x7abyflukw.fsf@mail.sysarch.com>
>>>>> "SS" == Stefano Sabatini <stefano.sabatini-lala@poste.it> writes:
>> was use strict enabled? won't work then.
SS> well, I was using no strict there.
that is the whole problem. strict is meant to stop you from doing evil
things.
SS> is there a better way to import an hash in the main package (without
SS> disabling the strict pragma), or is this a bad practice to avoid?
you haven't explained your bigger picture. why do you need to import the
hash? can you pass it as an argument by reference? can you remotely
access it via a sub or method? there are other ways to share data than
just importing. you seem to be stuck on only import and i see no reason
from you why that is so critical.
>>
SS> I also tried this:
>>
SS> {
SS> my $keys_str;
>> again nasty.
SS> well, I agree, and indeed it was just an experiment, and I'd think twice
SS> before to put it in production code.
good! you learned something! :)
>> why do you think you need to do this? will it make your code much
>> cleaner or easier? since you MUST know the names of the hash keys in
>> advance since you want to refer to them by name (in whatever scope), why
>> would a general import help? all you save would be typing the name of
>> the hash.
SS> I have this problem. There is portion of user defined code (via a
SS> code reference) loaded at run-time, and an hash containing options values
SS> used in that code, which again is defined by the user at run-time.
SS> I would like the user to use all the variables defined in the hash as
SS> they were defined as regular variables in the code environment, rather
SS> than hash entries.
that is bas as i have already explained. if they know the names of the
hash elements (not variables) they can use those directly. having them
automatically assigned to lexicals is not a win. let them do it in code
as i have shown you if they want that.
SS> print "My name is $name, I'm programming in
SS> $programming_language_used, ", "my vice is $vice";
SS> rather than like this:
SS> my $funref = {
SS> # $options is a reference to the options hash
SS> my ($options) = @_;
SS> print "My name is $options->{name}, ",
SS> "I'm programming in $options->{programming_language_used}, ",
SS> "my vice is $options->{vice}";
SS> }
so what is so bad about that? use a shorter name for $options if you
want. or use a templater (see Template::Simple on cpan for something
that will do that quickly and easily)
untested:
use Template::Simple ;
my $tmpl = Template::Simple->new() ;
my $in = <<INPUT ;
My name is [%name%],
I'm programming in [%programming_language_used%],
my vice is [%vice%]
INPUT
# put into $options the hash info as above (no code here for that)
print $tmpl->render( $options, $input ) ;
clean, fast, safe, no extra $options all around. $tmpl is reusable too.
SS> but, basing on what you said, I see it would be better (easier on the
SS> programmer, *safer*) the latter, even if it is sligthly more prolisse.
SS> So I'm thinking maybe it's not possible at all to achieve my goal, or
SS> maybe I can't simply see how.
your goal isn't worthy of being achieved as it is misguided. putting
lexicals into a remote scope would be dangerous even it could be
done. what if outside data set some other lexical that was used for some
external operation? a security hole a mile wide. php is famous for this
sort of thing (all cgi params automatically become variables, same nasty
concept).
as i have shown you here, you can use a templater. or have the users
assign their own lexicals. and there is nothing wrong with your basic
hash access as you know that works. why do you think your users need
such a minor extra little helper like your lexical idea? the other
solutions are almost as short and so much better in many ways.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 14 Mar 2007 05:49:36 -0700
From: ernond_paul@yahoo.fr
Subject: Installing librairies (window OS)
Message-Id: <1173876576.264997.51860@n76g2000hsh.googlegroups.com>
Hi all,
I'm currently having trouble installaing librairies under a window OS.
first, I've developped a perl Gtk application under linux (it's works
well) ; and I would like to run it in window os. This application use
Gnome2, Gnome2::Canvas, Gtk2::GladeXML (and others one).
Under win (xp) I've first install ActivePerl (5.8.? => I don't
remember exactly ;-) )
Next, I've tryed to run ppm (the little user interface to install
packages) but Gnome2::Canvas isn't into the repository...
Then, I've tryed "cpan > install Gnome2::Canvas" => "install seems
impossible"
then : "cpan > look install Gnome2::Canvas" => perl Makefile.pl were
OK ; but make and make install were impossible because I'm under win
OS; How can I install make to build librairies ?
Please, could someone help me ? :-)
------------------------------
Date: 14 Mar 2007 01:52:44 -0700
From: "Girish" <girishbhat6620@gmail.com>
Subject: Retrieving pre-set enviroment variables in DOS not working
Message-Id: <1173862364.195484.101730@p15g2000hsd.googlegroups.com>
I have the following snippet of code running on perl, v5.6.1 built for
MSWin32-x86-multi-thread
on Windows XP platform.
if($ENV{'ATS_SETUP'} ne "")
{
$sendEmail = "yes";
$rootDrive = $ENV{'ATS_INDRIVE'};
$templateRoot = $ENV{'ATS_TEMPLATEROOT'};
$ATSRoot = $ENV{'ATS_ATSOUTDRIVE'};
}
Basically all the mentioned environment variables have been set. Yet
still, the above snippet doesn't work. Why? <Banging head>
------------------------------
Date: Wed, 14 Mar 2007 09:58:20 +0100
From: Matija Papec <blank@yahoo.com>
Subject: Re: Retrieving pre-set enviroment variables in DOS not working
Message-Id: <et8del$5kb$1@ss408.t-com.hr>
Girish wrote:
> if($ENV{'ATS_SETUP'} ne "")
> {
> $sendEmail = "yes";
> $rootDrive = $ENV{'ATS_INDRIVE'};
> $templateRoot = $ENV{'ATS_TEMPLATEROOT'};
> $ATSRoot = $ENV{'ATS_ATSOUTDRIVE'};
> }
>
> Basically all the mentioned environment variables have been set. Yet
> still, the above snippet doesn't work. Why? <Banging head>
Check for environment within your script,
use Data::Dumper;
print Dumper \%ENV;
------------------------------
Date: 14 Mar 2007 09:54:57 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Retrieving pre-set enviroment variables in DOS not working
Message-Id: <55pv3hF25dlrtU1@mid.dfncis.de>
Girish <girishbhat6620@gmail.com> wrote in comp.lang.perl.misc:
> I have the following snippet of code running on perl, v5.6.1 built for
> MSWin32-x86-multi-thread
> on Windows XP platform.
>
>
> if($ENV{'ATS_SETUP'} ne "")
> {
> $sendEmail = "yes";
> $rootDrive = $ENV{'ATS_INDRIVE'};
> $templateRoot = $ENV{'ATS_TEMPLATEROOT'};
> $ATSRoot = $ENV{'ATS_ATSOUTDRIVE'};
> }
>
> Basically all the mentioned environment variables have been set.
Have been set where? In the process that later starts your script?
Does your script see the values?
> Yet
> still, the above snippet doesn't work. Why? <Banging head>
"Does not work" is a useless error description. What do you expect
to happen, and what happens instead? There is no way to find out what
goes wrong without that information. Please be specific.
Anno
------------------------------
Date: 14 Mar 2007 04:05:18 -0700
From: "Girish" <girishbhat6620@gmail.com>
Subject: Re: Retrieving pre-set enviroment variables in DOS not working
Message-Id: <1173870318.580951.208300@e1g2000hsg.googlegroups.com>
On Mar 14, 2:54 pm, anno4...@radom.zrz.tu-berlin.de wrote:
> Girish <girishbhat6...@gmail.com> wrote in comp.lang.perl.misc:
>
> > I have the following snippet of code running on perl, v5.6.1 built for
> > MSWin32-x86-multi-thread
> > on Windows XP platform.
>
> > if($ENV{'ATS_SETUP'} ne "")
> > {
> > $sendEmail = "yes";
> > $rootDrive = $ENV{'ATS_INDRIVE'};
> > $templateRoot = $ENV{'ATS_TEMPLATEROOT'};
> > $ATSRoot = $ENV{'ATS_ATSOUTDRIVE'};
> > }
>
> > Basically all the mentioned environment variables have been set.
>
> Have been set where? In the process that later starts your script?
> Does your script see the values?
>
In a batch file that calls the script. eg
set ATS_SETUP = "yes";
I even tried setting them from the desktop -> "My Computer" ->
"Settings" -> "Advanced" -> "Enviroment variables"
> "Does not work" is a useless error description. What do you expect
> to happen, and what happens instead? There is no way to find out what
Simple. :-) The value retrieved into
$rootDrive = $ENV{'ATS_INDRIVE'};
$templateRoot = $ENV{'ATS_TEMPLATEROOT'};
etc ( I even commented out the if statement) is null. I expect to see
the same values that I see when I do a set ATS_INDRIVE in the
commandline prompt. :-)
------------------------------
Date: 14 Mar 2007 04:15:55 -0700
From: "Girish" <girishbhat6620@gmail.com>
Subject: Re: Retrieving pre-set enviroment variables in DOS not working
Message-Id: <1173870955.298971.127720@b75g2000hsg.googlegroups.com>
On Mar 14, 4:05 pm, "Girish" <girishbhat6...@gmail.com> wrote:
> On Mar 14, 2:54 pm, anno4...@radom.zrz.tu-berlin.de wrote:
>
>
>
>
>
> > Girish <girishbhat6...@gmail.com> wrote in comp.lang.perl.misc:
>
> > > I have the following snippet of code running on perl, v5.6.1 built for
> > > MSWin32-x86-multi-thread
> > > on Windows XP platform.
>
> > > if($ENV{'ATS_SETUP'} ne "")
> > > {
> > > $sendEmail = "yes";
> > > $rootDrive = $ENV{'ATS_INDRIVE'};
> > > $templateRoot = $ENV{'ATS_TEMPLATEROOT'};
> > > $ATSRoot = $ENV{'ATS_ATSOUTDRIVE'};
> > > }
>
> > > Basically all the mentioned environment variables have been set.
>
> > Have been set where? In the process that later starts your script?
> > Does your script see the values?
>
> In a batch file that calls the script. eg
> set ATS_SETUP = "yes";
>
> I even tried setting them from the desktop -> "My Computer" ->
> "Settings" -> "Advanced" -> "Enviroment variables"
>
> > "Does not work" is a useless error description. What do you expect
> > to happen, and what happens instead? There is no way to find out what
>
> Simple. :-) The value retrieved into
> $rootDrive = $ENV{'ATS_INDRIVE'};
> $templateRoot = $ENV{'ATS_TEMPLATEROOT'};
>
> etc ( I even commented out the if statement) is null. I expect to see
> the same values that I see when I do a set ATS_INDRIVE in the
> commandline prompt. :-)- Hide quoted text -
>
> - Show quoted text -
Never mind. Thanks for the response. Solved the problem. It WAS a
problem with whitespace in the batch script.
------------------------------
Date: 14 Mar 2007 10:48:55 -0700
From: "doni" <doni.sekar@gmail.com>
Subject: Retrieving the value of an Selected Item from a Listbox widget
Message-Id: <1173894535.691414.157020@b75g2000hsg.googlegroups.com>
Hi,
I would like to know how can I retrieve the value of the selected item
from the Listbox widget. I tried different options in Listbox widget
(<Double-ButtonPress-1>, <Return>) but I was not able to retrieve the
expected results.
Can anyone let me know how can I do this.
Thanks,
doni
#!/usr/bin/perl
use strict;
use Tk;
my @received_hello; my @sending_rupd; my @changing_l2; my
@received_nreg; my @received_nreg_new;
my @sending_nreg_ack; my @received_nd; my @received_nd_ack; my
@sending_nd; my @removing_l2;
my $mw = MainWindow->new;
$mw->configure(-title => 'Test Tool', -background => 'white', -width
=> "700", -height => "500");
my $lbox1 = $mw->Scrolled('Listbox', -scrollbars => 'osoe');
$lbox1->configure(-height => 8, -width => 20);
$lbox1->configure(-selectmode => 'browse');
$lbox1->pack(-anchor => 'e');
my $btn1 = $mw->Button(-text => "RFROUTED",
-command => \&rfrouted_button)->pack(-side =>
'right', -anchor => 'e');
my $btn2 = $mw->Button(-text => "GWD",
-command => \&gwd_button)->pack(-side =>
'right', -anchor => 'e');
my $btn3 = $mw->Button(-text => "Exit",
-command => sub{exit})->pack(-side => 'right', -
anchor => 'e', -after => $btn1);
my $fr = $mw->Frame(-background => 'cyan')->pack(-side => 'top', -
fill => 'x');
my $t = $mw->Scrolled("Text")->pack(-side => 'bottom', -fill =>
'both', -expand => '1');
MainLoop();
sub rfrouted_button {
repack();
foreach (qw/rcvd_hello sendg_rupd chng_l2 rcvd_nreg rcvd_nreg_new
sendg_nreg_ack rcvd_nd rcvd_nd_ack sendg_nd rmvg_l2/) {
$fr->Button(-text => $_, -command => \&rcvd_hello, -width =>
'12')->pack(-anchor => 'e');
}
}
sub gwd_button {
repack();
foreach (qw/new_device route_update/) {
$fr->Button(-text => $_, -width => '12')->pack(-anchor =>
'w');
no_of_times(@new_device);
}
}
sub repack {
$btn1->packForget();
$btn2->packForget();
$lbl1->packForget();
$lbl2->packForget();
}
sub rcvd_hello {
my @list = ("00:13:50:00:05:19", "00:13:50:00:05:bd",
"00:13:50:00:04:f9", "00:13:50:00:05:cb");
$lbox1->insert('end', @list);
$lbox1->bind('<<ListboxSelect>>',
sub{ display_lb_curselection($lbox1) });
}
sub display_lb_curselection {
my $lbox1 = shift;
my @cs = $lbox1->curselection();
my $selection = $lbox1->selectionSet(@cs);
print "Current choices: ", $selection;
print "\n";
}
------------------------------
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 222
**************************************
