[26145] in Perl-Users-Digest
Perl-Users Digest, Issue: 8336 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 19 06:05:35 2005
Date: Fri, 19 Aug 2005 03:05:07 -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 Fri, 19 Aug 2005 Volume: 10 Number: 8336
Today's topics:
Re: coding style and performance <tadmc@augustmail.com>
Re: coding style and performance <nobull@mail.com>
Re: debian rename <shane@weasel.is-a-geek.net>
Re: debian rename <sherm@dot-app.org>
Re: debian rename <jurgenex@hotmail.com>
Re: debian rename <simon@unisolve.com.au>
Re: debian rename <tintin@invalid.invalid>
Re: debian rename (Anno Siegel)
Re: Dynamic Typing, Defencive Programming and Prototype <vtatila@mail.student.oulu.fi>
Re: Dynamic Typing, Defencive Programming and Prototype <tassilo.von.parseval@rwth-aachen.de>
Re: ftp client to send data using a certain network int <ThomasKratz@REMOVEwebCAPS.de>
Re: How to detect a dead parent? <bernard.el-haginDODGE_THIS@lido-tech.net>
Re: How to detect a dead parent? (Anno Siegel)
Re: How to detect a dead parent? <someone@example.com>
Re: How to detect a dead parent? <bernard.el-haginDODGE_THIS@lido-tech.net>
How to emulate the Unix command "which" <nabotleon@hotmail_N0_SPAMZ.com>
Re: How to emulate the Unix command "which" (Anno Siegel)
Re: Listing Folders with Net::IMAP <josef.moellers@fujitsu-siemens.com>
Re: Listing Folders with Net::IMAP <jon@watcher.net.nz>
Re: Organizing data for readability and efficiency <tadmc@augustmail.com>
Re: Organizing data for readability and efficiency (Anno Siegel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 18 Aug 2005 23:00:34 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: coding style and performance
Message-Id: <slrndgamb2.trk.tadmc@magna.augustmail.com>
ngoc <ngoc@yahoo.com> wrote:
> Villy Kruse wrote:
>> On Thu, 18 Aug 2005 14:18:38 +0200,
>> ngoc <ngoc@yahoo.com> wrote:
>>>I prefer
>>>
>>>my $element;
>>>for $element (@array) {
>>> ..do something..
>>>}
>>>The interpreter will NOT create new variable for every loop step. It
>>>just updates current one.
>>
>>
>> Then again, the loop won't use the $element you create before entering
>> the loop, it will use a new loop variable. Try assing a value to $element
>> before entering the loop and check its value after you leave the loop.
>>
>> VIlly
>
> I have tested what you suggest and It is as you say. But I still do not
> understand the logic.
> If the loop create a new variable with the same name as my own variable,
It does not create a new _variable_ it creates a new _value_
for the variable.
What is local is not the variable (ie. its name), but the variable's value.
> So there are two variables with the same name.
No, there is one (lexical) variable (named $element) that has a local()
value in it for a time.
First its value is undef.
Then foreach saves that value is a "secret place", and replaces it
with values taken from @array until the loop is done.
Then the (undef) value is restored to $element.
> 1. My own variable will not conflict with loop's variable, because my
> variable is 'global' and loop variable is 'local' (scoping).
They are *the same* variable.
Your own _values_ will not conflict with loop's values. :-)
See also:
"Coping with Scoping":
http://perl.plover.com/FAQs/Namespaces.html
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 19 Aug 2005 09:18:38 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: coding style and performance
Message-Id: <de44ku$rd8$1@redhat2.bham.ac.uk>
Tad McClellan wrote:
> ngoc <ngoc@yahoo.com> wrote:
>> Villy Kruse wrote:
>>> ngoc <ngoc@yahoo.com> wrote:
>>>>
>>>>my $element;
>>>>for $element (@array) {
>>>
>>> ...the loop won't use the $element you create before entering
>>>the loop, it will use a new loop variable. Try assing a value to $element
>>>before entering the loop and check its value after you leave the loop.
>>
>>If the loop create a new variable with the same name as my own variable,
>
> It does not create a new _variable_ it creates a new _value_
> for the variable.
>
> What is local is not the variable (ie. its name), but the variable's value.
No, Tad, what you say is true if $element is a package variable but not
if it's lexical. See my paralell response in this thread.
------------------------------
Date: Fri, 19 Aug 2005 16:06:20 +1200
From: Shane <shane@weasel.is-a-geek.net>
Subject: Re: debian rename
Message-Id: <pan.2005.08.19.04.06.20.581293@weasel.is-a-geek.net>
for the benefit of the pedants..
the problem was a newline char
to fix all I had to do was
chomp $mail
thanking you :-)
--
Hardware, n.: The parts of a computer system that can be kicked
The best way to get the right answer on usenet is to post the wrong one.
------------------------------
Date: Fri, 19 Aug 2005 00:14:38 -0400
From: Sherm Pendley <sherm@dot-app.org>
Subject: Re: debian rename
Message-Id: <m27jei5zrl.fsf@Sherm-Pendleys-Computer.local>
Shane <shane@weasel.is-a-geek.net> writes:
> This piece of perl works brill for me on my slackware machine, but not on
> my debian machine, any ideas why?
WTF is "brill"?
> sub changename{
> my @list = &unread;
Why are you calling a sub with &? If you can't answer that, delete the "&",
then go read "perldoc perlsub".
> foreach $mail(@list){
> my $old_name = $mail;
> ($mail=~s/2,$/2,S/);
> rename($old_name, $mail);
Why aren't you asking Perl the question you're asking us? It knows what went
wrong - we can only guess.
rename($old_name, $mail) or die "Could not rename $old_name to $mail: $!";
You really should read the posting guidelines for this group, and the Perl
FAQ.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Fri, 19 Aug 2005 04:20:49 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: debian rename
Message-Id: <B6dNe.13806$Y55.10505@trnddc06>
Sherm Pendley wrote:
> Shane <shane@weasel.is-a-geek.net> writes:
>
>> This piece of perl works brill for me on my slackware machine, but
>> not on my debian machine, any ideas why?
>
> WTF is "brill"?
I remember a hair gel from my father back in the 60th that was called Brill.
He never used it, so I figure it must have been even older, like from the
50th?
jue
------------------------------
Date: Fri, 19 Aug 2005 14:22:09 +1000
From: Simon Taylor <simon@unisolve.com.au>
Subject: Re: debian rename
Message-Id: <de3mvp$pui$1@otis.netspace.net.au>
Hello Shane,
> This piece of perl works brill for me on my slackware machine, but not on
> my debian machine, any ideas why?
>
> sub changename{
> my @list = &unread;
> foreach $mail(@list){
> my $old_name = $mail;
> ($mail=~s/2,$/2,S/);
> rename($old_name, $mail);
> print $old_name."\n";
>
> }}
>
> whats Im trying to do is mark mail as read on a imap server by appending
> an S on the end
I'd be suspicious of unexpected file permissions, file name problems, or
something else to do with the environment on the debian machine.
And by the way, you can get a lot of mileage out of checking what was
returned by *both* the s/// function and the rename function.
Try this:
#!/usr/bin/perl
use strict;
use warnings;
changename();
exit(0);
sub changename {
my @list = unread();
foreach my $mail (@list) {
my $old_name = $mail;
$mail =~ s/2,$/2,S/
or die "Unexpected filename: $old_name";
rename($old_name, $mail)
or die "Unable to rename $old_name to $mail: $!";
print $old_name."\n";
}
}
Regards,
Simon Taylor
--
www.perlmeme.org
------------------------------
Date: Fri, 19 Aug 2005 21:39:15 +1200
From: "Tintin" <tintin@invalid.invalid>
Subject: Re: debian rename
Message-Id: <6NhNe.4023$iM2.389773@news.xtra.co.nz>
"Shane" <shane@weasel.is-a-geek.net> wrote in message
news:pan.2005.08.19.04.06.20.581293@weasel.is-a-geek.net...
> for the benefit of the pedants..
> the problem was a newline char
> to fix all I had to do was
> chomp $mail
Actually your real problem was to not have any error checking in your code
(as pointed out by at least two of the regulars of this newsgroup)
------------------------------
Date: 19 Aug 2005 09:57:08 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: debian rename
Message-Id: <de4adk$2b1$2@mamenchi.zrz.TU-Berlin.DE>
Shane <shane@weasel.is-a-geek.net> wrote in comp.lang.perl.misc:
> On Fri, 19 Aug 2005 03:33:59 +0000, A. Sinan Unur wrote:
>
> > Shane <shane@weasel.is-a-geek.net> wrote in
> > news:pan.2005.08.19.03.30.13.736258@weasel.is-a-geek.net:
> >
> >> well thank you for the usenet protocol lecture if ever I need a pedant
> >> I'll be sure to contact you
> >
> > *PLONK*
>
> thanks.. I should of done the same
"Should of"? And you dare correct other people's English?
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Fri, 19 Aug 2005 10:53:46 +0300
From: "Veli-Pekka Tätilä" <vtatila@mail.student.oulu.fi>
Subject: Re: Dynamic Typing, Defencive Programming and Prototypes (Was: Interfaces and Type Safety)
Message-Id: <de436n$5a8$1@news.oulu.fi>
Tassilo v. Parseval wrote:
defencive programming:
> So PHP is offensive. ;-)
Yup, at least V4 is <smile>. But as to defencive programming in Perl, I've
found these two lines invaluable:
use strict;
use warnings FATAL => qw|all|;
Writing code with speech it is far too easy to accidentally mistype an
identifier and try introducing a new variable in the middle of a
print-statement or something. And as to making warnings die, it prevents you
from fixing things lazily and catches subtle initialization bugs, very nice.
Another benefit is knowing as soon as something goes wrong. As the screen
reader's focus can be in one GUI widget at a time and the console app I'm
doing runs in the background, dying quickly, forces me to actually notice
the warnings. It would be even better if I could be warned audibly by
emiting the bell char \a to the console when-ever this does happen. However,
I reckon that's a no-can-do in Win32 as signals aren't implemented and END
blocks not run when you die. Perhaps using eval, then.
benefits of dynamic typing:
> Consider a module that is used to write XML tags as generically as
> possible. <snip> <snip> all you need is one special
> method to handle it all. <snip> generate and compile
> the requested method on the fly:
I see, your auto load example is pretty impressive. Still, as they say
there's more than one way to do it, wouldn't it be easier foor the caller if
there was one createTag method whose first argument was the name of the tag.
No auto-load or pollution of the callers namespace needed. But then again
the other benefits you mentioned will be lost and you don't necessarily have
to export the methods.
ah, I think I now know another example of auto loading. The Win32::OLE
module that I'm using a lot enables you to load in an OLE type library and
after that the constructed object will magically have method and property
names corresponding to those of the type library. And calling non-existant
methods dies cleanly, too. I was really awed when I saw this. I cannot think
of a way to achieve the same thing in Java, for instance, even if you could
use reflection and polymorphism. Sure you might be able to have some
dispatcher method whose first argument is the property or method being
operated on, as in the previous example, but that doesn't look as smooth as
in Perl. Finally, I'm greatful that Perl programmers generally don't do as
much operator over-loading as C++-programmers, because it can be very
confusing if overused.
Prototypes:
> Perl does have forward-declarations as well. The case above works if the
> function definitions comes before the code that calls this function.
I just tried your example and noticed the same thing on my own yesterday.
Argh as in C again, I like the Java method where the compiler doesn't force
you to type in the same thing twice for no obvious reasons: I mean obvious
from the programmer convenience point of view.
Anyway, what's the canonical way of including these protos? If I stick all
of them at the beginning of the file, it is confusing for people reading it
the first time. But then again I haven't seen people using C-like include
files for definitions, either, and am unsure as to what extension such files
should have. ph comes to mind standing for perl header.
If I want to be truely lazy, is there a way of automatically copying the
prototype from the implementation and placing it before the function is
being used? I hope someone else has already done something like this and
will search using PPM. Source filtering comes to mind as the first choice.
--
With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/
------------------------------
Date: Fri, 19 Aug 2005 11:00:04 +0200
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: Dynamic Typing, Defencive Programming and Prototypes (Was: Interfaces and Type Safety)
Message-Id: <slrndgb7sk.sq.tassilo.von.parseval@localhost.localdomain>
Also sprach Veli-Pekka Tätilä:
> Tassilo v. Parseval wrote:
>
> defencive programming:
>> So PHP is offensive. ;-)
> Yup, at least V4 is <smile>. But as to defencive programming in Perl, I've
> found these two lines invaluable:
>
> use strict;
> use warnings FATAL => qw|all|;
>
> Writing code with speech it is far too easy to accidentally mistype an
> identifier and try introducing a new variable in the middle of a
> print-statement or something. And as to making warnings die, it prevents you
> from fixing things lazily and catches subtle initialization bugs, very nice.
> Another benefit is knowing as soon as something goes wrong. As the screen
> reader's focus can be in one GUI widget at a time and the console app I'm
> doing runs in the background, dying quickly, forces me to actually notice
> the warnings. It would be even better if I could be warned audibly by
> emiting the bell char \a to the console when-ever this does happen. However,
> I reckon that's a no-can-do in Win32 as signals aren't implemented and END
> blocks not run when you die. Perhaps using eval, then.
Don't the pseudo-signals __WARN__ and __DIE__ work on windows, too?
With them:
use warningsd FATAL => 'all';
$SIG{ __DIE__ } = sub {
for (1 .. 10) {
print STDERR "\a"; # need auto-flushed handle here
select undef, undef, undef, 0.2;
}
}
Or use one of the Win32 modules to emmit this annoying "oh-oh" Windows
system sound. :-)
> benefits of dynamic typing:
>> Consider a module that is used to write XML tags as generically as
>> possible. <snip> <snip> all you need is one special
>> method to handle it all. <snip> generate and compile
>> the requested method on the fly:
> I see, your auto load example is pretty impressive. Still, as they say
> there's more than one way to do it, wouldn't it be easier foor the caller if
> there was one createTag method whose first argument was the name of the tag.
> No auto-load or pollution of the callers namespace needed. But then again
> the other benefits you mentioned will be lost and you don't necessarily have
> to export the methods.
Yes, having a createTag() method is how less dynamic languages would do
it. With the expected consequences for the API.
> ah, I think I now know another example of auto loading. The Win32::OLE
> module that I'm using a lot enables you to load in an OLE type library and
> after that the constructed object will magically have method and property
> names corresponding to those of the type library. And calling non-existant
> methods dies cleanly, too. I was really awed when I saw this. I cannot think
> of a way to achieve the same thing in Java, for instance, even if you could
> use reflection and polymorphism. Sure you might be able to have some
> dispatcher method whose first argument is the property or method being
> operated on, as in the previous example, but that doesn't look as smooth as
> in Perl. Finally, I'm greatful that Perl programmers generally don't do as
> much operator over-loading as C++-programmers, because it can be very
> confusing if overused.
Note that tied hashes or arrays are conceptually overloading the
subscript operator. The C++ equivalent would be overloading the '[]'
operator. So if you consider tying as overloading, then it is in fact
common in Perl.
However, Perl programmers seem to be less hooked on overloading
operators the classical way (by using the 'overload' pragma).
> Prototypes:
>> Perl does have forward-declarations as well. The case above works if the
>> function definitions comes before the code that calls this function.
> I just tried your example and noticed the same thing on my own yesterday.
> Argh as in C again, I like the Java method where the compiler doesn't force
> you to type in the same thing twice for no obvious reasons: I mean obvious
> from the programmer convenience point of view.
The need for pre-declarations in certain languages has to do with the
way the compilers are implemented. You need at least a two-phase
compiler (that is, a compiler that makes two sweeps over the program or
the intermediate internal representation of the program) to eliminate
the need for forward declarations. However, there are also things like
incremental compilation where it is crucial for the compiler to know the
calling conventions for certain functions that are used in the code to
be compiled but that are not yet defined.
I reckon perl tries to reduce the number of visits of each syntax tree
node as it increases compile-time. Forward-declarations are one way to
ensure that prototypes can be checked at compile-time without the need
of running through the abstract syntax tree too often.
> Anyway, what's the canonical way of including these protos? If I stick all
> of them at the beginning of the file, it is confusing for people reading it
> the first time. But then again I haven't seen people using C-like include
> files for definitions, either, and am unsure as to what extension such files
> should have. ph comes to mind standing for perl header.
Perl headers are already used for something else and they have .ph as
extension. See 'perldoc h2ph'. It's fairly obscure.
Just use .pm as extension which is also the only way that ensures you
can include it with 'use'. If you want to indicate that a module only
consists forward declaration use an appropriate naming scheme:
Module_inc.pm # or Module_fwd.pm or so
Module.pm
Note that the file containing the forward declarations needs to be
included at compile-time in order to have any effect. When you include
modules via 'use', this happens anyway.
> If I want to be truely lazy, is there a way of automatically copying the
> prototype from the implementation and placing it before the function is
> being used? I hope someone else has already done something like this and
> will search using PPM. Source filtering comes to mind as the first choice.
Source filtering is probably the only way as it happens early enough,
namely at scan-time. But it's a heavy and in parts error-prone weapon.
But then I don't entirely understand your issue. If you have functions
in a module then you need to include this module in your programs
anyway. Do it with 'use' and no issues will arise.
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
------------------------------
Date: Fri, 19 Aug 2005 10:41:46 +0200
From: Thomas Kratz <ThomasKratz@REMOVEwebCAPS.de>
Subject: Re: ftp client to send data using a certain network interface
Message-Id: <43059b4a$0$11219$bb690d87@news.main-rheiner.de>
Tambaa Hapa wrote:
> Anyone know of an ftp client or a way to write one in Perl that will send
> data to another host using a specific network interface. I would like to
> test the throughput of our backup network and hence would like to force the
> client to use a specific network interface card.
>
> This is on Solaris.
Using Net::FTP, you can specify the interface in the call to the 'new'
contructor with the option 'LocalAddr' that will be passed on to
IO::Socket::INET. See the pod documentation for both modules.
Thomas
--
$/=$,,$_=<DATA>,s,(.*),$1,see;__END__
s,^(.*\043),,mg,@_=map{[split'']}split;{#>J~.>_an~>>e~......>r~
$_=$_[$%][$"];y,<~>^,-++-,?{$/=--$|?'"':#..u.t.^.o.P.r.>ha~.e..
'%',s,(.),\$$/$1=1,,$;=$_}:/\w/?{y,_, ,,#..>s^~ht<._..._..c....
print}:y,.,,||last,,,,,,$_=$;;eval,redo}#.....>.e.r^.>l^..>k^.-
------------------------------
Date: Fri, 19 Aug 2005 09:00:42 +0200
From: "Bernard El-Hagin" <bernard.el-haginDODGE_THIS@lido-tech.net>
Subject: Re: How to detect a dead parent?
Message-Id: <Xns96B75BABE447Celhber1lidotechnet@62.89.127.66>
Mark Mackey <markm@chiark.greenend.org.uk> wrote:
[...]
> So, the question is, how can a child detect that its parent is
> dead? [...]
By the smell?
--
Cheers,
Bernard
------------------------------
Date: 19 Aug 2005 07:34:10 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: How to detect a dead parent?
Message-Id: <de421i$qib$1@mamenchi.zrz.TU-Berlin.DE>
Bernard El-Hagin <bernard.el-haginDODGE_THIS@lido-tech.net> wrote in comp.lang.perl.misc:
> Mark Mackey <markm@chiark.greenend.org.uk> wrote:
>
> [...]
>
> > So, the question is, how can a child detect that its parent is
> > dead? [...]
>
>
> By the smell?
That depends...
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Fri, 19 Aug 2005 07:41:52 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: How to detect a dead parent?
Message-Id: <43gNe.208998$tt5.85256@edtnps90>
Anno Siegel wrote:
> Bernard El-Hagin <bernard.el-haginDODGE_THIS@lido-tech.net> wrote in comp.lang.perl.misc:
>>Mark Mackey <markm@chiark.greenend.org.uk> wrote:
>>
>>[...]
>>
>>>So, the question is, how can a child detect that its parent is
>>>dead? [...]
>>
>>By the smell?
>
> That depends...
Depends aren't large enough to cover a whole corpse.
John
--
use Perl;
program
fulfillment
------------------------------
Date: Fri, 19 Aug 2005 10:22:49 +0200
From: "Bernard El-Hagin" <bernard.el-haginDODGE_THIS@lido-tech.net>
Subject: Re: How to detect a dead parent?
Message-Id: <Xns96B769985D810elhber1lidotechnet@62.89.127.66>
"John W. Krahn" <someone@example.com> wrote:
> Anno Siegel wrote:
>> Bernard El-Hagin <bernard.el-haginDODGE_THIS@lido-tech.net> wrote
>> in comp.lang.perl.misc:
>>>Mark Mackey <markm@chiark.greenend.org.uk> wrote:
>>>
>>>[...]
>>>
>>>>So, the question is, how can a child detect that its parent is
>>>>dead? [...]
>>>
>>>By the smell?
>>
>> That depends...
>
> Depends aren't large enough to cover a whole corpse.
You could use *lots* of them, though.
--
Cheers,
Bernard
------------------------------
Date: Fri, 19 Aug 2005 11:05:36 +0200
From: Leon Nabot <nabotleon@hotmail_N0_SPAMZ.com>
Subject: How to emulate the Unix command "which"
Message-Id: <4305a123$0$17352$626a14ce@news.free.fr>
Hello,
I try to find a quick solution to find onto the PATH where is located an
executable as "which" do.
I have tried to use the "which" command into a pipe or backtick but the
returns are not the same in all Unixes, in particular if the searched
command is aliased, .
Anyone would know an easy way to do this ?
For the moment the only solution seems to write a module which browse
each directory of the PATH searching the file.
We need a solution that works only with the defaults functions/libs of a
Perl 5.005 (And up)
Rgds.
Léo
------------------------------
Date: 19 Aug 2005 09:45:57 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: How to emulate the Unix command "which"
Message-Id: <de49ol$2b1$1@mamenchi.zrz.TU-Berlin.DE>
Leon Nabot <nabotleon@hotmail_N0_SPAMZ.com> wrote in comp.lang.perl.misc:
> Hello,
>
> I try to find a quick solution to find onto the PATH where is located an
> executable as "which" do.
>
> I have tried to use the "which" command into a pipe or backtick but the
> returns are not the same in all Unixes, in particular if the searched
> command is aliased, .
If it reports aliases it isn't the external /usr/bin/which (or whatever),
but the shell builtin. Aliases are in she shell's workspace, external
programs don't know about them.
So you have essentially three choices of which "which" to use: The
external one, the one in the csh family and the one in the sh family.
> Anyone would know an easy way to do this ?
It isn't hard, but there is no trick that makes it particularly easy.
Walk through the $PATH directories and look for files with the right
name that are executable by the invocant. You can't report aliases
that way.
Alternatively you can use the external "which", or one of the shell's
builtins and post-process the output depending on the OS you're on.
The shell builtins may be more regular than it appears when you take
care to use the same shell everywhere.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Fri, 19 Aug 2005 09:22:18 +0200
From: Josef Moellers <josef.moellers@fujitsu-siemens.com>
Subject: Re: Listing Folders with Net::IMAP
Message-Id: <de416k$6jq$1@nntp.fujitsu-siemens.com>
Jon wrote:
> I'm trying to write an IMAP Webmail Client using Net::IMAP and am havin=
g
> problems getting a list of IMAP
> folders.
> use Net::IMAP;
> Is anybody able to point me in the right direction?
I've been using Mail::IMAPClient quite successfully.
It has a folder() method which does what you want.
--=20
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize
-- T. Pratchett
------------------------------
Date: Fri, 19 Aug 2005 21:34:02 +1200
From: Jon <jon@watcher.net.nz>
Subject: Re: Listing Folders with Net::IMAP
Message-Id: <de48pd$jjo$1@lust.ihug.co.nz>
Josef Moellers wrote:
> Jon wrote:
>> I'm trying to write an IMAP Webmail Client using Net::IMAP and am having
>> problems getting a list of IMAP
>> folders.
>
>> use Net::IMAP;
>
>> Is anybody able to point me in the right direction?
>
> I've been using Mail::IMAPClient quite successfully.
> It has a folder() method which does what you want.
Thanks Josef, I'll try it out :)
--
Jon
jon@watcher.net.nz
------------------------------
Date: Thu, 18 Aug 2005 23:18:14 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Organizing data for readability and efficiency
Message-Id: <slrndganc6.trk.tadmc@magna.augustmail.com>
Mark Seger <Mark.Seger@hp.com> wrote:
>
>> If you are considering making the choice between arrays and hashes based on
>> the performance of single look-ups into each (rather than by whether the
>> nature of your data best fits an array or best fits a hash), then I say you
>> are engaging in micro-optimization. Perhaps this is the nub of your
>> question, so let me repeat. The difference between array access and hash
>> access is small enough that if you are concerned about it, only actual
>> tests on actual data will be satifactory.
>
> Let me try again,
I think the unamed[1] quotee above was just checking that
you weren't succumbing to evil:
http://www.brainyquote.com/quotes/quotes/d/donaldknut181625.html [2]
[1] Please provide an attribution when you quote someone, it is
the polite thing to do.
[2] But Knuth was just quoting Tony Hoare, it seems.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 19 Aug 2005 08:54:17 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Organizing data for readability and efficiency
Message-Id: <de46np$7r$1@mamenchi.zrz.TU-Berlin.DE>
Mark Seger <Mark.Seger@hp.com> wrote in comp.lang.perl.misc:
>
> > Put the description of each plot into a hash with usefully named keys.
> > Then make a list of those:
> >
> >
> > my @plots;
> >
> > push @plots, {
> > title => 'Plot 13',
> > ymax => 120,
> > # ...
> > };
> >
> > push @plots, {
> > title => 'Plot 14',
> > ymax => 1.5,
> > # ...
> > };
>
> good to know I was on the right track with my thinking. now to add a
> slightly differnt wrinkle, in some cases I'll have mulitple not single
> elements such as multiple lines on the same plot and therefore a legend
> with multiple plot titles and even mulitple Y-axis entries. how would I
> mix in arrays with what you described above? can I have something like
>
> ymax => @max
> legend => @names
>
> where max is an array of the maximums for each plot line?
That is elementary Perl. Read perlref and perldsc.
> And finally, how is the efficiency of all this? Something like a plot
You appear to be obsessed with efficiency. You even wrote me in private
about it, but I want to keep it on Usenet, I won't reply.
At this stage of programming, efficiency is no concern of yours. The
point to begin worrying about efficiency is when you have a correct and
working program and it turns out to be slow, not before.
Also I fully agree with Xho's take that the organization of your data
is unlikely to have a noticeable effect on the runtime.
Thirdly, optimization is highly dependent on how the program is used,
what hardware it is run on, with what frequency, and so on. All we
have from you is a very sketchy plan to plot a lot of graphics. That
is no base to discuss efficiency. Please don't insist, you'll only
annoy people.
> title or legend is only going to be accessed once when I draw the plot,
> but the ymax represents something I have to check against for every data
> point. Are there any inefficiencies worth worrying about in accessing
> that data within a hash? In general when I need to access something
> 100Ks of times I do worry about hashes vs arrays.
Don't. If you have a plot to make, it won't matter if you have to access
an array or a hash to do so. It won't even matter if you have to access
it a hundred or a thousand times per plot, the plot time will still
dominate. It's like planning a 1000 mile journey and asking everybody
how to clear your driveway so you'll have a quick start.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
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 8336
***************************************
