[24206] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 6398 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Apr 13 21:05:47 2004

Date: Tue, 13 Apr 2004 18: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           Tue, 13 Apr 2004     Volume: 10 Number: 6398

Today's topics:
    Re: 3x3 simple puzzle <budman@somewhere.net>
    Re: 3x3 simple puzzle <budman@somewhere.net>
    Re: Changing from C thought to Perl <bmb@ginger.libs.uga.edu>
    Re: die-ing within functions <matternc@comcast.net>
    Re: download my bbs... <matthew.garrish@sympatico.ca>
    Re: foreach loop test <skuo@mtwhitney.nsc.com>
    Re: foreach loop test <nospam@bigpond.com>
    Re: foreach loop test <tore@aursand.no>
    Re: import() override - comments? <mb@uq.net.au.invalid>
    Re: MS Access Date/Time Data type mismatch <NOSPAM_djsteele@NOSPAM_canada.com>
    Re: perl's severe lack of in-line comment ability <edwards@nouce.trurl.bsd.uchicago.edu>
    Re: perldoc incompetence: perlre /s <lv@aol.com>
    Re: the code for bbs 3 <jurgenex@hotmail.com>
    Re: the code for bbs 3 <robin @ infusedlight.net>
    Re: the code for bbs 3 <noreply@gunnar.cc>
    Re: the code for bbs 3 <tore@aursand.no>
    Re: Tough (for me) regex case <matthew.garrish@sympatico.ca>
    Re: why does this not work <lkirsh@cs.ubc.ca>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

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

Date: Tue, 13 Apr 2004 21:27:33 -0300
From: budman <budman@somewhere.net>
Subject: Re: 3x3 simple puzzle
Message-Id: <pan.2004.04.14.00.27.30.991122@somewhere.net>

On Tue, 13 Apr 2004 22:35:36 +0200, Matija Papec wrote:

>>Do you get to move tiles around, or only rotate them in place?
> 
> Both. :)
> However one can use optimization when rotating so you don't need to get
> through all rotating possibilities. This also saves time as you don't
> have to check for body parts, only for colors. So, you can rotate
> leftmost and rightmost column by 90 deg. ccw, or top and bottom row by
> 90 deg. cw.
> 
> If you only move them around you'll find only one solution (that's a
> good start, I've used perldoc -q permute).

Hmm..  I thought you wanted a solution finder... oh well. :)

Thanks for the permute tip. I was working on a way to swap it, but thought
of using pointers to the original tiles.

I was able to get it to solve and find the 2 solutions in 20 seconds on a
1.8Ghz.

Grid: 3 x 3  Tiles: 9
Possibilities found: 362880
Solution 1: 3 0 5 8 2 7 1 4 6
Solution 2: 3 0 4 8 2 7 1 5 6
Total Secs: 20

Enjoyed the puzzle. :)  
Regards,
Rich

--------------------------------------- 
#!/usr/bin/perl

use strict;

my @Colors = qw(Red Yel Grn Blu);
my $debug = 0;

#          colors [top,right,bottom,left]
my @Tiles = ( [1,3,2,0], [3,3,0,2], [2,3,1,0],
              [2,0,3,1], [1,0,2,3], [1,0,2,3],
              [1,0,2,0], [2,3,1,3], [3,0,3,2]
            );

my $Rows = 3;
my $Cols = 3;

my $begintime = time;
my @Perms;
print "Grid: $Rows x $Cols  Tiles: ",scalar(@Tiles),"\n";

permute([0 .. $#Tiles], []);
print "Possibilities found: ", scalar @Perms, "\n";

my $solutions = 0;
foreach my $list (@Perms) {
        my $success = &CheckTiles($Rows,$Cols,$list);
        if ( $success ) {
           $solutions++;
           print "Solution $solutions: @{$list}\n";
        }
}

print "\nTotal Secs: ", time - $begintime, "\n";

sub CheckTiles {
  my ($Rows,$Cols,$list_ref) = @_;
  my @TileOrder = @{ $list_ref };

  my $MaxRow = $Rows - 1;
  my $MaxCol = $Cols - 1;

  my @Grid;
  my $row = my $col = 0;
  foreach my $i ( @TileOrder ) {
    $Grid[$row][$col++] = $Tiles[$i];
    if ( $col == $Cols ) { $col = 0; $row++; }
  }

  my ($top,$right,$bot,$left) = (0,1,2,3);

  my $e = 0;
 foreach my $r ( 0 .. $MaxRow ) {
 $e = 0;
 foreach my $c ( 0 .. $MaxCol ) {
    print "$r:$c - " if $debug;
    # Check Top Side
    if ( $r != 0 ) {
      printf "T%s-B%s ",$Grid[$r][$c][$top],
                $Grid[$r-1][$c][$bot] if $debug;
      $e++ if $Grid[$r][$c][$top] != $Grid[$r-1][$c][$bot];
    }
    # Check Right Side
    if ( $c != $MaxCol ) {
      printf "R%s-L%s ",$Grid[$r][$c][$right],
                $Grid[$r][$c + 1][$left] if $debug;
      $e++ if $Grid[$r][$c][$right] != $Grid[$r][$c+1][$left];
    }
    # Check Left Side
    if ( $c != 0 ) {
        printf "L%s-R%s ",$Grid[$r][$c][$left],
                $Grid[$r][$c - 1][$right] if $debug;
        $e++ if $Grid[$r][$c][$left] != $Grid[$r][$c-1][$right];
    }
    # Check Bottom Side
    if ( $r != $MaxRow ) {
        printf "B%s-T%s ",$Grid[$r][$c][$bot],
                $Grid[$r + 1][$c][$top] if $debug;
        $e++ if $Grid[$r][$c][$bot] != $Grid[$r+1][$c][$top];
    }

    print " = $e\n" if $debug;

  }
  print "Errors = $e\n\n" if $debug;
  last if $e;
 }
 #print "\n";
 return ( $e ? 0 : 1 );

}

sub permute {
        my @items = @{ $_[0] };
        my @perms = @{ $_[1] };
        unless (@items) {
           #print "@perms\n";
           push @Perms, [@perms];
        } else {
           my(@newitems,@newperms,$i);
           foreach $i (0 .. $#items) {
               @newitems = @items;
               @newperms = @perms;
               unshift(@newperms, splice(@newitems, $i, 1));
               permute([@newitems], [@newperms]);
           }
        }
}





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

Date: Tue, 13 Apr 2004 21:53:10 -0300
From: budman <budman@somewhere.net>
Subject: Re: 3x3 simple puzzle
Message-Id: <pan.2004.04.14.00.53.07.990677@somewhere.net>

On Tue, 13 Apr 2004 21:27:33 -0300, budman wrote:


> I was able to get it to solve and find the 2 solutions in 20 seconds on a
> 1.8Ghz.
> 
> Grid: 3 x 3  Tiles: 9
> Possibilities found: 362880
> Solution 1: 3 0 5 8 2 7 1 4 6
> Solution 2: 3 0 4 8 2 7 1 5 6
> Total Secs: 20

I was able to shave off 3 more seconds by adding another "last if $e" 
into the inner loop.



>     # Check Bottom Side
>     if ( $r != $MaxRow ) {
>         printf "B%s-T%s ",$Grid[$r][$c][$bot],
>                 $Grid[$r + 1][$c][$top] if $debug;
>         $e++ if $Grid[$r][$c][$bot] != $Grid[$r+1][$c][$top];
>     }
> 
>     print " = $e\n" if $debug;

      last if $e;
 
>   }
>   print "Errors = $e\n\n" if $debug;
>   last if $e;
>  }


Rich


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

Date: Tue, 13 Apr 2004 20:30:40 -0400
From: Brad Baxter <bmb@ginger.libs.uga.edu>
Subject: Re: Changing from C thought to Perl
Message-Id: <Pine.A41.4.58.0404132016220.8796@ginger.libs.uga.edu>

On Tue, 13 Apr 2004, Tigerhillside wrote:

> I am trying to understand Perl and having a hard time. I was a
> pretty good C programmer, but Perl seems to make much more sense
> for the kinds of things I am doing now. But I am having problems
> making it "intuitive". From my perspective Perl seems full of
> "side effects", I do something and some pre-defined variable
> changes. I was "taught" that side effects and (essentially)
> global variables are a "bad thing". ISTM that I have to keep some
> internal (to me) table of these variables in mind when I code.
> Has anyone else moved from C to Perl who has some advice. (I know
> the best advice is to write and read and I am doing that.)  Maybe
> it will just take time and all these things will become second
> nature.

Global variables are not a bad thing per se.  Side effects are not a bad
thing per se.  I suspect that you're worrying unnecessarily.  In regards
to Perl's special variables, you only have to think about the ones you're
using.  If you don't need to use them, ignore them.  As you say, as your
familiarity increases, you'll see where they're handy.

Regards,

Brad


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

Date: Tue, 13 Apr 2004 19:14:59 -0400
From: Chris Mattern <matternc@comcast.net>
Subject: Re: die-ing within functions
Message-Id: <7J-dnedaB4zu6eHdRVn-tA@comcast.com>

Sherm Pendley wrote:

> Anno Siegel wrote:
> 
>> Now one could argue that Perl has eval(), and hence dying is never truly
>> unconditional
> 
> That's one down... when's Larry going to get to work on taxes? ;-)
> 
That's been in there from the beginning--since perl is free, you
never pay any taxes on it!
-- 
             Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"


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

Date: Tue, 13 Apr 2004 19:49:42 -0400
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: download my bbs...
Message-Id: <n0%ec.7506$2Z6.628488@news20.bellglobal.com>


"Tore Aursand" <tore@aursand.no> wrote in message
news:pan.2004.04.13.12.48.16.336129@aursand.no...
> On Tue, 13 Apr 2004 12:43:34 +0100, Alan J. Flavell wrote:
> >>> Includes a really cool admin script and a cool header and footer.
>
> >> Could you please include this additional information about your script?
> >>
> >>   * It's insecure.
> >>   * It's a good example on how _not_ to program.
> >> [...]
>
> > Don't you think that the use of the word "cool", even once, would have
> > been enough to warn any serious users off?
>
> Yes.  But I wasn't talking about serious users;  Even not-so-serious
> users, who think "cool" is cool, should avoid scripts from this guy.  He
> makes Matt's scripts look cool.
>

My scripts are cool, damnit! ; )

Matt




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

Date: Tue, 13 Apr 2004 15:50:34 -0700
From: Steven Kuo <skuo@mtwhitney.nsc.com>
Subject: Re: foreach loop test
Message-Id: <Pine.GSO.4.21.0404131548270.11825-100000@mtwhitney.nsc.com>

On Tue, 13 Apr 2004, Robin wrote:

> foreach (@test)
> {
> print;
> }
> 
> for this code, I'd like some way to test if $_ is the last first or middle
> of the array without having to use a while loop....any suggestions?
> Thanks.



One way would be to use references:


my @foo = ( 99, 86, 7, 99, 007 );

my $first = \$foo[0];
my $last  = \$foo[-1];

for (@foo) {
    if (\$_ == $first) {
	print "First. ";
    } elsif (\$_ == $last) {
	print "Last.  ";
    }

    print $_, "\n";
}


See 'perldoc perlref' for details.

-- 
Hope this helps,
Steven



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

Date: Wed, 14 Apr 2004 09:58:58 +1000
From: Gregory Toomey <nospam@bigpond.com>
Subject: Re: foreach loop test
Message-Id: <1164520.ux9dzszaDq@GMT-hosting-and-pickle-farming>

Robin wrote:

> foreach (@test)
> {
> print;
> }
> 
> for this code, I'd like some way to test if $_ is the last first or middle
> of the array without having to use a while loop....any suggestions?
> Thanks.
> --
> Regards,
> -Robin
> --
> robin @ infusedlight.net

I asked this 3 years ago. The "best" solution was along the following lines:

for (@a=((1) x 4)) {

 print \$_, " $_\n" ;

 print "first $_\n" if \$_ == \$a[0] ;
 print "last $_\n" if \$_ == \$a[$#a] ;
 }


SCALAR(0x80ca55c) 1
first 1
SCALAR(0x80d0bb4) 1
SCALAR(0x80d0ca4) 1
SCALAR(0x80d0cf8) 1
last 1


gtoomey


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

Date: Wed, 14 Apr 2004 02:27:22 +0200
From: Tore Aursand <tore@aursand.no>
Subject: Re: foreach loop test
Message-Id: <pan.2004.04.13.23.05.41.693273@aursand.no>

On Tue, 13 Apr 2004 23:59:20 +0200, Matija Papec wrote:
>> foreach (@test)
>> {
>> print;
>> }
>>
>> for this code, I'd like some way to test if $_ is the last first or
>> middle of the array without having to use a while loop....any
>> suggestions?

> [...]
> p.s how would while loop show array index?

He may be thinking of reading data from handles, where one can access $.
to find out which element one is at;

  while ( <DATA> ) {
      print "$. => $_";
  }


-- 
Tore Aursand <tore@aursand.no>
"I am become Death, shatterer of worlds." -- J. Robert Oppenheimer,
 upon witnessing the explosion of the first atomic bomb.


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

Date: Wed, 14 Apr 2004 11:01:28 +1000
From: Matthew Braid <mb@uq.net.au.invalid>
Subject: Re: import() override - comments?
Message-Id: <c5i2h8$8nr$1@bunyip.cc.uq.edu.au>

Anno Siegel wrote:

>>BEGIN {
>>	require Functions; # One of the library packages
>>	my $old_x = \&Functions::x;
>>	sub x {
>>		print "OVERRIDE!\n";
>>		$old_x->(@_);
> 
> 
> This may be a place for "goto &$old_x".  You'd avoid building up a new
> stack frame for each override, and the caller remains the same.

Oh definitely. I stripped this down from an original that did something before 
and after the call to $old_x. Quite a few of the real subs do end with a goto.

>>However, it also means that use'ing a library package like:
>>
>>use Functions qw/x/;
>>
>>can be problematic and often loses overrides. At first I fixed this by using:
> 
> 
> I don't see how.  "use" loads the file only once.  Since overriding
> changes what &Functions::x points to, standard exportation should export
> the overridden version of "x".

I thought this too, but there does seem to be a difference in practice. I think 
it has to do with how the use'd functions are imported (which is why I changed 
the import function).

Example: package T1 is the library package, and T2 is the overrider.

package T1;
use base qw/Exporter/;
our @EXPORT_OK = qw/t1/;

# START IMPORT OVERRIDE
sub import {
	my $class = shift; # class checking omitted
	my (@funcs) = @_;
	my ($caller) = caller();
	for my $func (@funcs) {
		# function name checking omitted
		eval "sub $caller\::$func { goto &$class\::$func }";
		die $@ if $@;
	}
	return 1;
}
# END IMPORT OVERRIDE

sub t1 {
	print "T1::t1!\n";
}
1;
__END__

package T2;
BEGIN {
	require T1;
	*T1::t1 = \&t1;
}
sub t1 {
	# This one's a complete override - no chaining.
	# Doesn't make a difference - just more concise output
	print "T2::t1!\n";
}
1;
__END__

If you then run the following:

use T1 qw/t1/;
require T2;
t1();
exit;
__END__

the output is:

T2::t1!

But if you comment out the import function in T1 so that Exporter behaves as 
usual, the output is:

T1::t1!

And then if you change the script to:

require T1;
require T2;
sub t1 { goto &T1::t1 }
t1();
exit;
__END__

The output is once again:

T2::t1!

This surprised me as well, but that's what's happening.

> ...nor do I see how this would help.  Maybe you are doing something I'm
> not expecting.

I don't think so - as you can see it even happens in tiny stub cases like that 
above. Maybe a rogue perl version? I'm using 5.8.1.

> One problem I see is that the result of overriding may depend on the
> sequence in which (the same) overriding actions happen.  This is not
> good, but I don't see how it can be avoided with this kind of subroutine
> chaining.

Order dependance is expected here (hehe - I ran into troubles with that early 
on). I'm very careful to ensure the override packages are require'd in the order 
they're specified because of this, and that all overrides are require'd before 
any actual processing is done.

I'm quite happy to override the import method (obviously with a few more checks 
than that above), but it just seems that for things like this I shouldn't really 
have to. What's the reasoning for Exporter working like this?

MB



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

Date: Tue, 13 Apr 2004 22:17:30 GMT
From: "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com>
Subject: Re: MS Access Date/Time Data type mismatch
Message-Id: <_FZec.1286$le3.855@news04.bloor.is.net.cable.rogers.com>

Access delimits dates with #, not '.

-- 
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(No private e-mails, please)



"Jacquo Johnson" <genxgeek@hotmail.com> wrote in message
news:22a88b03.0404121845.27be69a1@posting.google.com...
> I am receiving the following error:
>
> MS Access Date/Time DBD::ODBC::st execute failed: [Microsoft][ODBC
> Data type mismatch in criteria expression
>
> when executing the following code.
>
> $sqlstatement="SELECT [Import Date], [Transaction Type], [Item
> Number]" .
> "FROM [Open Transactions] WHERE [Import Date] > '2004/02/01
> 11:16:16'";
>
> $sth = $dbh->prepare($sqlstatement);
> $sth->execute ||
>        die "Could not execute SQL statement ... maybe invalid?";
>
> The [Import Date] is defined as an MS Date/Time type and contains the
> following Db entry format: 4/12/2004 9:22:37 AM
>
> I've tried numerous literal values within the SELECT/WHERE but I am
> having absolutely no luck with other formats as well as locating a
> solution via the web.
>
> Any help would be greatly appreciated!
>
> Thanks!




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

Date: Tue, 13 Apr 2004 22:25:55 GMT
From: Darrin Edwards <edwards@nouce.trurl.bsd.uchicago.edu>
Subject: Re: perl's severe lack of in-line comment ability
Message-Id: <slrnc7oq7j.g2d.edwards@trurl.bsd.uchicago.edu>

In article <87smf958l6.fsf@jidanni.org>, Dan Jacobson wrote:
> Gentlemen, "#" until the end of the line is not good enough for
> comments.
> 
> Found in perlfaq7.pod
>        How can I comment out a large block of perl code?
> 
> Yes, but what about the very smallest pieces of code? C's */  /* can
> be used almost anywhere, but what about perl?
> 
> For instance, say I want to comment out "$F[0]," in
> perl -nalwe 'print $F[0],$F[1]'
> with out otherwise disturbing anything or being interrogated as to my
> motives or being told to make it into two lines:
> #perl -nalwe 'print $F[0],$F[1]'
> perl -nalwe 'print $F[1]'
> 
> It seems perl might be in need of a new operator c{}, modeled on q{},
> that will comment stuff in-line:
> perl -nalwe 'print c{$F[0],}$F[1]'
> or something like that.
> 
> Of course I didn't check if the name "c" has been used already, or if
> this "is impossible to implement", I'm just saying is that Larry
> forgot something.

In many cases you might be able to get away with the substituion
/* => #  (for comment start)
*/ => \n (for comment end)

so in your above example:

perl -nalwe 'print #$F[0],
$F[1]'

(note the inserted newline).

At the command line, this may be OS dependent; although it seems to
work on at least zsh under linux:

trurl:~>echo 'left1 right1
left2 right2
left3 right3' | perl -nalwe 'print $F[0], $F[1]'
left1right1
left2right2
left3right3
trurl:~>echo 'left1 right1
left2 right2
left3 right3' | perl -nalwe 'print #$F[0],      
pipe quote> $F[1]'
right1
right2
right3

Within a script I would not expect OS dependencies.  This might still
not be as general as you'd like, but it at least seems to work for the
example you gave...  (The point being that while '#' comments to the
end of line, perl syntax usually _doesn't_ depend on the presence or
absence of newlines / whitespace, but rather explicit markers like
';'.  The obvious exceptions would be things like quote-like
operators, regular expressions, etc.)

Hope this helps.
-- 
Darrin


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

Date: Tue, 13 Apr 2004 19:00:21 -0500
From: l v <lv@aol.com>
Subject: Re: perldoc incompetence: perlre /s
Message-Id: <ha%ec.198$Ho2.6397@dfw-read.news.verio.net>

Vetle Roeim wrote:

> * Michele Dondi
> 
>>On 11 Apr 2004 19:59:03 -0700, xah@xahlee.org (Xah Lee) wrote:
>>
>>
>>>today i'm writing some perl code involving regex. I wanted to find out
>>
>>[snip]
>>
>>>Fucking no mention of it. Fuck Perl and fuck Perl coders.
>>
>>Am I the only one seeing the contradiction?!?
> 
> 
>   What he does in the privacy of his own home is none of our business.
>   ;-)
> 
> 
I thought he was talking about himself as well.

Len



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

Date: Tue, 13 Apr 2004 23:37:26 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: the code for bbs 3
Message-Id: <WQ_ec.29733$hd3.6098@nwrddc03.gnilink.net>

Robin wrote:
> can someone point out a security hole? Or did I come to the wrong
> place?

Yes and yes.

jue




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

Date: Tue, 13 Apr 2004 16:42:38 -0700
From: "Robin" <robin @ infusedlight.net>
Subject: Re: the code for bbs 3
Message-Id: <c5hv5q$egs$1@reader2.nmix.net>

i don't know whether to laugh or fuckin' cry...haha. waaaahhh...
-robin





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

Date: Wed, 14 Apr 2004 02:25:33 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: the code for bbs 3
Message-Id: <c5i0dg$1uh5j$1@ID-184292.news.uni-berlin.de>

Robin wrote:
> i don't know whether to laugh or fuckin' cry...haha. waaaahhh...

I don't see what's so funny. The main security issues follow by the 
fact that you are using CGI, not that Perl happens to be the 
programming language. Accordingly, if you want help with security, 
you'd better post to a group that deals with CGI. (But don't forget to 
*first* study some tutorials about CGI security.)

-- 
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl



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

Date: Wed, 14 Apr 2004 02:27:23 +0200
From: Tore Aursand <tore@aursand.no>
Subject: Re: the code for bbs 3
Message-Id: <pan.2004.04.14.00.24.25.769494@aursand.no>

On Tue, 13 Apr 2004 10:54:39 -0700, Robin wrote:
> can someone point out a security hole? Or did I come to the wrong place?

I pointed out _at least_ two security holes.  Didn't you bother to read my
post?


-- 
Tore Aursand <tore@aursand.no>
"I didn't have time to write a short letter, so I wrote a long one
 instead." -- Mark Twain


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

Date: Tue, 13 Apr 2004 19:47:41 -0400
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: Tough (for me) regex case
Message-Id: <u__ec.7505$2Z6.627917@news20.bellglobal.com>


"Rob Perkins" <rob_perkins@hotmail.com> wrote in message
news:fm9o7015jr0s739h201p23k33qm7cv4iq7@4ax.com...
> [x-posted to m.p.d.f because it concerns the .NET Framework's regex-er
> as well...]
>
> "Matt Garrish" <matthew.garrish@sympatico.ca> wrote:
>
> >Does it make a little more sense now why Microsoft's implementation is
> >wrong?
>
> I'm not ready to call it "wrong", but I'm getting close. OK, so we
> start with:
>
> /(?<!")"(?!")(.*?)(?<!")"(?!")/
>
> Removing the lookahead and lookbehind stuff, (in other words, don't
> worry about the paired doublequote case) I get a pattern which reads:
>
> /"(.*?)"/
>
> ...which includes the quotes in the match, in the .NET implemenation.
> In Perl, the quotes get consumed before the match is constructed. But
> if I do this:
>
> /".*?"/
>
> Then the regex matches include the quote characters, in either
> implementation. So apparantly in the .NET implementation there is no
> semantic difference between the two smaller cases.
>
> And... now it begins to make a bit more sense. One implementor decided
> there was no distinction in that difference. Another did.
>
> It makes me wonder if this .NET implementation approach is shared by
> other implementations. IOW, is the desirable (for my problem) behavior
> unique to Perl 5, or is the undesirable behavior unique to .NET?
>

To put it bluntly, who cares?

You should figure out if you're using the .net framework or if you're
writing a perl script and write your code according the rules of the
language. I have no idea how regular expressions are implemented within
 .net, and am not going to figure them out for you.

Chances are you've misread the documentation (i.e., for all I know there may
be an implicit capture around the entire pattern in .net). It could also be
a poorly written program you're using to test with. If you run into any perl
problems with your regex feel free to post again, otherwise please stick to
the appropriate forum.

Matt




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

Date: Tue, 13 Apr 2004 15:15:46 -0700
From: Lowell Kirsh <lkirsh@cs.ubc.ca>
Subject: Re: why does this not work
Message-Id: <c5hoqi$rjc$1@mughi.cs.ubc.ca>

It seems a bit verbose to be using in my throw-away scripts. Perhaps 
it'd be useful for longer programs. Thanks.

A. Sinan Unur wrote:
> Lowell Kirsh <lkirsh@cs.ubc.ca> wrote in news:c5heea$p2i$1
> @mughi.cs.ubc.ca:
> 
> 
>>I'm trying to write a simple file-copy script on Windows and I can't 
>>figure out why it's not working. Here's part of what I have:
>>
>>my $fromDir = "C:\\Documents and Settings\\user\\Application 
>>Data\\Mozilla\\Profiles\\default\\iw2wx3e0.slt\\";
> 
> 
> use strict;
> use warnings;
> 
> use File::Spec;
> 
> my $full_path = File::Spec->catfile(
>     $ENV{USERPROFILE}, 'Application Data', 'Mozilla', 
>     'Profiles', 'default', 'iw2wx3e0.slt', 'bookmarks.html'
> );
> 
> print qq{"$full_path"};
> 
> Reduces time spent escaping quotes, slashes etc.
> 


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

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 6398
***************************************


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