Re: regrouping lines of STDIN

[Philip Newton]

On 19 Mar 2003 at 14:12, [EMAIL PROTECTED] wrote:

[sending attachments as UUEncoded to work around auto-HTML MSexChange 
misfeature]
> Well, I've tried that with this message...

Looks good to me.

Cheers,
Philip
-- 
Philip Newton <[EMAIL PROTECTED]>

RE: regrouping lines of STDIN

[TSchutzerWeissmann]

Philip Newton has the answer?

> Here's a very non-elegant, but effective (at least, it was for me), 
> workaround:
> 
> when you have an email message open, choose File | Properties 
> (or press 
> Alt+Enter), then "sending options", then the "Internet" tab (if it 
> isn't already selected), then "send attachments as: UUEncode". Press 
> Enter twice to confirm. (The exact names may be different; we have a 
> German version of Outlook here.)
>
> Apparently, what happens is that Outlook then does not send a MIME-
> Version: headers and Exchange doesn't dare wreak its havoc 
> and bung an 
> HTML version on the end.
> 
> Disadvantage: you have to do this on *every* message you send out. 
> (Though after a while your finger will probably get used to it... at 
> least, that's how it was with me. Thank goodness the server is 
> configured differently now.)

Well, I've tried that with this message...

Thanks,
Tom SW

Re: regrouping lines of STDIN

[Philip Newton]

[Apologies for coming into this discussion so late]

On 10 Mar 2003 at 2:00, Dave Cross wrote:

> From: "Blackwell, Lee [IT]" <[EMAIL PROTECTED]>
> Date: 3/10/03 9:51:14 AM
> 
> >> first let me apologise, I know this mail will be 
> >> accompanied by an HTML version & I don't know how to 
> >> prevent it. Outlook swears I'm using plain text but 
> >> somehow it doesn't end up that way. So, sorry...
> >
> > Outlook->Tools/Options/Mail format tab/Send in this 
> > message format = Plain text
> 
> Unfortunately, it's possible for the Exchange server to be configured
> to overrid this setting and send an HTML attachment anyway.

Indeed. Our company did this for a while.

Here's a very non-elegant, but effective (at least, it was for me), 
workaround:

when you have an email message open, choose File | Properties (or press 
Alt+Enter), then "sending options", then the "Internet" tab (if it 
isn't already selected), then "send attachments as: UUEncode". Press 
Enter twice to confirm. (The exact names may be different; we have a 
German version of Outlook here.)

Apparently, what happens is that Outlook then does not send a MIME-
Version: headers and Exchange doesn't dare wreak its havoc and bung an 
HTML version on the end.

Disadvantage: you have to do this on *every* message you send out. 
(Though after a while your finger will probably get used to it... at 
least, that's how it was with me. Thank goodness the server is 
configured differently now.)

Cheers,
Philip
-- 
Philip Newton <[EMAIL PROTECTED]>

Re: regrouping lines of STDIN

[Nicholas Clark]

On Thu, Mar 13, 2003 at 04:34:39PM +, Jasper McCrea wrote:
> Nicholas Clark wrote:
> > 
> > On Mon, Mar 10, 2003 at 04:04:54PM +, Jasper McCrea wrote:

> > > If $_ isn't too big, the latter is probably more efficient. I said probably.
> > 
> > use Benchmark;  # Recent experience with writing test programs for the

> Something tells me you think I didn't use Benchmark here. I don't know why.

No, I wasn't clear. Sorry - my fault - and I didn't mean to cause offence.

I did suspect that you'd used Benchmark, or some other quantitative timing
tool, given that you were careful to stress "probably". But I wasn't
confident that it was clear to other people who'd not tried this sort of
thing that much that it was important.

The timings tools aren't great - they generate "statistics"
(lies, damn lies, ) but they are better than guessing, where one
usually gets it wrong.

> However I did use Benchmark, and while what I said seemed to be borne out, there
> was bugger all difference in real terms. Anyone who wrote any code thinking
> about whether one would be faster would already have wasted more time thinking
> about it than would have been saved if the program ran until the end of time.

That's usually what I found too. Unless I got lucky, and found something that
turned out to be refactorable into something conceptually dissimilar that
worked much more efficiently.

Nicholas Clark

Re: regrouping lines of STDIN

[Adam Spiers]

Jasper McCrea ([EMAIL PROTECTED]) wrote:
> I agree. Pub good. (But I'd rather spend the time breeding crabsticks)

That was an obscure reference to Harry Hill, for those who don't have
to suffer a flatmate with zany TV taste.  OK, I have to admit it was
pretty funny...

Re: regrouping lines of STDIN

[Jasper McCrea]

Nicholas Clark wrote:
> 
> On Mon, Mar 10, 2003 at 04:04:54PM +, Jasper McCrea wrote:
> > The /g just removes the need for parantheses in the regex. ie
> >
> > ($bar) = /(foo)/
> >
> > is equivalent to:
> >
> > ($bar) =  /foo/g
> >
> > If $_ isn't too big, the latter is probably more efficient. I said probably.
> 
> use Benchmark;  # Recent experience with writing test programs for the
> use Benchmark;  # tutorial I gave at the German Perl workshop proved very
> use Benchmark;  # interesting. Conventional wisdom isn't always "right", or
> use Benchmark;  # at least clear cut enough to write small test cases
> use Benchmark;  # For example, I failed to write a program with $& that was.
> use Benchmark;  # slower than one with something like /(.*)/, and I found that
> use Benchmark;  # a regexp with /(...)/ capturing parentheses that are only used
> use Benchmark;  # for grouping actually was faster (in a tight test loop) than
> use Benchmark;  # using the "correct" non-capturing /(?:...)/
> use Benchmark;  # However, "normality" was restored once the //o flag was
> use Benchmark;  # used - then the (?:...) was faster. It appears that regexp
> use Benchmark;  # compilation time - even for just 2 more bytes "?:", is
> use Benchmark;  # significant

Something tells me you think I didn't use Benchmark here. I don't know why.

However I did use Benchmark, and while what I said seemed to be borne out, there
was bugger all difference in real terms. Anyone who wrote any code thinking
about whether one would be faster would already have wasted more time thinking
about it than would have been saved if the program ran until the end of time.
 
> There. Have I annoyed everyone with my (non) subliminal message.
> 
> And use a profiler first to work out where your slowness is.
> It saves you optimising the already fast things, and should get you to
> the pub sooner. (Or whatever else turns you on)

I agree. Pub good. (But I'd rather spend the time breeding crabsticks)

Jasper
-- 
Kirk: This is a mystery, and I don't like mysteries. They give me a 
  bellyache, and I've got a beauty right now.

Re: regrouping lines of STDIN

[Nicholas Clark]

On Mon, Mar 10, 2003 at 04:04:54PM +, Jasper McCrea wrote:
> The /g just removes the need for parantheses in the regex. ie
> 
> ($bar) = /(foo)/
> 
> is equivalent to:
> 
> ($bar) =  /foo/g
> 
> If $_ isn't too big, the latter is probably more efficient. I said probably.

use Benchmark;  # Recent experience with writing test programs for the
use Benchmark;  # tutorial I gave at the German Perl workshop proved very
use Benchmark;  # interesting. Conventional wisdom isn't always "right", or
use Benchmark;  # at least clear cut enough to write small test cases
use Benchmark;  # For example, I failed to write a program with $& that was.
use Benchmark;  # slower than one with something like /(.*)/, and I found that
use Benchmark;  # a regexp with /(...)/ capturing parentheses that are only used
use Benchmark;  # for grouping actually was faster (in a tight test loop) than
use Benchmark;  # using the "correct" non-capturing /(?:...)/
use Benchmark;  # However, "normality" was restored once the //o flag was
use Benchmark;  # used - then the (?:...) was faster. It appears that regexp
use Benchmark;  # compilation time - even for just 2 more bytes "?:", is
use Benchmark;  # significant

There. Have I annoyed everyone with my (non) subliminal message.

And use a profiler first to work out where your slowness is.
It saves you optimising the already fast things, and should get you to
the pub sooner. (Or whatever else turns you on)

Nicholas Clark

Re: regrouping lines of STDIN

[Jasper McCrea]

Paul Makepeace wrote:
> 
> On Fri, Mar 07, 2003 at 02:30:53PM +, Andrew Wilson wrote:
> > On Fri, Mar 07, 2003 at 01:24:43PM +, Joel Bernstein wrote:
> > > >   while () {
> > > >   if (my ( $code ) = /$rxp/g) {
> > > if ( my ($code) =~ /$rxp/g ) ... surely? ie, s/=/=~/
> >
> > That's not a substution, it's assigning the result of the pattern match
> > to $code.  /$rxp/g is matching against $_ not against $code.
> 
> $_ is what you'd expect to be looking at from . $rxp presumably
> includes a match parens so the value of $1 gets dumped into $code (which
> is in a list context).
> 
> So in effect,
> 
> my ($code) = $_ =~ /a (reg) ex/;
> 
> I'm not clear on the point of the /g though.

The /g just removes the need for parantheses in the regex. ie

($bar) = /(foo)/

is equivalent to:

($bar) =  /foo/g

If $_ isn't too big, the latter is probably more efficient. I said probably.

Jasper
-- 
Damn you, brocolli! - Stewie Griffin

Re: regrouping lines of STDIN - Outlook does what it wants

[Nicholas Clark]

On Mon, Mar 10, 2003 at 11:44:00AM +, Mark Fowler wrote:

> People could always offer to help the Siesta project to get it to a state
> where we could use it to run all the London.pm mail.  Then doing things
> like this is quite straight forward.

What does Siesta still need done in order to be useful enough to run
the London.pm list?

Nicholas Clark

Re: regrouping lines of STDIN

[Robin Szemeti]

On Monday 10 March 2003 13:31, Andrew Wilson wrote:

> ($foo) = 'foo boo moo' =~ /\w+/g;
> print "$foo\n";

> foo

ahh ! .. now I have to confess I didn't know that!   well well ... one lives 
and learns.

-- 
Robin Szemeti

Re: regrouping lines of STDIN

[Robin Szemeti]

On Monday 10 March 2003 12:54, Lusercop wrote:
> On Mon, Mar 10, 2003 at 11:16:18AM +, Robin Szemeti wrote:

> > > /g evaluated in a list context causes =~ to return a list of all
> > > bracketed submatches. That's what causes =~ to have an appropriate
> > > return value for assigning to a list lvalue. Otherwise it would return
> > > 1 or 0.

> Yes, I'm aware this is the conclusion you came to. I just can't see how
> you managed it. In every way I try to read it, I come to the conclusion
> that Shevek is talking about the return of a /g being applied in a list
> context or a scalar context, and that he's well aware of the difference
> between the two. I cannot parse the quoted text in such a way as to say
> that /g forces a list or scalar context.

oh arse ..this is turnig into pedantry half hour isn't it.

 [here we go ..]

 /g evaluated in a list context causes =~ to return a list of all
 bracketed submatches.

 [ OK ... so we are discussing /g ]

 That's what causes =~ to have an appropriate return value for assigning to a 
list lvalue.

 [ we are still talking about the action of /g  ... ]

 Otherwise it would return 1 or 0.

 [ I parse that as "otherwise if it didnt have the /g there it would return 1 
or 0" which is not true .. ]

 past caring now  

-- 
Robin Szemeti

Re: regrouping lines of STDIN - Outlook does what it wants

[Joel Bernstein]

On Mon, Mar 10, 2003 at 01:33:48PM -, [EMAIL PROTECTED] wrote:
> to David Cantrell's bemusement
> > > Still, it's Lent, humility and no alchohol the order of the 40 days.
> > 
> > Are you sure you're on the right list?
> 
> o yes. You've all been very helpful. It's almost a shame I'm leaving for the
> Gulf on Thursday to fight for Jesus.
>
Bah, let the git fight his own battles!
np: The Tiger Lillies - Banging In The Nails.

/joel

RE: regrouping lines of STDIN - Outlook does what it wants

[TSchutzerWeissmann]

Title: RE: regrouping lines of STDIN - Outlook does what it wants





to David Cantrell's bemusement
> > Still, it's Lent, humility and no alchohol the order of the 40 days.
> 
> Are you sure you're on the right list?


o yes. You've all been very helpful. It's almost a shame I'm leaving for the Gulf on Thursday to fight for Jesus.

Re: regrouping lines of STDIN

[Andrew Wilson]

On Sun, Mar 09, 2003 at 07:21:19PM +, Robin Szemeti wrote:
> no no my pretty little vampire slayer ... its not the /g that determines list 
> or scalar evaluation of the regex ... its what is wanted by the caller. I 
> suspect it is not entirely unconnected with #perldoc -f wantarray ...
> 
> my($foo) = 'blah' =~ /(\w+)/;
> 
> in this case $foo => 'blah'  .. the brackets in my($foo) cause the regex to 
> be evaluated in list context ... 
> 
> my $foo= 'blah' =~ /(\w+)/;
> 
> in this case $foo => 1 .. the lack of brackets in my $foo cause the regex to 
> be evaluated in scalar  context ...
> 
> what paul was pointing out was that it is pointless doing
> 
> my($foo) = 'blah blah blah' =~ /(\w+)/g;

It is pointless doing that, but, you've assumed that the regex being
passed to the script has a caputing pair of ().  If it doesn't then the
match returns 1.  If you use a regex without a capturing pair of () but
tack a /g on it then it returns whatever was matched.
 
my($foo) = 'foo boo moo' =~ /(\w+)/g;
print "$foo\n";

($foo) = 'foo boo moo' =~ /\w+/g;
print "$foo\n";

($foo) = 'foo boo moo' =~ /(\w+)/;
print "$foo\n";

($foo) = 'foo boo moo' =~ /\w+/;
print "$foo\n";

foo
foo
foo
1

andrew
-- 
Cancer: (June 22 - July 22)
You've long been familiar with Marshall's theory of the Marginal
Disutility of the Labourer, but you've just figured out that it means
you'll now have to deep-fry stuff for 40 hours a week.


pgp0.pgp
Description: PGP signature

Re: regrouping lines of STDIN - Outlook does what it wants

[David Cantrell]

On Mon, Mar 10, 2003 at 11:42:51AM -, [EMAIL PROTECTED] wrote:

> Still, it's Lent, humility and no alchohol the order of the 40 days.

Are you sure you're on the right list?

-- 
David Cantrell | Member of the Brute Squad | http://www.cantrell.org.uk/david

There are many different types of sausages.  The best are
from the north of England.  The wurst are from Germany.
  -- seen in alt.2eggs.sausage.beans.tomatoes.2toast.largetea.cheerslove

Re: regrouping lines of STDIN

[Lusercop]

On Mon, Mar 10, 2003 at 11:16:18AM +, Robin Szemeti wrote:
> On Monday 10 March 2003 10:08, Lusercop wrote:
> > what on earth made you write your paragraph above. Shevek makes it quite
> > clear that this is the case. 
> well ... my reading of the original hang on .. quote time:
> > /g evaluated in a list context causes =~ to return a list of all bracketed 
> > submatches. That's what causes =~ to have an appropriate return value for 
> > assigning to a list lvalue. Otherwise it would return 1 or 0.
> was that Shevek thought the /g was somehow involved in the decision as to 
> whether a list or scalar value was returned, and it isn't.  Its the caller 

Yes, I'm aware this is the conclusion you came to. I just can't see how
you managed it. In every way I try to read it, I come to the conclusion
that Shevek is talking about the return of a /g being applied in a list
context or a scalar context, and that he's well aware of the difference
between the two. I cannot parse the quoted text in such a way as to say
that /g forces a list or scalar context.

-- 
Lusercop.net - LARTing Lusers everywhere since 2002

RE: regrouping lines of STDIN - Outlook does what it wants

[TSchutzerWeissmann]

Title: RE: regrouping lines of STDIN - Outlook does what it wants





Joel, reassuringly,


> one... In other words, sending MIME-encoded mail with html 
> and plaintext
> versions should just DTRT in most clients. 


I'll stop apologising then. It still keeps me out of some mailing lists where I (almost) knew what I was talking about. 

Still, it's Lent, humility and no alchohol the order of the 40 days.


Tom SW

Re: regrouping lines of STDIN - Outlook does what it wants

[Mark Fowler]

> Alternatively, we could run something like demime to strip out all
> non-text/plain parts, but that will probably break PGP signing and
> stuff.

No, as that's subtly different.  The PGP signature is a normal attachment,
whereas html mail uses multipart/alternative etc to indicate that this is
an alternative format of the same data.

People could always offer to help the Siesta project to get it to a state
where we could use it to run all the London.pm mail.  Then doing things
like this is quite straight forward.

Mark.

-- 
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, [EMAIL PROTECTED], http://twoshortplanks.com/};

Re: regrouping lines of STDIN - Outlook does what it wants

[Joel Bernstein]

On Mon, Mar 10, 2003 at 10:07:16AM -, [EMAIL PROTECTED] wrote:
> Thanks Lee,
> 
> > Outlook->Tools/Options/Mail format tab/Send in this message 
> > format = Plain
> > text
> 
>but no. This message is plain text by that method, enjoy...

It would seem that Outhouse is taking your "send as Plain text" to mean
"send a plain text MIME component as well as the HTML version". While
this may not really be what you want, it's very rare that an MUA
configured to read plain text mail by preference would choose the
text/html portion of a multipart/alternative message over the text/plain
one... In other words, sending MIME-encoded mail with html and plaintext
versions should just DTRT in most clients. 

Alternatively, we could run something like demime to strip out all
non-text/plain parts, but that will probably break PGP signing and
stuff.

/joel

Re: regrouping lines of STDIN

[Robin Szemeti]

On Monday 10 March 2003 10:08, Lusercop wrote:
> On Sun, Mar 09, 2003 at 07:21:19PM +, Robin Szemeti wrote:
> > On Sunday 09 March 2003 15:10, Shevek wrote:
> > > /g evaluated in a list context causes =~ to return a list of all
> > > bracketed
>
> ^^ note: no "is"
>
> > no no my pretty little vampire slayer ... its not the /g that determines
> > list or scalar evaluation of the regex ... its what is wanted by the
> > caller. I
>
> what on earth made you write your paragraph above. Shevek makes it quite
> clear that this is the case. 

well ... my reading of the original hang on .. quote time:

> /g evaluated in a list context causes =~ to return a list of all bracketed 
> submatches. That's what causes =~ to have an appropriate return value for 
> assigning to a list lvalue. Otherwise it would return 1 or 0.

was that Shevek thought the /g was somehow involved in the decision as to 
whether a list or scalar value was returned, and it isn't.  Its the caller 
that determines the return type, the /g just allows the list to be bigger 
than 1 item. (at least thats the way I understand it).  /g and 'otherwise it 
would return 1 or 0' are entirely unconnected.

> What kind of crack are you on?

builders crack

-- 
Robin Szemeti

Re: regrouping lines of STDIN

[Tim Sweetman]

Lusercop wrote:
> 
> On Sun, Mar 09, 2003 at 07:21:19PM +, Robin Szemeti wrote:
> > On Sunday 09 March 2003 15:10, Shevek wrote:
> > > /g evaluated in a list context causes =~ to return a list of all bracketed
> ^^ note: no "is"
> > no no my pretty little vampire slayer ... its not the /g that determines list
> > or scalar evaluation of the regex ... its what is wanted by the caller. I
> 
> what on earth made you write your paragraph above. Shevek makes it quite
> clear that this is the case. What kind of crack are you on?

A geological fault?

Ti'

RE: regrouping lines of STDIN - Outlook does what it wants

[TSchutzerWeissmann]

Title: RE: regrouping lines of STDIN - Outlook does what it wants





Thanks Lee,


> Outlook->Tools/Options/Mail format tab/Send in this message 
> format = Plain
> text


but no. This message is plain text by that method, enjoy...


Tom SW

Re: regrouping lines of STDIN

[Lusercop]

On Sun, Mar 09, 2003 at 07:21:19PM +, Robin Szemeti wrote:
> On Sunday 09 March 2003 15:10, Shevek wrote:
> > /g evaluated in a list context causes =~ to return a list of all bracketed
^^ note: no "is"
> no no my pretty little vampire slayer ... its not the /g that determines list 
> or scalar evaluation of the regex ... its what is wanted by the caller. I 

what on earth made you write your paragraph above. Shevek makes it quite
clear that this is the case. What kind of crack are you on?

-- 
Lusercop.net - LARTing Lusers everywhere since 2002

RE: regrouping lines of STDIN

[Dave Cross]

From: "Blackwell, Lee [IT]" <[EMAIL PROTECTED]>
Date: 3/10/03 9:51:14 AM

>> first let me apologise, I know this mail will be 
>> accompanied by an HTML version & I don't know how to 
>> prevent it. Outlook swears I'm using plain text but 
>> somehow it doesn't end up that way. So, sorry...
>
> Outlook->Tools/Options/Mail format tab/Send in this 
> message format = Plain text

Unfortunately, it's possible for the Exchange server to be configured
to overrid this setting and send an HTML attachment anyway.

Dave...

-- 


"Let me see you make decisions, without your television"
   - Depeche Mode (Stripped)

RE: regrouping lines of STDIN

[Blackwell, Lee [IT]]

> first let me apologise, I know this mail will be accompanied by an 
> HTML version & I don't know how to prevent it. Outlook swears I'm 
> using plain text but somehow it doesn't end up that way. So, sorry...

Outlook->Tools/Options/Mail format tab/Send in this message format = Plain
text

That's what I got here.  I'm still working on the boss to allow a *nix
machine on my desktop... 

Lee

Re: regrouping lines of STDIN

[Robin Szemeti]

On Sunday 09 March 2003 15:10, Shevek wrote:
> On Sun, 9 Mar 2003, Paul Makepeace wrote:



> > my ($code) = $_ =~ /a (reg) ex/;
> >
> > I'm not clear on the point of the /g though.
>
> /g evaluated in a list context causes =~ to return a list of all bracketed
> submatches. That's what causes =~ to have an appropriate return value for
> assigning to a list lvalue. Otherwise it would return 1 or 0.
 
no no my pretty little vampire slayer ... its not the /g that determines list 
or scalar evaluation of the regex ... its what is wanted by the caller. I 
suspect it is not entirely unconnected with #perldoc -f wantarray ...

my($foo) = 'blah' =~ /(\w+)/;

in this case $foo => 'blah'  .. the brackets in my($foo) cause the regex to 
be evaluated in list context ... 

my $foo= 'blah' =~ /(\w+)/;

in this case $foo => 1 .. the lack of brackets in my $foo cause the regex to 
be evaluated in scalar  context ...

what paul was pointing out was that it is pointless doing

my($foo) = 'blah blah blah' =~ /(\w+)/g;

because the subsequent matches after the first are lost ... to be of any use 
the result of the regex needs to be assigned to an array (well .. a list 
bigger than 1 anyway)

my(@foo) = 'blah blah blah' =~ /(\w+)/g;

-- 
Robin Szemeti

Re: regrouping lines of STDIN

[Paul Makepeace]

On Sun, Mar 09, 2003 at 03:10:06PM +, Shevek wrote:
> On Sun, 9 Mar 2003, Paul Makepeace wrote:
> 
> > On Fri, Mar 07, 2003 at 02:30:53PM +, Andrew Wilson wrote:
> > > On Fri, Mar 07, 2003 at 01:24:43PM +, Joel Bernstein wrote:
> > > > >   while () {
> > > > >   if (my ( $code ) = /$rxp/g) {
> > > > if ( my ($code) =~ /$rxp/g ) ... surely? ie, s/=/=~/
> > > 
> > > That's not a substution, it's assigning the result of the pattern match
> > > to $code.  /$rxp/g is matching against $_ not against $code.
> > 
> > $_ is what you'd expect to be looking at from . $rxp presumably
> > includes a match parens so the value of $1 gets dumped into $code (which
> > is in a list context).
> > 
> > So in effect,
> > 
> > my ($code) = $_ =~ /a (reg) ex/;
> > 
> > I'm not clear on the point of the /g though.
> 
> /g evaluated in a list context causes =~ to return a list of all bracketed 
> submatches. That's what causes =~ to have an appropriate return value for 
> assigning to a list lvalue. Otherwise it would return 1 or 0.

The ($code) creates a list lvalue,

$ perl -lne '($b) = /(\w+)/; print $b'
hello world
hello
$

Paul

-- 
Paul Makepeace ... http://paulm.com/

"If your dog were blue, would you be sad, then it'd be a downer."
   -- http://paulm.com/toys/surrealism/

Re: regrouping lines of STDIN

[Shevek]

On Sun, 9 Mar 2003, Paul Makepeace wrote:

> On Fri, Mar 07, 2003 at 02:30:53PM +, Andrew Wilson wrote:
> > On Fri, Mar 07, 2003 at 01:24:43PM +, Joel Bernstein wrote:
> > > > while () {
> > > > if (my ( $code ) = /$rxp/g) {
> > > if ( my ($code) =~ /$rxp/g ) ... surely? ie, s/=/=~/
> > 
> > That's not a substution, it's assigning the result of the pattern match
> > to $code.  /$rxp/g is matching against $_ not against $code.
> 
> $_ is what you'd expect to be looking at from . $rxp presumably
> includes a match parens so the value of $1 gets dumped into $code (which
> is in a list context).
> 
> So in effect,
> 
> my ($code) = $_ =~ /a (reg) ex/;
> 
> I'm not clear on the point of the /g though.

/g evaluated in a list context causes =~ to return a list of all bracketed 
submatches. That's what causes =~ to have an appropriate return value for 
assigning to a list lvalue. Otherwise it would return 1 or 0.

S.

-- 
Shevekhttp://www.anarres.org/
I am the Borg. http://design.anarres.org/

Re: regrouping lines of STDIN

[Paul Makepeace]

On Fri, Mar 07, 2003 at 02:30:53PM +, Andrew Wilson wrote:
> On Fri, Mar 07, 2003 at 01:24:43PM +, Joel Bernstein wrote:
> > >   while () {
> > >   if (my ( $code ) = /$rxp/g) {
> > if ( my ($code) =~ /$rxp/g ) ... surely? ie, s/=/=~/
> 
> That's not a substution, it's assigning the result of the pattern match
> to $code.  /$rxp/g is matching against $_ not against $code.

$_ is what you'd expect to be looking at from . $rxp presumably
includes a match parens so the value of $1 gets dumped into $code (which
is in a list context).

So in effect,

my ($code) = $_ =~ /a (reg) ex/;

I'm not clear on the point of the /g though.

Paul



-- 
Paul Makepeace ... http://paulm.com/

"What is smeg good for? May 3rd."
   -- http://paulm.com/toys/surrealism/

Re: regrouping lines of STDIN

[Earle Martin]

On Fri, Mar 07, 2003 at 01:59:41PM +, Joel Bernstein wrote:
> it's a unicode character which likes buffy.

Is that sort of like a fictional character?



-- 
$x='4a75737420616e6f74686572205065726c'#Earle Martin
.'206861636b65720d0a';for(0..26){print #http://downlode.org/
chr(hex(substr($x,$y,2)));$y=$y+2;}#   http://grault.net/grubstreet/

Re: regrouping lines of STDIN

[Andrew Wilson]

On Fri, Mar 07, 2003 at 01:24:43PM +, Joel Bernstein wrote:
> > while () {
> > if (my ( $code ) = /$rxp/g) {
> if ( my ($code) =~ /$rxp/g ) ... surely? ie, s/=/=~/

That's not a substution, it's assigning the result of the pattern match
to $code.  /$rxp/g is matching against $_ not against $code.

andrew
-- 
Gemini: (May 21 - June 21)
Yet another great moment in American oration will be ruined by your
constant, vicious heckling of Mr. Sandler.


pgp0.pgp
Description: PGP signature

Re: regrouping lines of STDIN

[Randal L. Schwartz]

> "Luis" == Luis Campos de Carvalho <[EMAIL PROTECTED]> writes:

Luis> # I think you should rewrite this:
Luis> # > push @{ $seen{$code} } , $_;

Luis> # Like this:
Luis> if( exists $seen{$code} ){
Luis>   # I already used this array ref...
Luis>   push @{ $seen{$code} } , $_;
Luis> }else{
Luis>   # First time for this array ref...
Luis>   $seen{$code} = [ $_ ];
Luis> }
Luis>   }

No, wrong, absolutely *not* needed, thanks to autovivification.

See google "site:stonehenge.com autovivification" for further info.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: regrouping lines of STDIN -> hashtable algorithm?

[Randal L. Schwartz]

> "TSchutzerWeissmann" == TSchutzerWeissmann  <[EMAIL PROTECTED]> writes:

TSchutzerWeissmann> Hi Luis,
TSchutzerWeissmann> ...
>> Looks like a hashtable algorithm... just curious. =-]
TSchutzerWeissmann> don't know what one of those is...
TSchutzerWeissmann> ...
>> # First time for this array ref...
>> $seen{$code} = [ $_ ];

TSchutzerWeissmann> yup, [ ] was what I was looking for.

But not needed.  See my other post.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: regrouping lines of STDIN -> hashtable algorithm?

[Roger Burton West]

On Fri, Mar 07, 2003 at 01:56:50PM -, [EMAIL PROTECTED] wrote:
>But I think I can do this on the command-line with sort, somehow, all I want
>to do is sort on the 24th to 26th character of every line, instead of the
>whole thing.

sort +.23 -25

(character numbering starts at 0)

Roger

RE: regrouping lines of STDIN

[TSchutzerWeissmann]

Title: RE: regrouping lines of STDIN





> Dunno, it displays as 3 characters on my screen.  Maybe "mbm" 
> is a funny
> foreign multi-byte character that's sometimes difficult for 
> others to get
> to grips with.
> 
> 
> the hatter
> 
> 
yes, more sinned against than sinning, typo-wise,Wise,Wize,Weaz,usw

Re: regrouping lines of STDIN

[Joel Bernstein]

On Fri, Mar 07, 2003 at 01:47:36PM +, the hatter wrote:
> On Fri, 7 Mar 2003, Lusercop wrote:
> 
> > On Fri, Mar 07, 2003 at 01:25:29PM +, Joel Bernstein wrote:
> > > Ahh, so that's what he meant. Yeah.  what mbm said 
> >  ^^^
> > who's this "mbm" character?
> 
> Dunno, it displays as 3 characters on my screen.  Maybe "mbm" is a funny
> foreign multi-byte character that's sometimes difficult for others to get
> to grips with.
> 
yeah, that must be it. it's a unicode character which likes buffy.

> 
> the hatter
/joel

Re: regrouping lines of STDIN

[the hatter]

On Fri, 7 Mar 2003, Lusercop wrote:

> On Fri, Mar 07, 2003 at 01:25:29PM +, Joel Bernstein wrote:
> > Ahh, so that's what he meant. Yeah.  what mbm said 
>  ^^^
> who's this "mbm" character?

Dunno, it displays as 3 characters on my screen.  Maybe "mbm" is a funny
foreign multi-byte character that's sometimes difficult for others to get
to grips with.


the hatter

RE: regrouping lines of STDIN -> hashtable algorithm?

[TSchutzerWeissmann]

Title: RE: regrouping lines of STDIN -> hashtable algorithm?





Hi Luis,
...
>   Looks like a hashtable algorithm... just curious. =-]
don't know what one of those is...
...
>   # First time for this array ref...
>   $seen{$code} = [ $_ ];


yup, [ ] was what I was looking for.


But I think I can do this on the command-line with sort, somehow, all I want to do is sort on the 24th to 26th character of every line, instead of the whole thing.

Tom SW

RE: regrouping lines of STDIN

[TSchutzerWeissmann]

Title: RE: regrouping lines of STDIN





Lusercop points out
> >     for (%seen) {
>  ^ "values %seen" is more likely what you want here.


Of course! I was far too caught up with making the array ref in the first place (well, it's exciting the first few times). 

Thank you. Don't understand what he Joel meant, but one thing at a time.


Tom SW

Re: regrouping lines of STDIN

[Luis Campos de Carvalho]

- Original Message -
From: <[EMAIL PROTECTED]>
Sent: Friday, March 07, 2003 10:03 AM


> Hello London.pm
>
> first let me apologise, [...] an HTML version [...]

  Don't worry about this.
   Can anybody please send a
no-more-than-twenty-chars-HTML-filtering-perl-script to Mr. Schutzer?


> This is intended to re-sort STDIN according to a regexp:

  Looks like a hashtable algorithm... just curious. =-]

> my $rxp  = $ARGV[0];
> my %seen;
>
> print $rxp;
>
> while () {
> if (my ( $code ) = /$rxp/g) {

# I think you should rewrite this:
# > push @{ $seen{$code} } , $_;

# Like this:
if( exists $seen{$code} ){
  # I already used this array ref...
  push @{ $seen{$code} } , $_;
}else{
  # First time for this array ref...
  $seen{$code} = [ $_ ];
}
  }
> }
>
> for (%seen) {
> # could maybe sort these by the key
> for (@$_) {
> print;
>  }
> }
>
> It won't work with strict because I
> get "Can't use string ("AA") as an ARRAY
> ref while "strict refs" in use."
> How do I use a proper array ref? Any other
> comments very welcome...

  This is what I would do in your place.
  Hope that helps.

  Regards.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Luis Campos de Carvalho
  Computer Science Student
  OCP DBA Oracle & Unix Sys Admin
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: regrouping lines of STDIN

[Lusercop]

On Fri, Mar 07, 2003 at 01:25:29PM +, Joel Bernstein wrote:
> Ahh, so that's what he meant. Yeah.  what mbm said 
 ^^^
who's this "mbm" character?

:-)

-- 
Lusercop.net - LARTing Lusers everywhere since 2002

Re: regrouping lines of STDIN

[Joel Bernstein]

On Fri, Mar 07, 2003 at 01:20:42PM +, Lusercop wrote:
> On Fri, Mar 07, 2003 at 01:03:33PM -, [EMAIL PROTECTED] wrote:
> > for (%seen) {
>  ^ "values %seen" is more likely what you want here.
> > 
> > It won't work with strict because I get "Can't use string ("AA") as an ARRAY
> > ref while "strict refs" in use." How do I use a proper array ref? Any other
> > comments very welcome...
> 
> It is a proper arrayref, if you only get the values. As it is, you're
> flattening the associative array into a hash, so you're getting the keys
> as well, which are just text.

Ahh, so that's what he meant. Yeah.  what mbm said 
> 
/joel

Re: regrouping lines of STDIN

[Joel Bernstein]

On Fri, Mar 07, 2003 at 01:03:33PM -, [EMAIL PROTECTED] wrote:
> Hello London.pm
> 
> first let me apologise, I know this mail will be accompanied by an HTML
> version & I don't know how to prevent it. Outlook swears I'm using plain
> text but somehow it doesn't end up that way. So, sorry...
> 
> This is intended to re-sort STDIN according to a regexp:
> 
>   my $rxp  = $ARGV[0];
>   my %seen;
> 
>   print $rxp;
> 
>   while () {
>   if (my ( $code ) = /$rxp/g) {
if ( my ($code) =~ /$rxp/g ) ... surely? ie, s/=/=~/
>   push @{ $seen{$code} } , $_;
>   }
>   }
>   
>   for (%seen) {
>   # could maybe sort these by the key
>   for (@$_) {
I haven't seen the '@$_' syntax before. I'm sure the rest of the list
will shout if it's not legal, tho. Do you mean something like:
print for @_; 
?

>print;
>}
>   }
> 
> It won't work with strict because I get "Can't use string ("AA") as an ARRAY
> ref while "strict refs" in use." How do I use a proper array ref? Any other
> comments very welcome...

In my experience, this is usually due to a typo. ICBW, YMMV, IANAD.
> 
> cheers,
Sorry not to be more help.

> Tom SW
/joel

Re: regrouping lines of STDIN

[Lusercop]

On Fri, Mar 07, 2003 at 01:03:33PM -, [EMAIL PROTECTED] wrote:
>   for (%seen) {
 ^ "values %seen" is more likely what you want here.
> 
> It won't work with strict because I get "Can't use string ("AA") as an ARRAY
> ref while "strict refs" in use." How do I use a proper array ref? Any other
> comments very welcome...

It is a proper arrayref, if you only get the values. As it is, you're
flattening the associative array into a hash, so you're getting the keys
as well, which are just text.

-- 
Lusercop.net - LARTing Lusers everywhere since 2002