[23595] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 5802 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Nov 14 09:05:35 2003

Date: Fri, 14 Nov 2003 06:05:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Fri, 14 Nov 2003     Volume: 10 Number: 5802

Today's topics:
    Re: arrange form data in same order as on form <flavell@ph.gla.ac.uk>
    Re: arrange form data in same order as on form <REMOVEsdnCAPS@comcast.net>
    Re: arrange form data in same order as on form <REMOVEsdnCAPS@comcast.net>
    Re: Dynamic regexp <matthias_weckman@hotmail.com>
    Re: Dynamic regexp (Anno Siegel)
    Re: Is a value a decimal number or not? <tore@aursand.no>
    Re: Is a value a decimal number or not? <josef.moellers@fujitsu-siemens.com>
    Re: Is a value a decimal number or not? (Anno Siegel)
    Re: Is a value a decimal number or not? <tassilo.parseval@rwth-aachen.de>
    Re: Is a value a decimal number or not? (Anno Siegel)
    Re: JVM in perl <plau@sandiego.edu>
    Re: long running perl programs & memory untilization <ouellmi@videotron.ca>
        New to Wintel and 5.6.1.635 - control of end-of-line ch <millsrg@earthlink.net>
    Re: New to Wintel and 5.6.1.635 - control of end-of-lin <spam@hexmad.com>
    Re: newbie dealings with OS "grep -P" (Anno Siegel)
    Re: newbie dealings with OS "grep -P" <hexkid@hotpop.com>
    Re: newbie dealings with OS "grep -P" <hexkid@hotpop.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

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

Date: Fri, 14 Nov 2003 11:52:38 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: arrange form data in same order as on form
Message-Id: <Pine.LNX.4.53.0311141116250.9701@ppepc56.ph.gla.ac.uk>

On Fri, 14 Nov 2003, Ben Morrow wrote:

> Absolutely. Reading decent code is one of the best ways to learn.

Well, yes, but there's a massive difference between the elaborate code
that might be found in a well-tested and peer-reviewed module,
intended to deal well with all possible situations that it's going to
encounter in the Real World(tm), on the one hand; and a
straightforward little script to use that module, checking that all is
well but otherwise simply baling out when it recognises that it's not.

Or in clear text: CGI.pm internally appears to be contorted code, but
there's generally good reasons for what it does and how it does it;
however, it's probably not the kind of code that the average *user* of
CGI.pm should be seeking to emulate.

> You do have to be sure your source is reliable, though: there is one
> hell of a lot of very bad Perl floating around the web.

That too, for sure.  But that's a different axis of evaluation.

> > what i've since found is that the variable containing the form input
> > is in fact in the same order as the form this code keeps the
> > original order
>
> I don't think this is guaranteed,

I would ask anyone interested in the following to read all of it,
carefully, or not at all.  Half-measures are inadvisable.

Point 1.  Read
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1 , item 2.

Read also
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2

in the paragraph beginning 'A "multipart/form-data" message contains a
series of parts'.

Thus, both of the mandatory submission formats specify that the items
are required to be submitted in the same order that they appeared in
the form.

Point 2.  Client agents don't necessarily conform to the spec
(although most of them do nowadays).

Point 3.  In Perl, f you get your submitted name/value pairs from the
module as a "hash", then of course the ordering has been lost by then.

However, in every other respect, the hash is very much the "natural"
way to represent these things in Perl.

Point 4.  The whole point of defining the values by name/value pairs
is surely to make them accessible by name rather than by position?
If the designers of HTML forms had wanted to implement positional
parameters, they could have done so (in fact they already did - check
the <ISINDEX> element, now deprecated, from earlier versions of HTML).

My conclusion: although the HTML4 spec requires the name/value pairs
to be transmitted in same order they appear in the form, it seems to
me that it's utterly pointless to want to rely on all client software
actually doing that.  I've often met writers of scripts who seemed
completely obsessed with needing to process the items in the same
order as which they were present in the form, but on closer study I've
never found any justification for doing so, and as soon as the writer
agreed to drop their insistence that they "needed" this, they found
their scripts were easier to write, with no loss of functionality.

While I'm sure that someone could devise a requirement that depended
on the ordering, I can't see any advantage in doing so.

IMHO and YMMVWV.

You may very well want to re-write the form e.g with existing inputs
filled-in and waiting for further input from the user - but the right
way to do that is probably to use the same code to write the original
empty form as re-writes the partially completed form, and that code
will certainly know what is the proper ordering of the items on the
HTML form itself.  But when the boss says the items have to come in a
different order on the web page, there will be no need for a major
rewrite of the code to take that into account, if you've written code
that isn't sensitive to the ordering in the first place.

> by which I mean that it may happen
> to work for you with your browser during this phase of the moon, but
> under other circumstances it may well not.

Something like that; but by gaining the benefits of the hash
representation, one also discards any supposed benefits there might
have been in the original ordering, so - as I say - it seems to me to
be the wrong approach anyway.

> If you need to keep separate track of the different paramaters, give
> them different names. Change whatever generates them to put a number
> on the end, or something.

If you want to iterate through the name/value pairs that are present,
then just iterate through the keys of the hash.  Write the code so
that the ordering doesn't matter.  The resulting code is likely to be
simpler than trying to re-create the problem of positional parameters
all over again - would be my advice.


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

Date: Fri, 14 Nov 2003 06:20:19 -0600
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: arrange form data in same order as on form
Message-Id: <Xns94334AB80EF7Csdn.comcast@216.196.97.136>

-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1

"bbxrider" <bxtrap01@comcast.net> wrote in
news:81Xsb.144719$ao4.463347@attbi_s51: 

> thanks for all the help and opinions
>  i'm just self learning perl and found some  code at
> http://www.cgi101.com/class/

I just spent some time perusing this site.  It's not a bad site overall, 
as far as an introduction to CGI programming goes.  The way they 
introduce processing of input variables is fine -- but I wish they had 
moved immediately on to using CGI.pm, instead of saving it until chapter 
17.  That code is okay for learning, but is awful for any real work.

> actually i dont even know what cgi.pm and cgi lite are but will surely
> find out

Yes, you should.  CGI.pm is a module that comes with the Perl 
distribution.  It automates much of the dirty work behind processing CGI 
forms, plus it has some security checks to protect you from DOS attacks.

> i dont' mean to try and just steal code, but have found that seeing,
> using and understanding examples
> really accelerates my learing curve

Absolutely.  Borrowing and adapting others' code is a great way to learn.  
Just be aware of the limitations of the code you're using!  :-)

> what i've since found is that the variable containing the form input
> is in fact in the same order as the form

Most (all?) browsers do submit the variables in the same order that they 
appear on the form, but this is NOT guaranteed.  Besides, why do you need 
them to be in any particular order?  They all have names.

> this code keeps the original order
>     foreach (split(/[&;]/, $buffer)) {
>         s/\+/ /g ;
>         ($name, $value)= split('=', $_, 2) ;
>         $name=~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge ;
>         $value=~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge ;
>  print "$name = $value";
>         $buffer{$name}.= "\0" if defined($in{$name}) ;  # concatenate
> multiple vars
>         $buffer{$name}.= $value ;
>     }

Yes, this is much better.  However, be aware that CGI.pm does all of this 
for you.  Less typing, and it's already debugged for you.

> i have already set up sql query based inserts that expect the data
> fields in order and since there are 67
> on the form i want to be able to reuse that code

Well, all of your form variables are named, right?  So process them in 
name order.

> again thanks for the help, this is a great forum and would hope to
> return the help someday

You're welcome.

- -- 
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP7TImGPeouIeTNHoEQJT4QCfbqG0ESDylR8pTZDPjeaCDAh4Rf0AmgP+
1ZIw0EXmWZEP5GzNZNCgZz06
=fDlp
-----END PGP SIGNATURE-----


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

Date: Fri, 14 Nov 2003 06:26:09 -0600
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: arrange form data in same order as on form
Message-Id: <Xns94334BB508751sdn.comcast@216.196.97.136>

-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1

Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in news:bp19n3$1iabf3$1@ID-
184292.news.uni-berlin.de:

> 
> Still don't understand what it is that makes the above code "buggy".

[OP's posted code]:
> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
> @pairs = split(/&/, $buffer);
> foreach $pair (@pairs) {
>     ($name, $value) = split(/=/, $pair);
>     $value =~ tr/+/ /;
>     $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
>     $FORM{$name} = $value;

1. The read() may fail.  No check is made to see if it does.

2. This code does not handle GET requests.

3. CGI parameters may be separated by semicolons instead of ampersands.

4. If a faulty browser fails to encode "=" with a % escape, and that "=" 
is part of a form variable value, this code will drop that portion of the 
value.  I've seen browsers do this.  split() should use the limit 
parameter.

5. No limit is placed on the quantity of data read, opening the script to 
possible DOS attack.

> I'm not questioning the advantages with code reuse in general. I'm
> just (once again) reacting to the aggressive way, sometimes not to the
> point, in which some people here argue for using CGI.pm.

Surely you can't be questioning the value of CGI.pm over the above code?  
I have more respect for you than that, Gunnar!  :-)

- -- 
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP7TJ9GPeouIeTNHoEQJRbgCfXwD+RAL7yELVGwmJ53xPd4TSaNEAoPkD
xN+aqh2FBYWsF6sXTLfZD3xw
=G1nw
-----END PGP SIGNATURE-----


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

Date: Fri, 14 Nov 2003 13:13:03 +0100
From: Matthias Weckman <matthias_weckman@hotmail.com>
Subject: Re: Dynamic regexp
Message-Id: <3fb4c6cd$0$18474$e4fe514c@dreader4.news.xs4all.nl>

> wouldn't doubling the e at the end work as well? like so:
> 
>     if ($string =~ s/$rule->[0]/$rule->[1]/eei)
>                                           -----^^

argh. I guess I'll have to teach Thunderbird about tabs. :-(

I hope this comes out as intended (and indented:-):

      if ($string =~ s/$rule->[0]/$rule->[1]/eei)
                                        -----^^



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

Date: 14 Nov 2003 12:15:34 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Dynamic regexp
Message-Id: <bp2h16$gj7$1@mamenchi.zrz.TU-Berlin.DE>

Matthias Weckman  <matthias_weckman@hotmail.com> wrote in comp.lang.perl.misc:
> Eric Joanis wrote:
> 
> > Dear Winston,
> > 
> > Winston Smith  <winston_smith@linuxmail.org> wrote:
> > 
> >>I'm looking for a way to make a batch of s/// substitutions. As a code
> >>sample is worth a thousand words, let see what me code is presently :
> >>
> >>my @rules = ( ['^HELLO (.*)$', 'BONJOUR $1'], ... );
> >>foreach my $rule (@rules) {
> >>   if ($string =~ s/$rule->[0]/$rule->[1]/ei) {
> > 
> > 
> > The problem with this code is that $rule->[1] is only interpolated once
> > and thus the "$1" it contains is not itself interpolated to the
> contents of the
> > $1 variable.  To fix this, you need to get Perl to evaluation the replacement
> > string twice.  After some trial and error, I found that this works:
> > 
> >     if ($string =~ s/$rule->[0]/eval qq("$rule->[1]") /ei) {
> > 
> 
> wouldn't doubling the e at the end work as well? like so:
> 
> 	if ($string =~ s/$rule->[0]/$rule->[1]/eei)
>                                            -----^^

It works, but the Perl code /e has to execute is "BONJOUR $1", that is
"BONJOUR" is interpolated as a bareword.  That only works because the
implicit "eval" runs without strictures.  When using /e, the right hand
side should be an executable Perl expression.  Make the rule

    [ '^HELLO (.*)$', '"BONJOUR $1"']

Now the right side is an eval-able string interpolation.

Anno


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

Date: Fri, 14 Nov 2003 13:03:04 +0100
From: Tore Aursand <tore@aursand.no>
Subject: Re: Is a value a decimal number or not?
Message-Id: <pan.2003.11.14.11.45.58.645509@aursand.no>

On Fri, 14 Nov 2003 10:51:38 +0000, Anno Siegel wrote:
>> Is there a way to check if a number is a decimal number even when you
>> declare the value as a "plain number"?

> What do you consider a decimal number?

As <http://www.shodor.org/interactivate/dictionary/d.html> states:

  "A fraction where the denominator is a power of ten and is therefore
   expressed using a decimal point. For example: 0.37 is the decimal
   equivalent of 37/100."

>> sub is_decimal {
>>     my $nr = shift;
>>     return ( defined $nr && $nr =~ m,^[+-]?(\d+)?\.\d+$, ) ? 1 : 0;
>> }

> Why the "?:" operator?  It doesn't change the boolean result.

Hmm.  Don't know; I didn't write the code.  Personally, I would've skipped
it;

  sub is_decimal {
      my $nr = shift;
      return ( defined $nr && $nr =~ /.../ );
  }

That's not the point, though.

> It seems you require a period in a string for it to count as a "decimal
> number".  That is not the usual definition, though I know one
> participant on clpm who would agree with you.

Only _one_ who agrees with me!? :-)  Yes, I would like to think of a
decimal number as something express with a decimal point (period), as
mentioned in the dictionary definition.

> In the usual definition a string is a decimal number if it consists of
> an optional sign, one or more digits and at most one period among the
> digits.

Optional sign, optional digits, at most one period and one or more digits.

Anyway;  This topic was really a digression.  I just got curious if it was
possible to re-evaluate (or whatever) '$i = 5.00' and state that it _is_ a
decimal number (or whatever you prefer to call it).


-- 
Tore Aursand <tore@aursand.no>


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

Date: Fri, 14 Nov 2003 13:11:35 +0100
From: Josef =?iso-8859-1?Q?M=F6llers?= <josef.moellers@fujitsu-siemens.com>
Subject: Re: Is a value a decimal number or not?
Message-Id: <3FB4C677.E55E8DAF@fujitsu-siemens.com>

Tore Aursand wrote:

> Only _one_ who agrees with me!? :-)  Yes, I would like to think of a
> decimal number as something express with a decimal point (period), as
> mentioned in the dictionary definition.

A "decimal number" is a representation of a number with a base 10 (in
contrast to hexadecimal, octal and binary numbers).

A number with a decimal point, however, is said to "have decimals", it
is a "number with decimals", i.e. there are digits after the decimal
point.

That's the difference, but then ... I'm not a native english speaker.

Josef
-- =

Josef M=F6llers (Pinguinpfleger bei FSC)
	If failure had no penalty success would not be a prize
						-- T.  Pratchett


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

Date: 14 Nov 2003 12:18:51 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Is a value a decimal number or not?
Message-Id: <bp2h7b$gj7$2@mamenchi.zrz.TU-Berlin.DE>

Tore Aursand  <tore@aursand.no> wrote in comp.lang.perl.misc:
> On Fri, 14 Nov 2003 10:51:38 +0000, Anno Siegel wrote:
> >> Is there a way to check if a number is a decimal number even when you
> >> declare the value as a "plain number"?

> Anyway;  This topic was really a digression.  I just got curious if it was
> possible to re-evaluate (or whatever) '$i = 5.00' and state that it _is_ a
> decimal number (or whatever you prefer to call it).

No.  "$x = 5.00" and "$x = 5" are indistinguishable after the fact.
That is *why* it makes little sense to exclude whole numbers from the
set of decimal numbers.

Anno


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

Date: 14 Nov 2003 12:31:49 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: Is a value a decimal number or not?
Message-Id: <bp2hvl$64q$1@nets3.rz.RWTH-Aachen.DE>

Also sprach Anno Siegel:

> Tore Aursand  <tore@aursand.no> wrote in comp.lang.perl.misc:
>> On Fri, 14 Nov 2003 10:51:38 +0000, Anno Siegel wrote:
>> >> Is there a way to check if a number is a decimal number even when you
>> >> declare the value as a "plain number"?
> 
>> Anyway;  This topic was really a digression.  I just got curious if it was
>> possible to re-evaluate (or whatever) '$i = 5.00' and state that it _is_ a
>> decimal number (or whatever you prefer to call it).
> 
> No.  "$x = 5.00" and "$x = 5" are indistinguishable after the fact.
> That is *why* it makes little sense to exclude whole numbers from the
> set of decimal numbers.

In fact, no, they shouldn't be indistinguishable:

ethan@ethan:~$ perl -MDevel::Peek
Dump(5);
Dump(5.0);
__END__
SV = IV(0x812b058) at 0x811e408
  REFCNT = 1
  FLAGS = (IOK,READONLY,pIOK)
  IV = 5
SV = NV(0x812dfb0) at 0x8128ab0
  REFCNT = 1
  FLAGS = (NOK,READONLY,pNOK)
  NV = 5

Stress is on "shouldn't". I am not sure whether there is a way to call
the various macros (SvNOK, SvIOK etc.) from pure-Perl. Maybe there's
some module around that exposes them. At least it isn't in the latest
Scalar::Util where they'd probably belong.

Tassilo
-- 
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval


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

Date: 14 Nov 2003 13:21:18 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Is a value a decimal number or not?
Message-Id: <bp2kse$ivp$2@mamenchi.zrz.TU-Berlin.DE>

Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote in comp.lang.perl.misc:
> Also sprach Anno Siegel:
> 
> > Tore Aursand  <tore@aursand.no> wrote in comp.lang.perl.misc:
> >> On Fri, 14 Nov 2003 10:51:38 +0000, Anno Siegel wrote:
> >> >> Is there a way to check if a number is a decimal number even when you
> >> >> declare the value as a "plain number"?
> > 
> >> Anyway;  This topic was really a digression.  I just got curious if it was
> >> possible to re-evaluate (or whatever) '$i = 5.00' and state that it _is_ a
> >> decimal number (or whatever you prefer to call it).
> > 
> > No.  "$x = 5.00" and "$x = 5" are indistinguishable after the fact.
> > That is *why* it makes little sense to exclude whole numbers from the
> > set of decimal numbers.
> 
> In fact, no, they shouldn't be indistinguishable:
> 
> ethan@ethan:~$ perl -MDevel::Peek

No fair, peeking!

> Dump(5);
> Dump(5.0);
> __END__
> SV = IV(0x812b058) at 0x811e408
>   REFCNT = 1
>   FLAGS = (IOK,READONLY,pIOK)
>   IV = 5
> SV = NV(0x812dfb0) at 0x8128ab0
>   REFCNT = 1
>   FLAGS = (NOK,READONLY,pNOK)
>   NV = 5
> 
> Stress is on "shouldn't". I am not sure whether there is a way to call
> the various macros (SvNOK, SvIOK etc.) from pure-Perl. Maybe there's
> some module around that exposes them. At least it isn't in the latest
> Scalar::Util where they'd probably belong.

I don't think the difference between IOK and NOK is anywhere visible
in pure Perl.  The problem is that, since Perl lacks a formal specification,
nobody knows what "pure Perl" is.

In any case, the difference is in the internal representation of the
numbers -- a subject I had hoped to keep out of this discussion of
"decimals".  Conceptually, there is no difference between 1 and 1.0.

Anno

Anno


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

Date: Fri, 14 Nov 2003 11:12:15 GMT
From: "Philip Lau" <plau@sandiego.edu>
Subject: Re: JVM in perl
Message-Id: <jM2tb.60110$Ec1.3602826@bgtnsc05-news.ops.worldnet.att.net>

On 11-Nov-2003, "Mc Kiernan, Daniel Kian"
<Mc-Kiernan@bogus-subdomain.worldnet.att.net> wrote:

> I'm planning an implementation of the JVM in perl. (I can begin work in
> early 2004.) Has anyone else been doing or planning something along these
> lines?

Great!


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

Date: Fri, 14 Nov 2003 08:09:42 -0500
From: "Michele Ouellet" <ouellmi@videotron.ca>
Subject: Re: long running perl programs & memory untilization
Message-Id: <qu4tb.9323$cm6.63025@wagner.videotron.net>

> It does setup stuff (a lot of that), and then goes into a loop. In this
> loop it does a system call to v4lctl to capture an image, then goes bacl
to
> sleep and waits. Curently it's one image every 10 seconds. Running since
> moday, it had grown to a size of 1/2 a gig :-(
>

Hi Everyone,

I am no Perl guru and not at all familiar with memory management under Linux
or Unix. But I have experience with images.

Have you considered that the problem may be memory fragmentation rather than
a memory leak? Images typically require large CONTIGUOUS blocks of memory
so, if the memory manager des not occasional compact free memory, that kind
of situation can easily occur. I have seen this with older versions of
Windows, such as Windows 95 and Windows 98.

If your images are all of the same size, fragmentation is less likely, but
otherwise...

If fragmentation is impossible, I will be glad to know this. Otherwise, you
might have to write your own memory manager for your images.

My two bits,

Michèle Ouellet
Stelvio Inc.






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

Date: Fri, 14 Nov 2003 08:42:18 -0500
From: "R.G. Mills" <millsrg@earthlink.net>
Subject: New to Wintel and 5.6.1.635 - control of end-of-line chars?
Message-Id: <CrCdnWTBN-8gRimiU-KYkQ@giganews.com>

Under WinXP-Pro, "print" is helping me by outputting hex '0D0A' when I try
to create a file containing only '0A' at that spot.

How do I discontinue, or work around, this unwelcome assistance?  Simple, I
am sure, but it hasn't dawned on me yet.

Thanks.




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

Date: Fri, 14 Nov 2003 13:54:10 +0000
From: Sean Doherty <spam@hexmad.com>
Subject: Re: New to Wintel and 5.6.1.635 - control of end-of-line chars?
Message-Id: <4gn9rv81gfiiefdidrico5d8plark2sjn3@4ax.com>

On Fri, 14 Nov 2003 08:42:18 -0500, "R.G. Mills"
<millsrg@earthlink.net> wrote:

>Under WinXP-Pro, "print" is helping me by outputting hex '0D0A' when I try
>to create a file containing only '0A' at that spot.
>
>How do I discontinue, or work around, this unwelcome assistance?  Simple, I
>am sure, but it hasn't dawned on me yet.
>

binmode will do it.

use strict;

open OUF, ">out.txt";
binmode(OUF);

print OUF "Hello, World\n";
close(OUF);

etc.

-- 
s e a n @ h e x m a d . c o m | http://hexmad.com


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

Date: 14 Nov 2003 13:07:44 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: newbie dealings with OS "grep -P"
Message-Id: <bp2k30$ivp$1@mamenchi.zrz.TU-Berlin.DE>

Pedro Graca  <hexkid@hotpop.com> wrote in comp.lang.perl.misc:
> My system grep does not support the -P option (perl regexp pattern).
> So I thought it would be a good idea to make a perl script for that
> (after all, only Perl parses perl, right?)
> 
> my first working attempt is grepp1 at the bottom
> 
> 
> And then I realized this wouldn't allow me to pipe things to grepp1,
> so out comes the second attempt (grepp2)
> 
> 
> By now I'm using grepp2 very happily until I needed a case sensitive
> match :(
> After a tough time, this came out:
> $ cat grepp3
>         #!/usr/bin/perl -nsw
>         # use strict;          ## BEGIN does not like strict

BEGIN and strict have no problems with each other.  Just declare your
variables, as strict requires.

> 
>         # grepp [-I] pattern [file1 [file2 [...]]]
> 
>         BEGIN {
>           $expr = shift;       ## need error checking!!!
>           $regex = qr/$expr/i;
>           { no warnings; ## -I might not have been specified
>             if ($I) { $regex = qr/$expr/; }
>           } # end no warnings
>           $\ = "\n"; ## nice little trick

 ...but only needed if you insist in chomp()ing the input.

>         }
> 
>         chomp;
>         print if /$regex/;
> 
> 
> Now I'm working on grepp4, trying to add options from the 'real' grep.
>   + -c == only count matches
>   + -H == print the file name
>   + -n == print the line number
>   + -V == print version and exit
> 
> but I don't like having the "use strict;" out.
> 
> Is it better to manually shift all parameters and verify if they're
> options or the pattern or filenames?
> 
> Did I do something wrong with the "perl -s", "use strict;" and "BEGIN"
> block?

Well, you need to declare your variables with strict.  A first attempt
would look like this (I'm leaving the -I flag out, that's not the problem).
Note that this code does *not* work:

    #!/usr/local/bin/perl -nsw

    my $regex; # we need that outside the BEGIN block
    BEGIN {
        my $expr = shift;
        $regex = qr/$expr/;
    }

    print if /$regex/;

The problem is that -n constructs a loop around the whole script,
which means that the run-time effect of "my $regex" happens each
time around the loop.  But the run-time effect of my() is to clear
the variable, so $regex is not set when it is needed.

The easiest way out is to use a package variable for $regex.  So a
working variant of your script would be:

    #!/usr/local/bin/perl -nsw
    use strict;          ## BEGIN does not like strict

    # grepp [-I] pattern [file1 [file2 [...]]]

    our $regex;
    BEGIN {
      my $expr = shift;       ## need error checking!!!
      $regex = qr/$expr/i or die "invalid pattern: /$expr/"; # like this? :)
      if (our $I) {
          $regex = qr/$expr/;
      }
    }

    print if /$regex/;

A better solution would be to write the loop yourself and keep
"my $regex" out of it.  BEGIN is just a trick to keep some code
out of the loop, but it doesn't work very well in this case.

You may want to take a look at the _Perl Cookbook_, which devotes
a whole chapter to grep-like programs.  (The first edition did,
I guess the second one still does.)

[more grep's snipped]

Anno


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

Date: 14 Nov 2003 13:16:57 GMT
From: Pedro Graca <hexkid@hotpop.com>
Subject: Re: newbie dealings with OS "grep -P"
Message-Id: <bp2kk8$1jlco8$1@ID-203069.news.uni-berlin.de>

Bob Walton wrote:
> You might check out what the folks at the Unix Reconstruction Project 
> did with grep:
>
>     http://www.perl.com/language/ppt/src/grep/index.html

Thank you. I've looked at it and got a few good new ideas for my
project.

-- 
 .sig


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

Date: 14 Nov 2003 13:43:41 GMT
From: Pedro Graca <hexkid@hotpop.com>
Subject: Re: newbie dealings with OS "grep -P"
Message-Id: <bp2m6c$1jmfpp$1@ID-203069.news.uni-berlin.de>

Ben Morrow wrote:
> Pedro Graca <hexkid@hotpop.com> wrote:
>>         #!/usr/bin/perl -nsw
>>         # use strict;          ## BEGIN does not like strict
>
> There is no problem with BEGIN and strictures. You do have to make
> sure all variables are declared before you use them: if you are going
> to use them both inside and outside the BEGIN block then the
> declaration must come before the BEGIN block. So here you would need:
>
>>         # grepp [-I] pattern [file1 [file2 [...]]]
>
>   my ($expr, $regex);

Does not work. Have to make them 'our'
    our ($expr, $regex, $I);

>>         BEGIN {
>>           $expr = shift;       ## need error checking!!!
>>           $regex = qr/$expr/i;
>>           { no warnings; ## -I might not have been specified
>
> Doesn't matter... undef is perfectly false and won't give a warning
> here. $expr might, though, if you don't specify an expression.

Problem was with $I. When I tried
  grepp -I pattern file
there would be no warning, but with
  grepp pattern file
I'd get
  Name "main::I" used only once: possible typo at ...
[ grepp symlinks to the latest greppn ]

Now, with $I declared with 'our' everything is ok :)

 ... well, if I try grepp -X it complains "main::X" used only once

hopefully I'll have that dealt with in grepp4 (or maybe grepp57)

>>           $\ = "\n"; ## nice little trick
>
> Another nice trick is -l, which does the chomp as well.

two more lines off of my code.

>> but I don't like having the "use strict;" out.
>
> That is a good instinct. Cultivate it... :)

It's back on, right where it should!

> I would suggest that it would be better to use one of the Getopt
> modules from CPAN, probably Getopt::Std.

Thank you. That module does not get installed by default, but dealing
with command-line options is such a daunting task I do not feel like
reinventing the wheel for that.

>> Did I do something wrong with the "perl -s", "use strict;" and "BEGIN"
>> block?
>
> If you use -s, then the variable it creates are globals, so you must
> declare them with 'our' rather than with 'my'.

Ah! that's it!


Thank you very much for your answers.

-- 
 .sig


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

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.  

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


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