[28489] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 9853 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 16 14:05:50 2006

Date: Mon, 16 Oct 2006 11:05:03 -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           Mon, 16 Oct 2006     Volume: 10 Number: 9853

Today's topics:
        How to kill a perl thread raaghulists@yahoo.com
    Re: I have no problems eating cereal...after it softens <mritty@gmail.com>
    Re: I have no problems eating cereal...after it softens samiam@mytrashmail.com
    Re: LWP and Unicode <tzz@lifelogs.com>
    Re: LWP and Unicode <tzz@lifelogs.com>
        writing directory files to different output depending o <mark.leeds@morganstanley.com>
    Re: writing directory files to different output dependi <glex_no-spam@qwest-spam-no.invalid>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

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

Date: 16 Oct 2006 10:26:17 -0700
From: raaghulists@yahoo.com
Subject: How to kill a perl thread
Message-Id: <1161019577.416842.33940@m7g2000cwm.googlegroups.com>

Hi,

Can you please tell me how to kill a perl thread? I am trying to bound
the wait time on a call which is called as part of the thread.

Here is a snippet of the code:

use threads;
use threads::shared;

my $waitTime =5;
my $condvar : shared;
my $condlock;


sub my_exec_thread {
    my $cmd = shift;
    print ("In thread ".$cmd."\n");
    my $resultVar;
	eval {
	$resultVar = this_call_hangs_sometimes($cmd);
        cond_signal($condvar);
        print "Thread done\n";
	};
}

# Returns result
sub my_true_exec {
    my $cmd = shift;

    # init cond var
    lock($condvar);
    my $ret ;
    my $thr = threads->new(\&my_exec_thread, $cmd);
    if (!cond_timedwait($condvar, time()+$waitTime)) {
        print "Timed out\n";
        my $tid = $thr->tid;
###### Want to kill the thread here because the call did not return in
time
    } else {
        print "Thread completed \n";
        $ret = $thr->join;
    };
    if (defined $ret ) {
        print "Thread returned : $ret\n";
    }
}



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

Date: 16 Oct 2006 08:13:19 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: I have no problems eating cereal...after it softens. Why is replacing a simple string so hard then?
Message-Id: <1161011599.435267.187090@b28g2000cwb.googlegroups.com>

sam...@mytrashmail.com wrote:
> comments inline like this jjjjjjjjjjjjjjjjjjjj:

There's really no need for that marker.  That's what the > things are
for at the beginning of each quoted line.

> Paul Lalli wrote:
> > samiam@mytrashmail.com wrote:

> > If you're using those pieces of code, you must not be using warnings.
> > Please start doing so.  They will catch 90% of the errors you're
> > making.  In particular, they will tell you you should be quoting your
> > strings, not using barewords.  Additionally, please make sure you use
> > strict, which will force you to declare your variables.
>
> So many examples, most of them, don't seem to declare their variables,
> even in the perldocs.  what benefit is there...aren't they
> auto-declared when a value is assigned to them?  I know in vbscript one
> must declare or dimension...but I thought Perl was free from that
> contraint?  Again...so many examples don't seem to??

The examples in the docs are just that - examples.  They are intended
for brevity, not thoroughness.  As for the value of declaring your
variables, do you really trust yourself to NEVER typo a variable name?
Ever?  Why would you want to run the risk of introducing an absurdly
hard to find bug, just to avoid typing the two characters 'my' in front
of your variable names?   You understand that without strict, this
code:
$var1 = "Hello World\n";
#900 lines of code later....
print "I said: $varl\n";

will not give any errors at all?  Instead, it will merrily print out "I
said: " followed by a newline, forcing you to try to figure out where
in the 900 previous lines of code you accidentally changed $var1 to an
empty string (never realizing that you accidentally typed a lowercase L
instead of a number one).

Additionally, declaring your variables explicitly allows you to declare
them in the shortest scope possible, meaning that your variables are
only visible in the block in which they are declared.  This has many
benefits:  the memory they use is returned to Perl when they go out of
scope; you have far less code to look through to find where something
went wrong with your variable; external modules that you use can't
accidentally change your variables.

> > > Eventually I want to try:
> > >
> > > $orgtext = /<form[.*]?*\/form>/;  # this one right here
> >
> > Once again, that's assigning $orgtext to be the result of matching $_
> > to that pattern.  And once again, your pattern isn't what you think it
> > is.  See above.
>
> jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
> Oops..you lost me again in that I thought an tacit comparison was
> always made to $_ in the absence of an explicit =~ comparison.

Yes, exactly.

> But
> that line above seems to be the most basic assignment statement like
> I've seen in myriad examples, albeit with a fault [.*] bracket bit
> needing to be corrected.

No.  You're still not understanding.  Without a =~ operator, the bare
/match/ syntax ALWAYS makes a comparison to $_.  You then assign the
results of that pattern match to another variable.  You're using a
shortcut without realizing it.  Expanding that line for completeness
would be:
$origtext = ( $_ =~ m/<form[.*]?*\/form>/);

> In the same way I could assign a string to $orgtext, can't I assign a
> regex to it for comparison to another variable or string later in the
> script?

Yes you can, but that is not what your syntax above does.  If you want
to assign a regular expression to a variable, you have to use the qr//
operator, not the m// operator (which is what empty slashes implicitly
are):

my $origtext = qr/<form[.*]?*\/form>/;

> > > $newtext = block;
> > >
> > > But I can't get past the staring blocks. I know this code works in
> > > general, but my modifications seem to break it.
> >
> > No, the code really doesn't work in general.  The code you claimed
> > worked was assigning two strings (albeit in their bareword versions) to
> > a variable.  Then you suddenly stopped doing that and started assigning
> > the result of a pattern match to that variable, using the //
> > delimiters.
>
> jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
> yes...I see your point and also possibly validation of assigning the
> result of a pattern match to a variable?  Or is the distinction "result
> of a pattern match" vs assigning the regex pattern itself to a
> variable?

Yes.  A pattern match is this:
$x =~ /match/;
That is, look for 'match' inside $x.  That expression *returns* a
value.  If 'match' was found in $x, the expression returns 1.  If it
was not, it returns the empty string.  When you do:
$result = ($x =~ mmatch/);
you are assigning $result to be either 1 or the empty string.
Likewise, if you do:
$origtext = ($_ =~ m/<form>.*<\/orm>/);
you are assigning $orig text to be either 1 or the empty string,
depending on whether or not the pattern was found in $_.  And as
already noted, the above can be reduced through some shortcuts to:
$origtext = /<form>.*<\/form>/;

To assign the regexp pattern itself, you have to use the qr// syntax,
not the m// syntax.

> But yes...point taken. Read up or clam up. Understood. I have quite a
> library of Perl books, but all the O'Reilley books are these talkative
> friendly Alice in wonderland meets it's a small world rambles.  I am
> used to Linux book where a rule is stated tersely, an example given -
> DONE!!!    The perldocs are this way and are beloved by me.  If I had 2
> lifetimes...sure....teach me via anecdotal valley girl talk.  But I
> have so little time...is there a book that just gives a brief
> explanation of code snippets, a few examples of each, and we're off?
> Kind of like the orignal Bjorn C books.

I don't know what books you have, so it's difficult to recommend
alternatives.  Learning Perl is probably not what you want, as that's a
tutorial.  Programming Perl is the canonical reference book.  The Perl
Cookbook is a companion to Programming Perl, in that it offers a
multitude of "here's how you do <foo>" recipes.

> > > Any suggestions as to:
> > >
> > > 1.) Is my basic model okay, slurping the whole file into a variable? or
> > > 2.) Should I use a while <> structure?
> >
> > In general, you don't want to slurp unless you actually need to. In
> > this case, however, you do need to, because your pattern spans more
> > than one line of the file.  So no, you cannot use the while() loop
> > approach in your case.
>
> jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
> why can't while span lines?  can't it be told to process until /n or
> something?

Assumign you meant \n, that's exatcly what it does.  Except it's not
while, it's the readline operator, <>.  That reads until the first
newline that it finds, and then returns the current string.  You then
operate on that string.  Then it reads the next line.  So let's say
your file is:
My form: <form><input type ="text" name="foo">
<input type="submit"></form>

And you process like so:
while (my $line = <$fh>) {
  if ($line =~ /<form>.*<\/form>/) { do_something() }
}

The first time through the while loop, $line contains: 'My form:
<form><input type ="text" name="foo">';  Obviously, that line does not
match the pattern, so do_something() does not happen.  Then the second
time through the while loop, $line contains: '<input
type="submit"></form>'.  Clearly, that line doesn't match the pattern
either.  So do_something() does not happen.

You need to have your entire file in one big string, so that you can
pattern-match against the entire thing at once.  You can't look for a
pattern that spans multiple lines by looking only in one line at a
time.

> I know there are all sorts of catchall whitespace /t /n /r
> characters to account for this?  Again...something in my reading...but
> it's all a blur...walls closing in....usb drive OVERHEATING!!!!

Yes, you can change the $/ variable to make Perl read until some other
character instead of the newline.  That's what you did.  You changed it
to the undefined value, which forces a single <> operation to read the
entire file into one gigantic string.  That's exactly what you need to
do.  But if you have only one string, which contains the entire file,
it makes no sense of any kind to have a while loop around it.  The loop
would only execute once.



> > > And even when I do get the simple Whey replaced with Popcorn - it only
> > > does the first instance, basically, I am guessing, because there is no
> > > iterative code in this script.
> >
> > STOP GUESSING.  READ.  LEARN.  Read the documentation I pointed you to
> > above to see how to make a s/// operation replace all instances of a
> > pattern.  Again, it's trivial, but you are not going to learn how to do
> > it by just guessing and typing random characters.
>
> jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
> Yes...I am guessing a bit, but truly...honestly...based on lots of
> reading and scouring examples. My code was VERY CLOSE to working wasn't
> it? Wasn't it just a minor detail or two wrong?

No, you had severe syntax and logic errors.  You have syntax errors in
assigning to variables.  You have regexp syntax errors in looking for
the correct pattern.  You have a complete logic error in trying to look
for one line-spanning pattern in a single line.  You have a regexp bug
in wanting to find all instances, but not telling the regexp to look
for all instances.   And those are just the ones I remember without
reviewing this entire thread.


> > > And the only iterative examples I've
> > > seen are not with a whole file in one "intext" variable, but always
> > > with a while <> structure.
> >
> > Massive red herring.  Examples using while(<>) would have the same
> > problem if the pattern appeard twice on the same line.  Only the first
> > on each line would be replaced.
>
> jjjjjjjjjjjjjjjjj: Now this seems true, but entirely addressable? Isn't
> there a way to match 1st and 2nd and x occurances per line or spanning
> lines?

You're asking two distinct questions here.  The first answer is "Yes,
read perldoc perlretut to find out how to find all occurrences".  The
second answer is "Yes, by changing $/ as you already did.".  The two
answers have nothing to do with each other because the two questions
have nothing to do with each other.

$x = "This # string # has # many # signs\n";
$y = "So # does # this \n # one, \n # plus \n # newlines\n";
$x = ~ s/#/&/;
$y = ~ s/#/&/;

The above code would only replace the FIRST instance of # with & in
each of the two strings.  The fact that $y contains multiple lines is
100% irrelevant.  

Paul Lalli



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

Date: 16 Oct 2006 10:38:27 -0700
From: samiam@mytrashmail.com
Subject: Re: I have no problems eating cereal...after it softens. Why is replacing a simple string so hard then?
Message-Id: <1161020307.402373.81570@m7g2000cwm.googlegroups.com>

Aren't my comments much easier to locate if identified with a new
string?

inline comments found near 888888888888

Paul Lalli wrote:
> sam...@mytrashmail.com wrote:
> > comments inline like this jjjjjjjjjjjjjjjjjjjj:
>
> There's really no need for that marker.  That's what the > things are
> for at the beginning of each quoted line.
>
> > Paul Lalli wrote:
> > > samiam@mytrashmail.com wrote:
>
> > > If you're using those pieces of code, you must not be using warnings.
> > > Please start doing so.  They will catch 90% of the errors you're
> > > making.  In particular, they will tell you you should be quoting your
> > > strings, not using barewords.  Additionally, please make sure you use
> > > strict, which will force you to declare your variables.
> >
> > So many examples, most of them, don't seem to declare their variables,
> > even in the perldocs.  what benefit is there...aren't they
> > auto-declared when a value is assigned to them?  I know in vbscript one
> > must declare or dimension...but I thought Perl was free from that
> > contraint?  Again...so many examples don't seem to??
>
> The examples in the docs are just that - examples.  They are intended
> for brevity, not thoroughness.  As for the value of declaring your
> variables, do you really trust yourself to NEVER typo a variable name?
> Ever?  Why would you want to run the risk of introducing an absurdly
> hard to find bug, just to avoid typing the two characters 'my' in front
> of your variable names?   You understand that without strict, this
> code:
> $var1 = "Hello World\n";
> #900 lines of code later....
> print "I said: $varl\n";
>
> will not give any errors at all?  Instead, it will merrily print out "I
> said: " followed by a newline, forcing you to try to figure out where
> in the 900 previous lines of code you accidentally changed $var1 to an
> empty string (never realizing that you accidentally typed a lowercase L
> instead of a number one).
>
> Additionally, declaring your variables explicitly allows you to declare
> them in the shortest scope possible, meaning that your variables are
> only visible in the block in which they are declared.  This has many
> benefits:  the memory they use is returned to Perl when they go out of
> scope; you have far less code to look through to find where something
> went wrong with your variable; external modules that you use can't
> accidentally change your variables.
>
> > > > Eventually I want to try:
> > > >
> > > > $orgtext = /<form[.*]?*\/form>/;  # this one right here
> > >
> > > Once again, that's assigning $orgtext to be the result of matching $_
> > > to that pattern.  And once again, your pattern isn't what you think it
> > > is.  See above.
> >
> > jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
> > Oops..you lost me again in that I thought an tacit comparison was
> > always made to $_ in the absence of an explicit =~ comparison.
>
> Yes, exactly.
>
> > But
> > that line above seems to be the most basic assignment statement like
> > I've seen in myriad examples, albeit with a fault [.*] bracket bit
> > needing to be corrected.
>
> No.  You're still not understanding.  Without a =~ operator, the bare
> /match/ syntax ALWAYS makes a comparison to $_.  You then assign the
> results of that pattern match to another variable.  You're using a
> shortcut without realizing it.  Expanding that line for completeness
> would be:
> $origtext = ( $_ =~ m/<form[.*]?*\/form>/);


888888888888888888
Oh...I was just thinking that if I do an assign like:

$origtxt= '/foo(.*.bar/'
then I could do a match =~   preceding or subsequent in the code
but you are saying the match occurs the exact time the assign line is
processed: there is not consider previous matches in code above or
subsequent matches in the code below, because if one is not explicit in
this assign statement, a match will be made against $_

So, I have learned that one must identify and consider what $_ is
holding and realize it is being compared with any /regex/ at the exact
time the /regex/ is evaluated. right?







>
> > In the same way I could assign a string to $orgtext, can't I assign a
> > regex to it for comparison to another variable or string later in the
> > script?
>
> Yes you can, but that is not what your syntax above does.  If you want
> to assign a regular expression to a variable, you have to use the qr//
> operator, not the m// operator (which is what empty slashes implicitly
> are):

8888888888

ooooohhhhhh....anytime one uses /foobar/  an m/foobar/ is always
implied.  Hmmm, there is such inconsistent use, I inferred that each
was different, especially since I read that the m/foo/ means one can
use alternate delimiters.  But again, I misunderstood what I read?
Perhaps the m/foo/ or s/foo/ have to be explicit to use alternate
delimiters such as m!foo!  or s!foo!  ?


8888888888
you wrote:
 If you want
> to assign a regular expression to a variable, you have to use the qr//

Now that's something I have not come across in any of my tutorials or
perldocs.  Thanks Paul! It would have taken me a much longer time to
find this bit...although...I bet it doesn't work the way I think it
does :)


>
> my $origtext = qr/<form[.*]?*\/form>/;
>
> > > > $newtext = block;
> > > >
> > > > But I can't get past the staring blocks. I know this code works in
> > > > general, but my modifications seem to break it.
> > >
> > > No, the code really doesn't work in general.  The code you claimed
> > > worked was assigning two strings (albeit in their bareword versions) to
> > > a variable.  Then you suddenly stopped doing that and started assigning
> > > the result of a pattern match to that variable, using the //
> > > delimiters.
> >
> > jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
> > yes...I see your point and also possibly validation of assigning the
> > result of a pattern match to a variable?  Or is the distinction "result
> > of a pattern match" vs assigning the regex pattern itself to a
> > variable?
>
> Yes.  A pattern match is this:
> $x =~ /match/;
> That is, look for 'match' inside $x.  That expression *returns* a
> value.  If 'match' was found in $x, the expression returns 1.  If it
> was not, it returns the empty string.  When you do:
> $result = ($x =~ mmatch/);
> you are assigning $result to be either 1 or the empty string.

888888888888

I see. I am going to print this out and keep it with my Perldocs. Very
insiteful Paul - again...thank you.






> Likewise, if you do:
> $origtext = ($_ =~ m/<form>.*<\/orm>/);
> you are assigning $orig text to be either 1 or the empty string,
> depending on whether or not the pattern was found in $_.  And as
> already noted, the above can be reduced through some shortcuts to:
> $origtext = /<form>.*<\/form>/;


8888888888888888888888
$origtext = ($_ =~ m/<form>.*<\/orm>/);   THIS equals
$origtext = /<form>.*<\/form>/;      	THIS

Very explanatory.

Oh...it just occurred to me that you are using a fancy newreader like
Agent, which parses the >>>> maybe? And that's why my otherwise
conspicuously helpful unique idents (8888) have no value for you?

>
> To assign the regexp pattern itself, you have to use the qr// syntax,
> not the m// syntax.

8888888888
got it!


>
> > But yes...point taken. Read up or clam up. Understood. I have quite a
> > library of Perl books, but all the O'Reilley books are these talkative
> > friendly Alice in wonderland meets it's a small world rambles.  I am
> > used to Linux book where a rule is stated tersely, an example given -
> > DONE!!!    The perldocs are this way and are beloved by me.  If I had 2
> > lifetimes...sure....teach me via anecdotal valley girl talk.  But I
> > have so little time...is there a book that just gives a brief
> > explanation of code snippets, a few examples of each, and we're off?
> > Kind of like the orignal Bjorn C books.
>
> I don't know what books you have, so it's difficult to recommend
> alternatives.  Learning Perl is probably not what you want, as that's a
> tutorial.  Programming Perl is the canonical reference book.  The Perl
> Cookbook is a companion to Programming Perl, in that it offers a
> multitude of "here's how you do <foo>" recipes.

888888888888888
A 20 year Perl veteran at work recommended I read these Perl books in
this order:

1.) Beginning Perl
2.) Perl Best Practices

Then use Programming Perl and Perl Cookbook as needed.
I thought I might also make Perl, a Problem Solution approach a 1.5 on
the list?



>
> > > > Any suggestions as to:
> > > >
> > > > 1.) Is my basic model okay, slurping the whole file into a variable? or
> > > > 2.) Should I use a while <> structure?
> > >
> > > In general, you don't want to slurp unless you actually need to. In
> > > this case, however, you do need to, because your pattern spans more
> > > than one line of the file.  So no, you cannot use the while() loop
> > > approach in your case.
> >
> > jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
> > why can't while span lines?  can't it be told to process until /n or
> > something?
>
> Assumign you meant \n, that's exatcly what it does.  Except it's not
> while, it's the readline operator, <>.  That reads until the first
> newline that it finds, and then returns the current string.  You then
> operate on that string.  Then it reads the next line.  So let's say
> your file is:
> My form: <form><input type ="text" name="foo">
> <input type="submit"></form>
>
> And you process like so:
> while (my $line = <$fh>) {
>   if ($line =~ /<form>.*<\/form>/) { do_something() }
> }
>
> The first time through the while loop, $line contains: 'My form:
> <form><input type ="text" name="foo">';  Obviously, that line does not
> match the pattern, so do_something() does not happen.  Then the second
> time through the while loop, $line contains: '<input
> type="submit"></form>'.  Clearly, that line doesn't match the pattern
> either.  So do_something() does not happen.
>
> You need to have your entire file in one big string, so that you can
> pattern-match against the entire thing at once.  You can't look for a
> pattern that spans multiple lines by looking only in one line at a
> time.

88888888888888
I had a long talk with Mr. Twenty Year Perl Veteran (TYPV) and he said
that everyone goes through the stage of "Why can't regex be used to
process multi-line html files?"

And he said I just needed to go through it, take my lumps, and
eventually learn that cpan and modules are my best friends.  He said,
ALWAYS use a module to parse any html and any multiple line data.  He
said he scours CPAN and uses modules for most everything.

I told him I tried using HMLT parser, since deprecated but now a
wrapper for the Treebuilder module.  I mentioned the documents were a
bit cryptic if not sparse.

He agreed and said that's just the way it was...but I would have to
learn how to use the modules in spite of this.  He made a big
impression enough for me to think:

Just don't:
1.) Use regex for anything more than a simple replace
2.) Never attempt to parse html without a module
3.) Never try to parse multi-line code without a module.

But modules are going to be the steepest learning curve I think. I
think one has to pretty much know Perl very well to even begin to
understand the Module docs?



>
> > I know there are all sorts of catchall whitespace /t /n /r
> > characters to account for this?  Again...something in my reading...but
> > it's all a blur...walls closing in....usb drive OVERHEATING!!!!
>
> Yes, you can change the $/ variable to make Perl read until some other
> character instead of the newline.  That's what you did.  You changed it
> to the undefined value, which forces a single <> operation to read the
> entire file into one gigantic string.  That's exactly what you need to
> do.  But if you have only one string, which contains the entire file,
> it makes no sense of any kind to have a while loop around it.  The loop
> would only execute once.


88888888888888888
Yes...I see that now.



>
>
>
> > > > And even when I do get the simple Whey replaced with Popcorn - it only
> > > > does the first instance, basically, I am guessing, because there is no
> > > > iterative code in this script.
> > >
> > > STOP GUESSING.  READ.  LEARN.  Read the documentation I pointed you to
> > > above to see how to make a s/// operation replace all instances of a
> > > pattern.  Again, it's trivial, but you are not going to learn how to do
> > > it by just guessing and typing random characters.
> >
> > jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
> > Yes...I am guessing a bit, but truly...honestly...based on lots of
> > reading and scouring examples. My code was VERY CLOSE to working wasn't
> > it? Wasn't it just a minor detail or two wrong?
>
> No, you had severe syntax and logic errors.  You have syntax errors in
> assigning to variables.  You have regexp syntax errors in looking for
> the correct pattern.  You have a complete logic error in trying to look
> for one line-spanning pattern in a single line.  You have a regexp bug
> in wanting to find all instances, but not telling the regexp to look
> for all instances.   And those are just the ones I remember without
> reviewing this entire thread.



888888888888888
Yes...but my pet hogs need some slop or they starve. In time, I will
put them on a diet as my code comes up to par with the help of yourself
and other Perl guardians.


>
>
> > > > And the only iterative examples I've
> > > > seen are not with a whole file in one "intext" variable, but always
> > > > with a while <> structure.
> > >
> > > Massive red herring.  Examples using while(<>) would have the same
> > > problem if the pattern appeard twice on the same line.  Only the first
> > > on each line would be replaced.
> >
> > jjjjjjjjjjjjjjjjj: Now this seems true, but entirely addressable? Isn't
> > there a way to match 1st and 2nd and x occurances per line or spanning
> > lines?
>
> You're asking two distinct questions here.  The first answer is "Yes,
> read perldoc perlretut to find out how to find all occurrences".  The
> second answer is "Yes, by changing $/ as you already did.".  The two
> answers have nothing to do with each other because the two questions
> have nothing to do with each other.
>
> $x = "This # string # has # many # signs\n";
> $y = "So # does # this \n # one, \n # plus \n # newlines\n";
> $x = ~ s/#/&/;
> $y = ~ s/#/&/;
>
> The above code would only replace the FIRST instance of # with & in
> each of the two strings.  The fact that $y contains multiple lines is
> 100% irrelevant.
>
> Paul Lalli



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

Date: Mon, 16 Oct 2006 17:18:38 +0100
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: LWP and Unicode
Message-Id: <g6964ekutcx.fsf@lifelogs.com>

On 12 Oct 2006, jurgenex@hotmail.com wrote:

Ben Morrow wrote:
>> Transfer encodings aren't needed because Usenet articles are in
>> practice in US-ASCII, [...]
>
> Oh, really? I wonder how you write messages in lets say French, German,
> Norwegian, Greek, Russian, Chinese, Japanese, Hebrew, Arabic and most other 
> languages with US-ASCII only.

Transliterate, my boy, transliterate...

:)

Ted


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

Date: Mon, 16 Oct 2006 17:23:20 +0100
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: LWP and Unicode
Message-Id: <g691wp8ut53.fsf@lifelogs.com>

So is there a consensus that MIME with charset=utf8 and a suitable
8-bit-safe content-transfer-encoding should be acceptable in
comp.lang.perl.misc?  It's unlikely to do violent things to anyone's
news reader, and it would make it much easier to post Perl code that
uses UCS characters in source.

Ted


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

Date: 16 Oct 2006 09:24:49 -0700
From: "markpark" <mark.leeds@morganstanley.com>
Subject: writing directory files to different output depending on criteria
Message-Id: <1161015889.055665.183460@b28g2000cwb.googlegroups.com>


hi everyone : i wrote a function ( which i'm very proud of ) that reads
all the files in a directory and
and writes them to a file.

sub create_file_list {

  my ($datadir,$outfilename) = @_;

  print "data directory = $datadir \n";
  print "outfilename = $outfilename \n";

  opendir(DH, $datadir) or die "Could not open directory $datadir";
  my @filelist = readdir(DH);
  closedir(DH);

  open OUT_FILE1, "> $outfilename ";

  foreach my $filename (@filelist) {
    if ( ( $filename ne '.' ) && ( $filename ne '..' ) ) {
      print OUT_FILE1 "$filename \n";
    }
  }

}


an example of a file name would be "eurusd.FXEBSLN.20060123.txt"
and there can be many of them and they will all be the same except for
the
different dates ( each one represents a day )

what i would like to be able to do is change it a little ( maybe a lot
)
so that i write some files to one outfile and other files to another
outfile
depending on criteria : so

if ( 200601, 200602, 200603 ) was array1
and ( 200604, 200605, 200606 ) was array2

then any files with a substring in array1 would get written to file 1
and
any files with a substring in array2 would get written to file 2 and
any files that don' t have any matching substrings don't get written
anywhere.

i think i need to search each filename that i read for the correct
string using some kind
of patter matching but i'm a   novice so i'm very unsure how to do this
 ?

i would really appreciate it if someone could show me the pattern or
use some kind
of other logic to get the two final filelists correct. thanks a lot. i
really do appreciate the
generosity of everyone on this list and i'm honestly trying to do
things on my own but i'm very new to perl. i am improving though.



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

Date: Mon, 16 Oct 2006 11:59:07 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: writing directory files to different output depending on criteria
Message-Id: <4533ba03$0$10302$815e3792@news.qwest.net>

 > markpark wrote:
> hi everyone : i wrote a function ( which i'm very proud of ) that reads
                            ^^^^^^^ subroutine
> all the files in a directory and
> and writes them to a file.
> 
> sub create_file_list {
> 
>   my ($datadir,$outfilename) = @_;
> 
>   print "data directory = $datadir \n";
>   print "outfilename = $outfilename \n";
> 
>   opendir(DH, $datadir) or die "Could not open directory $datadir";

Always include the reason why opendir may fail, which will be available 
in $!.

opendir( my $dh, '<', $datadir)
       or die "Could not open directory $datadir: $!";

>   my @filelist = readdir(DH);
>   closedir(DH);
> 
>   open OUT_FILE1, "> $outfilename ";
ahhhh.. where is your check to ensure it can write $outfilename????  Be 
consistent!

open( my $out_file1, '>', $outfilename )
	or die "Couldn't write $outfilename: $!";

> 
>   foreach my $filename (@filelist) {
>     if ( ( $filename ne '.' ) && ( $filename ne '..' ) ) {
>       print OUT_FILE1 "$filename \n";
print $out_file1 $filename, "\n"; #if using the above open.
>     }
>   }

See perldoc -f readdir

For an example on a shorter way to filter out '.' and '..' using grep.

> 
> }
> 
> 
> an example of a file name would be "eurusd.FXEBSLN.20060123.txt"
> and there can be many of them and they will all be the same except for
> the
> different dates ( each one represents a day )
> 
> what i would like to be able to do is change it a little ( maybe a lot
> )
> so that i write some files to one outfile and other files to another
> outfile
> depending on criteria : so
> 
> if ( 200601, 200602, 200603 ) was array1
> and ( 200604, 200605, 200606 ) was array2
> 
> then any files with a substring in array1 would get written to file 1
> and
> any files with a substring in array2 would get written to file 2 and
> any files that don' t have any matching substrings don't get written
> anywhere.
> 
> i think i need to search each filename that i read for the correct
> string using some kind
> of patter matching but i'm a   novice so i'm very unsure how to do this
>  ?
> 
> i would really appreciate it if someone could show me the pattern or
> use some kind
> of other logic to get the two final filelists correct. thanks a lot. i
> really do appreciate the
> generosity of everyone on this list and i'm honestly trying to do
> things on my own but i'm very new to perl. i am improving though.

Start with the documentation.

perldoc perlretut

if   ( $filename =~ /20060[123]/ ) { .. do something.. }
elsif( $filename =~ /20060[456]/ ) { ... do something else... }



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

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


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