[32790] in Perl-Users-Digest
Perl-Users Digest, Issue: 4054 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Oct 12 16:09:37 2013
Date: Sat, 12 Oct 2013 13:09:04 -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 Sat, 12 Oct 2013 Volume: 11 Number: 4054
Today's topics:
Any experiences with Rakudo Perl 6? gamo@telecable.es
Re: Any experiences with Rakudo Perl 6? gamo@telecable.es
Re: multiple codepages <derykus@gmail.com>
Re: multiple codepages <rvtol+usenet@xs4all.nl>
sendmail not working - any alternatives? <John.Smith@invalid.com>
Some sort questions - especially hashes <dave@invalid.invalid>
Re: Some sort questions - especially hashes <news@lawshouse.org>
Re: Some sort questions - especially hashes <rweikusat@mobileactivedefense.com>
Re: Some sort questions - especially hashes <dave@invalid.invalid>
Re: Some sort questions - especially hashes <dave@invalid.invalid>
Re: Some sort questions - especially hashes <ben@morrow.me.uk>
Re: Some sort questions - especially hashes <rweikusat@mobileactivedefense.com>
Re: Some sort questions - especially hashes <ben@morrow.me.uk>
Re: using File::Spec effectively <ben.usenet@bsb.me.uk>
Re: using File::Spec effectively <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 11 Oct 2013 21:42:35 +0000 (UTC)
From: gamo@telecable.es
Subject: Any experiences with Rakudo Perl 6?
Message-Id: <l39rcb$6up$1@speranza.aioe.org>
I'm interested specially with the speed of Perl 6 compiled
programs. Numeric programs in particular.
I have read the examples of Perl6::Coockbook module and I
think there are a lot of basic programs that could be
translated from Perl 5 to 6 without much pain.
TIA
------------------------------
Date: Sat, 12 Oct 2013 11:22:06 +0000 (UTC)
From: gamo@telecable.es
Subject: Re: Any experiences with Rakudo Perl 6?
Message-Id: <l3bbcu$ahp$1@speranza.aioe.org>
Forget about it. It's unusable because hangs out.
I used this program to test
#!/usr/bin/perl6
use v6;
=begin pod
Calculate the N(0,1) prob. value corresponding to Z
=end pod
# say "Enter Z: ";
my $z = 1; # @ARGV[0]; # $*IN; # .lines;
# chomp $z;
die "Wrong number" unless $z;
my $step = 1/1000000;
my $r = 0.5;
my $pi = 3.14159265358979324;
my $static = 1/(1000000*sqrt(2*$pi));
my $e = exp(1);
my $i = $step;
loop {
$i += $step;
if $i > $z {
last;
}
$r += $static*($e**(-0.5*$i*$i));
}
$r = sprintf ("%.7f",$r);
say "P[Z<=$z] = $r";
my $rleft = 1 - $r;
$r -= $rleft;
say "P[-$z<=Z<=$z] = $r";
exit 0;
# After correcting it more than 20 times, it shows no error but doesn't run
------------------------------
Date: Fri, 11 Oct 2013 16:55:57 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: multiple codepages
Message-Id: <ed77d0d0-549c-49ca-be36-fa9651f49887@googlegroups.com>
On Tuesday, October 8, 2013 4:59:11 AM UTC-7, Rainer Weikusat wrote:
> Charles DeRykus <derykus@gmail.com> writes:
>
> ...
>
> The point was supposed to be that our is genuinely different from my
> because it doesn't create a perl-level object (it may do so
> accidentally, but that's an implementation detail which c be ignored
> but a short (that is, not fully-qualified) name referring to an object
> associated with the symbol-table of the package the our resides in (in
> order to prevent "use strict 'vars'" from complaining about such an
> object being used without a fully-qualified name): With your
> add_something, not the scope of the object referred to by $foo is
> restricted but the scope of the short name $foo. This code
>
>
> use strict;
> package MyFoo;
> sub add_something { our $foo; return $foo += $_[0]; };
> $foo = 5;
> package main;
> print MyFoo::add_something(3), "\n";
>
> won't compile because the $foo name is used outside of the scope of the our declaration but this code
> --------
> use strict;
> package MyFoo;
> sub add_something { our $foo; return $foo += $_[0]; };
> our $foo = 5;
> package main;
> print MyFoo::add_something(3), "\n";
>
> will because a name referring to the same object is declared in both scopes.
>
> In contrast to this, both the 'state' feature and the trick with
>
> creating a my-variables in a surrounding scope end up creating an object
>
> which is private to the subroutine in question and will keep its value
> between invocations of that.
Yes, thanks I realize that. My point was although it was a loose "encapsulation" you can come close to faking what 'state' and 'my-variables in a surrounding scope' can do.
In fact, although it's nothing more than a curiosity,
(maybe "curioser and curioser" Alice would say) you could
even tighten it a bit more with an eval:
package MyFoo;
our( $foo, $tmp );
sub add_something {
local $tmp = $foo;
$tmp += $_[0];
*foo = eval "\\$tmp"; die $@ if $@ ;
return $foo;
}
Now an injection of $MyFoo::foo = -17 won't be possible.
--
Charles DeRykus
[sorry for any Google spacing injection, the thread disappeared from my regular newsreader]
------------------------------
Date: Sat, 12 Oct 2013 21:46:32 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: multiple codepages
Message-Id: <5259a718$0$16003$e4fe514c@news2.news.xs4all.nl>
On 12/10/2013 01:55, C.DeRykus wrote:
> *foo = eval "\\$tmp"; die $@ if $@ ;
I never get it why people test $@.
eval "*foo = \\$tmp; 1" or die $@;
And if you are going to die anyway:
*foo = \$tmp;
--
Ruud
------------------------------
Date: Sat, 12 Oct 2013 22:05:56 +0300
From: John <John.Smith@invalid.com>
Subject: sendmail not working - any alternatives?
Message-Id: <dq6j59p7lljlu88cefdguvlfcelhh8arm0@4ax.com>
My web site provider has trouble getting sendmail to work.
This is a trimmed down versio on a perl file that used to work just fine for
years and then it quit working. I've contacted them to no avail:
#!/usr/bin/perl
print "Content-Type: text/html; charset=iso-8859-1\n\n";
print '<html><head>';
print '<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">';
print '</head><body>';
$i=0;
&testmail;
print "Testing email $i <br>(1=success, 0=fail)<br>";
print "</body></HTML>";
sub testmail
{
#open(MAIL,"|/usr/sbin/sendmail -t") || return 0;
open(MAIL,"|/usr/lib/sendmail -t") || return 0;
#open(MAIL,"|/usr/bin/sendmail -t") || return 0;
select (MAIL);
print "To: blahblah\@whatever.com\n";
print "From: blahblah\@whatever.com\n";
print "Subject: testing\n";
print "\n";
print "This is message.\n";
close(MAIL);
select (STDOUT);
$i=1;
}
The code returns:
"Testing email 1
(1=success, 0=fail)"
but no email ever gets to the receiver (yes, I tried with actual working
addresses).
It works just fine on another domain host provider but I need to get it to work
on this particular.
What alternatives can I try?
------------------------------
Date: Thu, 10 Oct 2013 13:44:03 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Some sort questions - especially hashes
Message-Id: <fV45K0OBJxbE-pn2-DemjS6hYTv8h@paddington.bear.den>
This started out as one question but in trying to solve my problem I
got side tracked - as you do :-)
In the "Perl Cookbook" page 140 under sorting lists there is the
following code:
@ordered = sort { $a->name cmp $b->name } @employees;
Where has 'name' come from? and what is in @employees such that
$a->name means something? I can't work it backwards as it were to
figure it out.
Now the actual problem.
I have a script that is building an HTML table. The table is built
from a hash. The top level entries of the hash are anonymous arrays
the elements of which are the columns.
At present there is a chunk of duplicated formatting code depending on
which of two columns I sort over. Yesterday the inevitable happened in
that I changed the formatting of one set and forgot to make the same
change in the other. The "curse of the duplicated code" :-)
So it got me wondering if I could code one formatting loop and
dynamically set the sort up or down.
$foo = \&sortup;
$foo = \&sortdown if $bar;
foreach (sort $foo keys ......
But I recall scope problems in the past using suborutines that seem
solved if one used sort { ..... } syntax
At present one of the sorts looks like:
foreach my $url (sort {$$urlsref{$site}{$b}[0] <=>
$$urlsref{$site}{$a}[0] or $a cmp $b} keys %{$$urlsref{$site}} ) #
count descending
TIA
--
Regards
Dave Saville
------------------------------
Date: Thu, 10 Oct 2013 15:03:37 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: Some sort questions - especially hashes
Message-Id: <ROCdnUTphs8nLsvPnZ2dnUVZ8mednZ2d@giganews.com>
On 10/10/13 14:44, Dave Saville wrote:
> @ordered = sort { $a->name cmp $b->name } @employees;
>
> Where has 'name' come from? and what is in @employees such that
> $a->name means something?
From the perldoc: "where the elements to be compared are passed into
the subroutine as the package global variables $a and $b".
So in that block (within the braces) $a and $b represent the two sides
of every comparison that the sort will make; conceptually at any rate
the sort invokes your block, passing $a and $b to it, and makes its sort
decision on the final value.
I don't know what @employees consists of either, but whatever it is the
construct "$element_of_employees->name" must have some value. An array
of objects which all implement a "name" method would do.
It's just a code fragment; its message is that that you can use whatever
comparison code you like within your block, not just "<=>", "cmp" and so on.
--
Henry Law Manchester, England
------------------------------
Date: Thu, 10 Oct 2013 15:28:13 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Some sort questions - especially hashes
Message-Id: <87eh7tjj42.fsf@sable.mobileactivedefense.com>
"Dave Saville" <dave@invalid.invalid> writes:
[...]
> I have a script that is building an HTML table. The table is built
> from a hash. The top level entries of the hash are anonymous arrays
> the elements of which are the columns.
>
> At present there is a chunk of duplicated formatting code depending on
> which of two columns I sort over. Yesterday the inevitable happened in
> that I changed the formatting of one set and forgot to make the same
> change in the other. The "curse of the duplicated code" :-)
>
> So it got me wondering if I could code one formatting loop and
> dynamically set the sort up or down.
>
> $foo = \&sortup;
> $foo = \&sortdown if $bar;
>
> foreach (sort $foo keys ......
>
> But I recall scope problems in the past using suborutines that seem
> solved if one used sort { ..... } syntax
----------
sub asc
{
return $a <=> $b;
}
sub desc
{
return $b <=> $a;
}
my @in = map { int(rand(100)); } 0 .. 9;
my $cmp;
$cmp = \&asc;
print($_, "\n") for sort $cmp @in;
print("\n");
$cmp = \&desc;
print($_, "\n") for sort $cmp @in;
-----------
works as it should. What 'scope problems' are you referring to?
------------------------------
Date: Thu, 10 Oct 2013 15:35:27 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Some sort questions - especially hashes
Message-Id: <fV45K0OBJxbE-pn2-GHiKj3deCG0C@paddington.bear.den>
On Thu, 10 Oct 2013 14:28:13 UTC, Rainer Weikusat
<rweikusat@mobileactivedefense.com> wrote:
> "Dave Saville" <dave@invalid.invalid> writes:
>
> [...]
>
>
> > I have a script that is building an HTML table. The table is built
> > from a hash. The top level entries of the hash are anonymous arrays
> > the elements of which are the columns.
> >
> > At present there is a chunk of duplicated formatting code depending on
> > which of two columns I sort over. Yesterday the inevitable happened in
> > that I changed the formatting of one set and forgot to make the same
> > change in the other. The "curse of the duplicated code" :-)
> >
> > So it got me wondering if I could code one formatting loop and
> > dynamically set the sort up or down.
> >
> > $foo = \&sortup;
> > $foo = \&sortdown if $bar;
> >
> > foreach (sort $foo keys ......
> >
> > But I recall scope problems in the past using suborutines that seem
> > solved if one used sort { ..... } syntax
>
> ----------
> sub asc
> {
> return $a <=> $b;
> }
>
> sub desc
> {
> return $b <=> $a;
> }
>
> my @in = map { int(rand(100)); } 0 .. 9;
> my $cmp;
>
> $cmp = \&asc;
> print($_, "\n") for sort $cmp @in;
>
> print("\n");
>
> $cmp = \&desc;
> print($_, "\n") for sort $cmp @in;
> -----------
>
> works as it should. What 'scope problems' are you referring to?
Thanks.
IIRC I was several depths down in subroutines and using a "sort sub"
syntax to sort and it was similar to this problem with a complicated
deep hash to sort on and it was not sorting correctly until someone on
here pointed out that some part of it was out of scope. It was a long
time ago. But it *may* have been like this:
use .....
foo(..........
exit
sub foo{
.... sort bar .....
}
sub bar {
}
IOW foo and bar are on the same "level" and possibly bar should have
been defined inside foo.
--
Regards
Dave Saville
------------------------------
Date: Thu, 10 Oct 2013 15:39:27 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Some sort questions - especially hashes
Message-Id: <fV45K0OBJxbE-pn2-SZZ53B3dZEZ4@paddington.bear.den>
On Thu, 10 Oct 2013 14:03:37 UTC, Henry Law <news@lawshouse.org>
wrote:
> On 10/10/13 14:44, Dave Saville wrote:
> > @ordered = sort { $a->name cmp $b->name } @employees;
> >
> > Where has 'name' come from? and what is in @employees such that
> > $a->name means something?
>
> From the perldoc: "where the elements to be compared are passed into
> the subroutine as the package global variables $a and $b".
>
> So in that block (within the braces) $a and $b represent the two sides
> of every comparison that the sort will make; conceptually at any rate
> the sort invokes your block, passing $a and $b to it, and makes its sort
> decision on the final value.
>
Yes I understand that part.
> I don't know what @employees consists of either, but whatever it is the
> construct "$element_of_employees->name" must have some value. An array
> of objects which all implement a "name" method would do.
>
Ah, I thought it might be some sneaky way of sorting on hash keys
assuming the array contained refs to hashes.
> It's just a code fragment; its message is that that you can use whatever
> comparison code you like within your block, not just "<=>", "cmp" and so on.
>
--
Regards
Dave Saville
------------------------------
Date: Thu, 10 Oct 2013 22:38:39 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Some sort questions - especially hashes
Message-Id: <vbjjia-el42.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
>
> IIRC I was several depths down in subroutines and using a "sort sub"
> syntax to sort and it was similar to this problem with a complicated
> deep hash to sort on and it was not sorting correctly until someone on
> here pointed out that some part of it was out of scope. It was a long
> time ago. But it *may* have been like this:
You can get problems if the sort call and the sub you are sorting by are
in different packages.
> use .....
>
>
> foo(..........
>
> exit
>
> sub foo{
> .... sort bar .....
> }
>
> sub bar {
> }
>
> IOW foo and bar are on the same "level" and possibly bar should have
> been defined inside foo.
Named subs should never be defined inside other named subs in Perl. It
doesn't achieve anything useful and sometimes has confusing side-effects
(you will get a 'variable will not stay shared' warning, and the sub
won't see the lexicals you necessarily expect).
This probably doesn't apply to the new 'my sub's in 5.18; I haven't
investigated those yet.
Ben
------------------------------
Date: Fri, 11 Oct 2013 12:41:27 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Some sort questions - especially hashes
Message-Id: <87li202fx4.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth "Dave Saville" <dave@invalid.invalid>:
>>
>> IIRC I was several depths down in subroutines and using a "sort sub"
>> syntax to sort and it was similar to this problem with a complicated
>> deep hash to sort on and it was not sorting correctly until someone on
>> here pointed out that some part of it was out of scope. It was a long
>> time ago. But it *may* have been like this:
>
> You can get problems if the sort call and the sub you are sorting by are
> in different packages.
Actually, one will get problems in this case as sort uses the
package-variables $a and $b to pass the objects-to-be-compared into the
comparison routine and if that's not in the same package as the sort call,
naively written code will use a different $a and $a (namely, those of
the package the subroutine belongs to). Symbolic references could be
used to work around that (possibly together with no strict 'refs'):
-------
package AlienCompare;
sub desc {
return ${caller().'::b'} <=> ${caller().'::a'};
}
package Orkshire;
my @in = map { int(rand(100)) } 0 .. 9;
print($_, "\n") for sort AlienCompare::desc @in;
--------
[...]
>> IOW foo and bar are on the same "level" and possibly bar should have
>> been defined inside foo.
>
> Named subs should never be defined inside other named subs in Perl. It
> doesn't achieve anything useful
Depending on the situation, it might: PostgreSQL functions written in
Perl end up being compiled into anonymous subroutines. Insofar things
get complicated enough that more than one Perl subroutine is needed, the
additional ones have to be defined inside the/ a anonymous subroutine
created by the database server (it is possible to escape from the
anonymous routine by terminating it with a top-level }, add some 'free
code' and then get back into a different anonymous sub at the end of the
Postgres function definition, as you suggested a while ago, but that's a
trick I'd rather avoid).
> and sometimes has confusing side-effects
> (you will get a 'variable will not stay shared' warning, and the sub
> won't see the lexicals you necessarily expect).
IMHO, the warning itself is such a confusing side effect:
----------
use warnings;
sub soup
{
my @components = qw(carrots leeks celeriac garlic onion);
sub components
{
return @components;
}
sub mash_it
{
@components = 'vegetable mash';
}
}
soup();
print('A soup made of ', join(', ', components()), ".\n");
mash_it();
print('Now, we just have ', components(), ".\n");
-----------
Since the two inner subroutine are created 'statically' at
compile-time, I wouldn't expect them to pick up new incarnations of
@components created at run time but they will continue to share the
initial one.
------------------------------
Date: Fri, 11 Oct 2013 21:50:08 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Some sort questions - especially hashes
Message-Id: <0t4mia-g35.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth "Dave Saville" <dave@invalid.invalid>:
> >>
> >> IIRC I was several depths down in subroutines and using a "sort sub"
> >> syntax to sort and it was similar to this problem with a complicated
> >> deep hash to sort on and it was not sorting correctly until someone on
> >> here pointed out that some part of it was out of scope. It was a long
> >> time ago. But it *may* have been like this:
> >
> > You can get problems if the sort call and the sub you are sorting by are
> > in different packages.
>
> Actually, one will get problems in this case as sort uses the
> package-variables $a and $b to pass the objects-to-be-compared into the
> comparison routine and if that's not in the same package as the sort call,
> naively written code will use a different $a and $a (namely, those of
> the package the subroutine belongs to). Symbolic references could be
> used to work around that (possibly together with no strict 'refs'):
We had that discussion just the other day. It's possible to avoid $a and
$b altogether by using a prototype, and IIRC it was no less efficient
that the globals when using a named sub for sorting rather than an
anonymous block.
> >> IOW foo and bar are on the same "level" and possibly bar should have
> >> been defined inside foo.
> >
> > Named subs should never be defined inside other named subs in Perl. It
> > doesn't achieve anything useful
>
> Depending on the situation, it might: PostgreSQL functions written in
> Perl end up being compiled into anonymous subroutines. Insofar things
> get complicated enough that more than one Perl subroutine is needed, the
> additional ones have to be defined inside the/ a anonymous subroutine
> created by the database server (it is possible to escape from the
> anonymous routine by terminating it with a top-level }, add some 'free
> code' and then get back into a different anonymous sub at the end of the
> Postgres function definition, as you suggested a while ago, but that's a
> trick I'd rather avoid).
Did I suggest that? It doesn't sound like me... if I were maintaining
PL/Perl I would want to make that impossible. (I don't know if that can
be done without PPI.)
More generally, at least as of Pg 9 there's no need for nasty tricks
like this any more. PL/Perl now has configuration parameters which allow
you to run Perl code before 'require' is locked out of the interpreter,
so you can put sub definitions in a file and load them in a civilised
fashion.
> > and sometimes has confusing side-effects
> > (you will get a 'variable will not stay shared' warning, and the sub
> > won't see the lexicals you necessarily expect).
>
> IMHO, the warning itself is such a confusing side effect:
>
> ----------
> use warnings;
>
> sub soup
> {
> my @components = qw(carrots leeks celeriac garlic onion);
>
> sub components
> {
> return @components;
> }
>
> sub mash_it
> {
> @components = 'vegetable mash';
> }
> }
>
> soup();
>
> print('A soup made of ', join(', ', components()), ".\n");
>
> mash_it();
>
> print('Now, we just have ', components(), ".\n");
> -----------
>
> Since the two inner subroutine are created 'statically' at
> compile-time, I wouldn't expect them to pick up new incarnations of
> @components created at run time but they will continue to share the
> initial one.
You clearly understand how the lexical scoping of these subs works;
however, it's confusing enough that it's not surprising others don't,
and the warning is for their benefit. Even with a proper understanding
of the situation, you are left in the rather weird position that the
first invocation of soup() will share @components with the other subs,
while subsequent invocations will not, so the warning still probably
indicates you have done something wrong.
It's worth noting that the warning is not emitted for 'state' variables,
which (despite otherwise being ordinary lexicals) exist in only one
instance, so the sharing semantics make more sense.
Ben
------------------------------
Date: Thu, 10 Oct 2013 14:20:45 +0100
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: using File::Spec effectively
Message-Id: <0.c3eaf351225ae671c280.20131010142045BST.87pprd2rf6.fsf@bsb.me.uk>
Cal Dershowitz <cal@example.invalid> writes:
<snip searching for questions...>
> unless(-e $path_to_images or mkdir($path_to_images, 0755)) {
> die "Unable to create $to\n";
> };
<snip>
> Q1 = shift; that is, is there something less-kludgy than pasting
> together paths with what the method call of File::Spec rootdir()
> returns?
catfile. There's no guarantee that rootdir() can be used to join path
components. Did you not see catfile (and the related catdir) in the
documentation?
> Q2 I've been reading the development in the alpaca book and was pretty
> sure that I could create a regex that would know that I want to have
> an or among pm css and tmpl, but I couldn't achieve as a lexical
> variable. Instead I have 3 pretty fortranny-looking controls. They
> might be cute as a first effort, but I'd like to see what an old perl
> pro might write instead.
I can't tell what this means.
> Q3) Do I set permissions correctly? Since I set them to 755, what
> situations would I do as well? For example, I could grant others in
> the group write priveleges. What number would that entail, and how is
> that best represented in perl?
There's lots to say here but it's not clear what you really want to
know. It looks like you might not have read the documentation for mkdir
which tells you that the mask you give it does not directly set the
permissions. It also directs you to the discussion of permissions in
the description of umask. Are still left with questions after reading
those two?
--
Ben.
------------------------------
Date: Thu, 10 Oct 2013 23:48:58 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: using File::Spec effectively
Message-Id: <qfnjia-h752.ln1@anubis.morrow.me.uk>
Quoth Cal Dershowitz <cal@example.invalid>:
> On 10/09/2013 03:32 AM, Cal Dershowitz wrote:
>
> > What one seems to have to do is build a path using catfile and append
> > the system's representation of root. Is that what a person is supposed
> > to do?
No, not at all. rootdir returns a string representing the root of the
(a) filesystem; the fact that on Unix and Win32 this happens to be the
same as the directory separator is just a coincidence (or, a consequence
of the sensible design of the Unix path syntax).
rootdir should never be used anywhere except at the front of a path.
> I'm trying to sort out these questions and do my own first edit,
> snipping the code from the original post, but not the question.
>
> I'd much rather come away from this discussion understanding File::Spec
> than cling to the latest thing I've thrown at the rim.
I would not recommend using File::Spec directly: it's rather verbose,
and the class setup is confusing. If you really care about portable
paths, I would recommend either File::Spec::Functions, or using
Path::Class from CPAN instead.
OTOH, I find that in general I can get away with sticking to /-separated
paths relative to the current directory. These are valid on all
currently-relevant OSs, and are much easier to deal with than trying to
get File::Spec to behave.
[snip: I don't know why you posted all that output, it didn't tell us
anything useful.]
> $ cat spades5.pl
> #!/usr/bin/perl -w
> use strict;
> use MySubs4 qw( highest_number );
> use Cwd;
> use File::Basename;
> use File::Spec;
> use File::Copy;
>
> my ($from, $to) = @ARGV;
> my $dir = cwd;
> my $rootdir = File::Spec->rootdir();
> print "rootdir is $rootdir\n";
> my $path_patch = $from.$rootdir;
So, to start with, this is wrong. This is 'a path ending in a
directory', so you want catdir. rootdir is not involved here.
> print "path1 is $path_patch\n";
> #mkdir
> unless(-e $to or mkdir($to, 0755)) {
> die "Unable to create $to\n";
> };
> my @files = <$path_patch*>;
This is extremely confusing. $path_patch ends with a /, so this is a
glob of all files in a directory, but that's not at all clear from the
code. Probably if you want to be portable the best thing is to do
my @file = glob catfile $path_patch, "*";
(assuming you import catfile from File::Spec::Functions). This gives you
'a complete path ending with a filename' where the filename is "*",
which glob will then expand.
OTOH you could just use readdir, or File::Slurp::read_dir, or
Path::Class::Dir->children.
> foreach $_ (@files) {
> $_ =~ s/^$path_patch//;
You cannot assume you can remove a directory name like this. Probably
you want abs2rel with two arguments.
> }
> #print "files are @files\n";
> my $ext = "pl";
> my $highest = highest_number(\@files, $ext, $from);
> print "highest is $highest\n";
> my $from_path = $path_patch.$from.$highest.".".$ext;
my $from_path = catfile $path_patch, "$from$highest.$ext";
There, isn't that clearer?
> foreach $_ (@files1) {
> next if $_ =~ m/~$/; #no backup files copied
> if ($_ =~ m/pm$/) {
>
> foreach $_ (@files1) {
> next if $_ =~ m/~$/; #no backup files copied
> if ($_ =~ m/css$/) {
>
> foreach $_ (@files1) {
> next if $_ =~ m/~$/; #no backup files copied
> if ($_ =~ m/tmpl$/) {
> Q1 = shift; that is, is there something less-kludgy than pasting
> together paths with what the method call of File::Spec rootdir() returns?
Yes. Use the functions properly.
> Q2 I've been reading the development in the alpaca book and was pretty
> sure that I could create a regex that would know that I want to have an
> or among pm css and tmpl, but I couldn't achieve as a lexical variable.
> Instead I have 3 pretty fortranny-looking controls. They might be
> cute as a first effort, but I'd like to see what an old perl pro might
> write instead.
What did you try? The obvious answer would be
if ($_ =~ m/(pm|css|tmpl)$/) {
> Q3) Do I set permissions correctly? Since I set them to 755, what
> situations would I do as well? For example, I could grant others in the
> group write priveleges. What number would that entail, and how is that
> best represented in perl?
I don't know if you set them correctly. Who do you want to have
permission to access these files?
The permission number is in octal (shown by the leading 0), because it
is divided into four groups of three bits. The first group is special
permissions (setuid, setgid and sticky); the other three are read, write
and execute/search permission for owner, group and other respectively.
So 0755 (or 00755) on a directory is
octal binary permission
0 0 setuid off
0 setgid off
0 sticky off
7 1 owner read on
1 owner write on
1 owner search on
5 1 group read on
0 group write off
1 group search on
5 1 other read on
0 other write off
1 other search on
Ben
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 4054
***************************************
