[6493] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 118 Volume: 8

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 14 14:17:17 1997

Date: Fri, 14 Mar 97 11:00:32 -0800
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 Mar 1997     Volume: 8 Number: 118

Today's topics:
     Re: DFD's for perl5 <seay@absyss.fr>
     Re: Elegant way to strip spaces off the ^ and $ of a va <tchrist@mox.perl.com>
     Re: Elegant way to strip spaces off the ^ and $ of a va (Chris Russo)
     Re: File path separators <tchrist@mox.perl.com>
     Re: flock() problem <rootbeer@teleport.com>
     Re: flock() problem <eryq@enteract.com>
     HELP!! Urgent assistance required please! <Jamief@btinternet.com>
     Re: Help: Regular Expression <wkuhn@uconect.net>
     Re: Install help for 5.003 on Solaris? (David Combs)
     Re: MacPerl5 <wkuhn@uconect.net>
     Re: Open file works under DOS, not under server (Ronald L. Parker)
     perl and C++ <William.Gacquer@obspm.fr>
     Perl and ypcat <Bob_Maillet@dg.com>
     Re: random perl core dumps with obscure message <tchrist@mox.perl.com>
     Re: Recurrence of variable, pct and count (Ronald L. Parker)
     script to patch binaries (binpatch) (Robert L. Urban)
     Re: We've baffled tech support, now on to Usenet... <shimpei@socrates.caltech.edu>
     Re: We've baffled tech support, now on to Usenet... <tchrist@mox.perl.com>
     Re: What language do Perl REs recognize? <seay@absyss.fr>
     Re: What language do Perl REs recognize? <jdane@honlab.nmfs.hawaii.edu>
     Re: What's wrong with "an email" (was: How to spam - le <tchrist@mox.perl.com>
     Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)

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

Date: Fri, 14 Mar 1997 17:16:34 +0000
From: Douglas Seay <seay@absyss.fr>
To: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: DFD's for perl5
Message-Id: <332987F2.DB5@absyss.fr>

Tom Christiansen wrote:
> 
> In comp.lang.perl.misc,
>     vkomandu@mnemosyne.cs.du.edu (Ind study) writes:
> : Really appreciate your help!!
> 
> What'a DFD?  It's like BNF?  If so, there's just do such thing.


A DFD is a Data Flow Diagram, basically just a map of the
data relations of the subprograms.  I would be surprised
if someone bothered doing a DFD for Perl.

doug seay

[posted and emailed]


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

Date: 14 Mar 1997 15:55:48 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Elegant way to strip spaces off the ^ and $ of a variable containing a sentence.
Message-Id: <5gbse4$mfd$1@csnews.cs.colorado.edu>

 [courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc, 
    abigail@ny.fnx.com writes:
:And why set $_ to the element of the array in stead of a copy if we
:aren't supposed to use the side effects?

Why?  I can tell you that: Because it was an accident the first time, and
people started using it, so Larry doc'ed it.  As far as I'm concerned,
it's kinda dodgy and mystifying.  This first came up with grep(), and
the grep name is too strongly associated with a filter function to mean
a munge one to most people, including me.  Thus it's deceptive.  On the
other hand, map() invokes thoughts of the LISP mapcar function, which
is rather different.  Still, an "apply" -- or simply postfix foreach --
would have been more understandable.

    map { $_ += 7 } @foo;		# grrr
    foreach (@foo) { $_ += 7 }		# clear to non lisper

These are illegal, but follow the intent, and were once contemplated:

    $_ += 7 foreach @foo
    { $_ += 7 } foreach @foo
    do { $_ += 7 } foreach @foo;

On the other, this is cool:

    @remainders = map { $_ % 7 } @foo;

because the retval is used.

--tom
-- 
	Tom Christiansen	tchrist@jhereg.perl.com


I've got plenty of inputs and outputs.  I don't need the video. --Andrew Hume


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

Date: Fri, 14 Mar 1997 08:37:24 -0800
From: crusso@alink.net (Chris Russo)
Subject: Re: Elegant way to strip spaces off the ^ and $ of a variable containing a sentence.
Message-Id: <crusso-1403970837240001@buzz.alink.net>

In article <qum7mjbr1iv.fsf@cyclone.stanford.edu>, Russ Allbery
<rra@cs.stanford.edu> wrote:

>Tom Christiansen <tchrist@mox.perl.com> writes:
[...]
>> No, that's a bad way.  You ignored the return value of the function.
>> Map is a filter function.  It seems far less deceptive to write
[...]

[...]
>Programmers ignore return values constantly.  The return value of print is
>regularly annoyed, for example.
[...]

I agree completely.  It's all a matter of style, and "bad" (with
connotations of being wrong) seems extremely subjective to me for this
issue.

I mean, these are the same guys who included:

select((select(STDERR), $| = 1)[0])

in the manual that *they* wrote.  :)  Yes, I know that there's a comment
of its being "bizarre and obscure", but by including it and from the fact
that I've never seen its usage disparaged here, it seems to be "bizarre
and obscure but accepted".  Meanwhile, the map thing isn't bizarre, but
it's a little obscure and *not* accepted.

pot, kettle... black?


Regards,

Chris Russo

----------------------------------------------------------------------
Chris Russo                          A-Link Network Services, Inc.
crusso@alink.net                     Bolo me
http://www.alink.net/~crusso


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

Date: 14 Mar 1997 16:44:17 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: File path separators
Message-Id: <5gbv91$orh$2@csnews.cs.colorado.edu>

 [courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc, ebohlman@netcom.com (Eric Bohlman) writes:
:This reminds me: in the current WIN32 build (303), -d '/perl/' fails, 
:though -d '/perl' succeeds.  This causes a failure in AutoSplit.pm 
:because in checking to see if it needs to build a new directory subtree, 
:it tests for a directory terminated with '/', doesn't find it and then 
:tries to create it, which fails because it already exists.  Is this a 
:known bug?

Historically, precise behaviour in this case was undefined.  Some systems
would tolerate the slash, others would forbid it -- or at least treat
it as meaning something different.  Fortunately, the POSIX standard
mandates that a path to a directory terminating in a slash be treated
exactly the same as one without such.  Obviously, WinDOS hasn't caught up
with the standard yet, so some kludge will doubtless need to be devised.

--tom
-- 
	Tom Christiansen	tchrist@jhereg.perl.com

    echo "ICK, NOTHING WORKED!!!  You may have to diddle the includes.";;
            --Larry Wall in Configure from the perl distribution


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

Date: Fri, 14 Mar 1997 08:40:24 -0800
From: Tom Phoenix <rootbeer@teleport.com>
To: Lutz Albers <lutz@muc.de>
Subject: Re: flock() problem
Message-Id: <Pine.GSO.3.96.970314083524.15346I-100000@kelly.teleport.com>

On Fri, 14 Mar 1997, Lutz Albers wrote:

> Wait a minute. Do I understand this correct: perl isn't flushing the
> file buffer before it releases the lock ? Then I would call this a mayor
> bug :-) 

Yes, if you ask perl to release the lock before you force it to flush the
buffers, then you have caused a major bug. But whose fault is that? :-)

But it's possible that a future version of perl will flush the buffers for
you before locking and after unlocking, just to prevent this problem. That
won't cure all such problems, but it should help. 

-- Tom Phoenix        http://www.teleport.com/~rootbeer/
rootbeer@teleport.com   PGP  Skribu al mi per Esperanto!
Randal Schwartz Case:     http://www.lightlink.com/fors/



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

Date: Fri, 14 Mar 1997 12:12:51 -0600
From: Eryq <eryq@enteract.com>
Subject: Re: flock() problem
Message-Id: <33299523.3DF47AF7@enteract.com>

Randal Schwartz wrote:

> (For those that want to know, the problem with releasing the lock
> first is that someone else can get the flock *before* your buffer
> flushes.  Ouch.)

I take it that setting the filehandle to be unbuffered -- or doing
an explicit flush() before the unlock -- will circumvent such a bug?

-- 
  ___  _ _ _   _  ___ _   Eryq (eryq@enteract.com)
 / _ \| '_| | | |/ _ ' /  Hughes STX, NASA/Goddard Space Flight Cntr.
|  __/| | | |_| | |_| |   http://www.enteract.com/~eryq
 \___||_|  \__, |\__, |___/\  Visit STREETWISE, Chicago's newspaper by/
           |___/    |______/ of the homeless: http://www.streetwise.org


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

Date: 14 Mar 1997 17:24:56 GMT
From: "Jamie Fojut" <Jamief@btinternet.com>
Subject: HELP!! Urgent assistance required please!
Message-Id: <01bc3037$fb2b8880$LocalHost@default>

Jamie Fojut<jamief@btinternet.com>writes:

I am relatively new to perl. I've read the camel book but I've not actually
put any of it into practice yet.
However, I have downloaded a verion of PERL for DOS,PERLGATE and DC.exe.
The instructions that are with it are not too clear to me. Sooooo... can
anyone out there   tell me what I need to do to install it on my PC. I'm
running win95, or alternatively point me to a good installation guide.

One other question. Once I've developed my application scripts, is there
any way to transfer them to a Web server?

I'd appreciate any ideas.

Thanks



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

Date: Fri, 14 Mar 1997 10:20:28 -0500
From: Bill Kuhn <wkuhn@uconect.net>
To: Victor Tolbert <vtolbert@mindspring.com>
Subject: Re: Help: Regular Expression
Message-Id: <33296CBC.5B9F6CA8@uconect.net>

One way:
#!/usr/local/bin/perl -w

$/ = "" ;
open(MAILLIST, maillist);
while (<MAILLIST>) {
	chomp ;
	@matches = () ;
	if (/^Name:/) {
		while (/Name:\s+([\w ]+)|Email:\s+([\w\@\.\-]+)/g) {
			push(@matches,defined($1) ? $1 : $2) ;
		}
		print join("|",@matches),"\n" ;
	}
}

-Bill
-- 
Bill Kuhn
Chief Developer
Wired Markets, Inc.
http://www.buyersindex.com


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

Date: Fri, 14 Mar 1997 17:25:14 GMT
From: dkcombs@netcom.com (David Combs)
Subject: Re: Install help for 5.003 on Solaris?
Message-Id: <dkcombsE71n22.Cxs@netcom.com>

For upcoming 5.4, someone PLEASE do the work of compiling
and making it into a SOLARIS "PACKAGE".

Maybe even for the BETA, now.

(What a wonderful service that would be!)

(yes, I know you can get 5.3 from that sun...canadian site)

THANKS!



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

Date: Fri, 14 Mar 1997 09:03:36 -0500
From: Bill Kuhn <wkuhn@uconect.net>
To: Carl Joel Kuzmich <cjk@omedsrvb.omed.pitt.edu>
Subject: Re: MacPerl5
Message-Id: <33295AB8.6E0D04BF@uconect.net>

No, you don't need a powerpc.  I run it on my Performa 475 (lc68040)
just fine.

Where to get it:
http://err.ethz.ch/~neeri/macintosh/perl-qa.html#Q2

-Bill
-- 
Bill Kuhn
Chief Developer
Wired Markets, Inc.
http://www.buyersindex.com


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

Date: Fri, 14 Mar 1997 17:07:48 GMT
From: ron@farmworks.com (Ronald L. Parker)
Subject: Re: Open file works under DOS, not under server
Message-Id: <332a8476.14280269@10.0.2.33>

On Wed, 12 Mar 1997 10:01:54 -0600, dsmith6@sct.edu wrote:

>Why does the following code work fine under DOS, but doesn't appear
>to work under the O'Reilly Web Server.  From the server, the file
>doesn't appear to read in any data. Other CGI's seem to work OK.
>
>#!/usr/bin/perl
>
>$file = "ratedata/comments.txt";

WebSite sets the current directory to the CGI working directory you
specified on the General tab.  (Apache and NCSA HTTPd set it to the
directory the script resides in.)

To mimic the Apache or NCSA behavior, I have changed the Standard CGI
Shell on the CGI tab to

perl c:\perlprog\fixpath.pl

where fixpath.pl is the short but sweet script 

chdir(($ARGV[0]=~/(.*)\\/)[0]);exec perl,@ARGV

Note, however, that this is about the same as putting PERL.EXE in your
cgi-bin in terms of security holes you can drive trucks through.  You
really should validate the contents of @ARGV first.  In my case, it's
a small private web server on a protected network, so this isn't an
issue.

--
Ron Parker
Software Engineer
Farm Works Software       Come see us at http://www.farmworks.com


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

Date: Fri, 14 Mar 1997 18:24:12 +0000
From: root <William.Gacquer@obspm.fr>
Subject: perl and C++
Message-Id: <332997CC.35478C4D@obspm.fr>

Hi! 
	I am just starting learning perl. I plan to do
a simple program and I wonder if I still have to use C/C++
(As I ever do) to do this or if I can use perl in my C++ code.
The aim is to extract information from a file which is formatted
like this:

------------------------------------------------------------------------
   Bytes Format  Units   Label    Explanations
------------------------------------------------------------------------
   2- 11  F10.4  0.1nm   lambda   Wavelength 
  13- 21  A9     ---     Element  Element (or molecule) name 
  22- 23  I2     ---     Z        [0/90] Atomic element number 
  24- 25  I2     ---     Ion      [0/15] Electronic charge
  27- 28  A2     ---    n_lambda  [NACLPFf?* ] Note concerning the line 
  30- 41  A12    ---   Multiplet  Multiplet number
      43  A1     ---     RefL     Reference of intensity (2)
  45- 57  A13    ---     Intens   Intensity with Moore notation (2)
  59- 65  F7.3   eV      IP       ? Ionisation Potential
  68-100  A33    ---     SpTypes  List of concerned spectral types


and the file I will explore looks like this:

// begining of the file 

  2951.40   CrII     24 1              59 A 10                     
  2951.95   CrII     24 1              59 A 10                     
  2952.07   V II     23 1               2 A 150                    
  2953.358  CrII     24 1              27 B 35                     
  2953.706  CrII     24 1              66 B 45                     
  2953.774  FeII     26 1               2 A 11                     
  2953.940  FeI      26 0              10 A 50R                    
  2954.050  FeII     26 1              61 A 4                      
  2954.332  V I      23 0              18 C 20                     
  2954.67   CrII     24 1             104 D 10                     
  2955.12   CrII     24 1              59 A 10                     
  2955.71   CrII     24 1              58 A 2                      
  2956.133  TiI      22 0              30 A 70R                    
  2956.60   CrII     24 1              58 A 10                     
  2956.797  TiI      22 0              30 E 25                     
  2957.28   CrI      24 0                 B 3w                     
  2957.33   V I      23 0              18 C 10?                    
  2957.365  FeI      26 0              10 A 30R       
  etc ...
// end of the file


I want to create of command (named "get_element") which returns 
the nearest element corresponding to the value that I requested. 

eg:

"get_element(2957.26)" has to return "CrI"
"get_element(2952.09)" has to return "V II"

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

So what is the corresponding perl scrit and how can I incorporate it
into a C++ code?


		Many thanks,
		William Gacquer

PS: please mailto://William.Gacquer@obspm.fr

-----------------------------------
Gacquer William
DASGAL - Batiment B
Observatoire de Paris                    tel: 33 1 40 51 22 53
61, Avenue de l'Observatoire             fax: 33 1 40 51 22 32
F75014 PARIS - FRANCE          email: William.Gacquer@obspm.fr
-----------------------------------


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

Date: Fri, 14 Mar 1997 13:00:42 -0500
From: Bob Maillet <Bob_Maillet@dg.com>
Subject: Perl and ypcat
Message-Id: <3329924A.436F@dg.com>

Is there a command or commands that can invoke ypcat filename  to work
in perl?

Bob



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

Date: 14 Mar 1997 16:54:57 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: random perl core dumps with obscure message
Message-Id: <5gbvt1$orh$4@csnews.cs.colorado.edu>

 [courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc, 
    ilya@math.ohio-state.edu (Ilya Zakharevich) writes:
:I'm absolutely ignorant in this, but is not the POSIX signal stuff
:just the way to do it without a signal handler? What was that
:discussion on p5-p about interrupting/noninterrupting (sp?) signals?

Well, one could do that, but it's a lot of hassle because it requires
that one use POSIX:: stuff instead of just %SIG.  Perl's signals be
default restart system calls if at all possible.

--tom
-- 
	Tom Christiansen	tchrist@jhereg.perl.com
    last|perl -pe '$_ x=/(..:..)...(.*)/&&"'$1'"ge$1&&"'$1'"lt$2'
    That's gonna be tough for Randal to beat...  :-)
            --Larry Wall in  <1991Apr29.072206.5621@jpl-devvax.jpl.nasa.gov>


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

Date: Fri, 14 Mar 1997 16:57:38 GMT
From: ron@farmworks.com (Ronald L. Parker)
Subject: Re: Recurrence of variable, pct and count
Message-Id: <33297fe6.13111910@10.0.2.33>

[emailed and posted]

On 10 Mar 1997 12:07:15 -0700, cpayne@xmission.xmission.com (Carl
Payne) wrote:

>- what percentage of people do this
>- listed by employee name, where do these people go FROM the ftdoor
>- listed by employee name, where do they go after that

This sounds suspiciously like the kind of information one would want
from a web server log file if one's #*?&%* provider didn't (and won't)

log the Referer: field.  For that reason, you might want to ask around
a www group or two to see if someone's already implemented it and is
willing to share. (I haven't yet, but I'm working on it.)

>I can do the total percentages based on destination and employee,
>but I can't figure out how to track the employee's second stop,
>their third or fourth.  

What you need is a data structure that splits the log entries into a 
"bin" for each employee.  This sounds like a hash of array references.
(man perlref)  If the log isn't already in order, you might need to 
sort each bin by date/time, but once you've done that you should be 
able to get the n'th stop for any given employee rather trivially.

>I can count how many times each destination
>was visited, but not how many times each employee visited it, 

This is just a matter of running each of the above bins through your 
existing count routine.

>and
>I can count the percentage of employees that use each destination,
>(100% use the front door, 75% use the FRIDGE, etc), but not what
>percent each destination is a 2cd, 3rd or 4th stop.

This might necessitate another data structure, such as a hash on 
destination that contains counts for each stop number.  This could be 
built at the same time you build the hash by employee (if the log was
in the proper order already.)

--
Ron Parker
Software Engineer
Farm Works Software       Come see us at http://www.farmworks.com


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

Date: 14 Mar 1997 18:05:16 GMT
From: urban@nasaxp.rto.dec.com (Robert L. Urban)
Subject: script to patch binaries (binpatch)
Message-Id: <5gc40s$13k@rtnews.rto.dec.com>

Hello Perlers,

I spent a few hours writing a script to patch binary files, and I
thought I'd make the fruit of my labor generally available.  It only
patches ascii strings, I'm afraid, but you're welcome to pick up
where I left off.

The script can:
	+ search for one or all occurances of a string and replace them
	+ search for a string and print the offset(s)
	+ overwrite a string at a particular offset

I've tested it briefly on Digital UNIX... not very thoroughly though, so
if you intend to patch your kernel, please test it before you overwrite
and reboot!!!

If you do find some problem, please let me know.  I've tried to make it
rebust.  It reads chunks in (and doesn't therefore slurp the entire
binary into memory -- a teensy problem when your binary is 5MB), and tries
to handle the cases properly when the chunk border falls right on
the string to be replaced.  Same goes for using an offset to overwrite
a part of the binary.

If you are looking for a really good tool for comparing binaries, for
example, to check if binpatch did it's job right, I recommend
the GNU Project's 'cmp' (diffutils), which, with the '-cl' flags, will
give you the offset and value of differing bytes.

help: binpatch -h

-- 
Rob Urban
Digital Equipment GmbH
Freischuetzstr. 91
81927 Muenchen
Germany

----------------------- start -----------------------
#!/usr/local/bin/perl
######################################################################
## script to patch strings in binary files.  see binpatch -h
## for details.
##
## I recommend setting ts=4 in vi
##
######################################################################
$filepos = 0;
$done = 0;
$replcnt = 0;
$action = 'replace';
$scheme = 'search';
$chunksize = 4096;
$occurance = 1;
@args = ();
$READPOS = 0;
$WRITEPOS = 0;
$shellreturn = 1;	# success

while ($_ = shift(@ARGV)) {
	if (/^-f(.*)$/) {
		$infile = $1 ? $1 : shift;
	} elsif (/^-off=?(.*)$/) {
		$offset = $1 ? $1 : shift;
		$scheme = 'offset';
		$shellreturn = 0;
	} elsif (/^-o(.*)$/) {
		$oldstring = $1 ? $1 : shift;
	} elsif (/^-n(.*)$/) {
		$newstring = $1 ? $1 : shift;
	} elsif (/^-s(.*)$/) {
		$oldstring = $1 ? $1 : shift;
		$action = 'search';
	} elsif (/^-d(.*)$/) {
		$debug = $1 ? $1 : 1;
	} elsif (/^-(\d+)$/) {
		$occurance = $1;
	} elsif (/^-all$/) {
		$occurance = 0;
	} elsif (/^-h/) {
		Usage();
		exit;
	} elsif (/^-/) {
		print "What's that? [$_].\n";
		exit -1;
	} else {
		push(@args,$_);
	}
}

foreach (@args) {
	if ($scheme eq 'offset') {
		if (!$infile) {$infile = $_; next;}
		if (!$newstring) { $newstring = $_; next;}
		else {
			print "What's that? [$_].\n";
			exit -1;
		}
	} else {
		if (!$infile)    { $infile = $_; next;}
		if (!$oldstring) { $oldstring = $_; next;}
		if (!$newstring) { $newstring = $_; next;}
		print "What's that? [$_].\n";
		exit -1;
	}
}

if ($debug) {
	print "SCHEME: $scheme\n";
	print "ACTION: $action\n";
	print "INFILE: $infile\n";
	print "OLDSTR: $oldstring\n";
	print "NEWSTR: $newstring\n";
	print "OFFSET: $offset\n";
}

if (!$infile) {
	print "you must supply a file to patch\n";
	Usage();
	exit -1;
}

$outfile = $infile.'.out';

############################################################
# get the mode of the input file (minus the filetype) so I
# can set the mode on the output file, if necessary
############################################################
$mode = (stat('/tmp/gp'))[2] & 07777;

if ($action eq 'replace') {
	if ($scheme eq 'search') {
		if (!$oldstring || !$newstring) {
			print "you must supply old and new strings\n";
			Usage();
			exit -1;
		}
		if (length($oldstring) != length($newstring)) {
			print "you must supply old and new strings\n";
			Usage();
			exit -1;
		}
	} else {
		if (!$newstring) {
			print "you must supply a new string\n";
			exit -1;
		}
	}
}
if (($action eq 'search')&&!$oldstring) {
	print "parameters are missing.\n";
	Usage();
	exit -1;
}

$strlen = length($oldstring) ? length($oldstring) : length($newstring);

open(IN,$infile) || die "open to read";
binmode(IN);					# for the Bill fans
if ($action eq 'replace') {
	print "writing to [$outfile]...\n";
	open(OUT,">$outfile") || die "open to write";
	binmode(OUT);				# for the Bill fans
}

$carryover = '';

######################################################################
## the trick here is:
## in order to avoid missing a string that falls right on a chunk
## border, I use index() to test a chunk for the existence of the
## string to be replaced (or searced for).  Then, as long as I'm
## still searching (i.e., I haven't found the string to be replaced),
## when I'm through with a chunk, I write the chunk MINUS a bit to
## the output file.  The length of the bit not written is the length
## of the string to be found.  Then I prefix that bit onto the next
## chunk read so and repeat my index() test.  More or less:
##
##     ========              [chunk]
##           ========        [next chunk]
##   overlap ^^    ========  [next chunk]
##   overlap       ^^
##
## This should work 
## in both the single and multiple replacement cases, because in the
## multi-replacement case, assuming the string fell exactly in the bit
## that I hold over, the replacement will happen, then the bit will
## be prefixed, and the string will not match anymore (come to think
## of it, it wouldn't really matter either way).
## There is one anomoly, in the above-mentioned case, the SEARCH
## option would report an occurence of a string twice at the same
## offset. oh well.
######################################################################
TOP: while($chunklen = Read($chunk,$chunksize)) {
	if (!$done) {
		if ($scheme eq 'search') {
			$chunk = $carryover.$chunk;
			$chunklen += length($carryover);
			$carryover = '';
			##############################################################
			## index doesn't seem to want to return the real offset within
			## a scalar when the data is binary, so I must use
			## substr to actually find the offset.
			## however, index *does* seem to reliably *find* a substr in
			## a binary scalar...
			## *** your milage may vary ***
			## (I'm using a real unix -- Digital UNIX :-))
			##############################################################
			if (index($chunk,$oldstring) != -1) {
				#######################
				## index() found string
				#######################
				$pos = 0;
				while($pos < $chunklen) {
					##########################################
					## go through chunk, one byte at a time...
					##########################################
					$tmp = $chunklen - $pos;
					####################################################
					## for a single replacement, I don't have a problem,
					## but for multiples, I must still check for the
					## target string being chopped by a chunk boundary
					####################################################
					if (($tmp < $strlen)&&
						(substr($chunk,$pos,$tmp) eq substr($oldstring,0,$tmp)))
					{
						###############################################
						## match was cut by chunk boundary
						## this _could_ backfire if I were
						## searching for 'foobar' and the last 3 bytes
						## of the current chunk were 'foo' and the next
						## chunk continued with 'foofoofoofoofoofoo...'
						## till the end but what the hell...
						###############################################
						if ($debug) {
							print "grabbing a few more bytes...\n";
						}
						$len = Read($smallchunk,$strlen-$tmp);
						if ($len != $strlen-$tmp) {
							print "read failed ",$strlen-$tmp," bytes, dying\n";
							exit -1;
						}
						$chunk .= $smallchunk;
						$chunklen += $len;
						redo;
					}
					if (substr($chunk,$pos,$strlen) eq $oldstring) {
						print "found at ",$filepos+$pos;
						$shellreturn = 0;
						$replcnt++;
						if (($action eq 'replace')&&
							(($occurance == 0)||
							 ($replcnt == $occurance)))
						{
							substr($chunk,$pos,$strlen) = $newstring;
							print ", changed.";
							if ($occurance) {		# only one replacement
								$done = 1;
								print "\n";
								next TOP;
							}
						}
						print "\n";
						$pos += $strlen;
					} else {
						$pos++;						# no match? goto next byte
					}
				}
			}
			if ($scheme eq 'search') {
				$carryover = substr($chunk,$chunklen - $strlen,$strlen);
				$chunklen -= $strlen;
			}
		} else {			# $scheme eq 'offset'
			if (($filepos < $offset)&&($filepos+$chunklen > $offset)) {
				$pos = $offset - $filepos;
				if ($pos + $strlen > $chunklen) {
					if ($debug) {
						print "whoops! at end, reading a bit more...\n";
					}
					$len = Read($smallchunk,$strlen);
					if ($len != $strlen) {
						print "failed to read $strlen bytes, dying\n";
						exit -1;
					}
					$chunk .= $smallchunk;
					$chunklen += $strlen;
				}
				print "replacing at position [$pos] in chunk.\n";
				substr($chunk,$pos,$strlen) = $newstring;
				$done = 1;
			}
		}
	}
} continue {
	if ($action eq 'replace') {
		Write(substr($chunk,0,$chunklen),$chunklen) || die "syswrite";
	}
	$filepos += $chunklen;
}

if ($carryover) {
	Write($carryover,length($carryover));
}

close(IN);

if ($action eq 'replace') {
	close(OUT);
	chmod $mode, $outfile;
}

if ($chunklen < 0) {
	print "error with sysread\n";
}

exit $shellreturn;

##
## my version of sysread and syswrite
## so that I can track file offsets...
##
sub Read {
	my($ret) = sysread(IN,$_[0],$_[1]);
	if ($ret == -1) {
		print "error reading input file\n";
		exit -1;
	}
	if ($debug) {
		print "%% read from offset $READPOS, SIZE=$ret\n";
	}
	$READPOS += $ret;
	$ret;
}

sub Write {
	my($ret) = syswrite(OUT,$_[0],$_[1]);
	if ($ret == -1) {
		print "error writing output file\n";
		exit -1;
	}
	if ($debug) {
		print "%% wrote at offset $WRITEPOS, SIZE=$ret\n";
	}
	$WRITEPOS += $ret;
	$ret;
}

sub Usage {
	print <<_EOF_;

Usage:
binpatch <filename> <OLD> <NEW>             - Replace <OLD> with <NEW>
binpatch <filename> -off=<OFFSET> <STRING>  - REPLACE at OFFSET
binpatch <filename> -s<STRING>              - FIND OFFSET of STRING

OPTIONS:
  -<N>            - replace the Nth occurance of the string (0=all)
                    (default is 1st occurance only)
  -all            - replace all occurances
  -f<filename>    - explicitly specify filename
  -off=<offset>   - explicitly specify offset       ('-off' is required)
  -off <offset>   - same
  -s <string>     - specify search string
  -o <string>     - explicitly specify <oldstring>
  -n <string>     - explicitly specify <newstring>

NOTE: when replacing a string, the lengths of OLD and NEW must be equal

_EOF_
}
------------------------ end ------------------------



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

Date: 14 Mar 1997 16:59:30 GMT
From: Shimpei Yamashita <shimpei@socrates.caltech.edu>
Subject: Re: We've baffled tech support, now on to Usenet...
Message-Id: <5gc05i$rnh@gap.cco.caltech.edu>

Jason Maggard <jman95@ix.NOSPAMnetcom.com> writes:
>
>Howdy!!!!
>
>	This program is a really simple thing, but I cannot get it to run on my
>web server.  I use netcom, and all other scripts run fine.  Any input???? I
>spent 2 hours with the Netcom hosting support kids, and they just finally
>gave up with a resounding "Hmph, I dunno..."
>
>Thanks, and come see us at ClaytorRE.com!
>(There's always time for a cheesy plug.)
>
>#Receptionist.pl ~ Jason Maggard
>#! /usr/bin/local/perl5

You MUST have #!<wherever your perl executable is> as the first line of
your script if you want Unix to know that it is to be read by perl (or
anything else, for that matter); otherwise it will be interpreted by
/bin/sh. Read the comp.unix.questions FAQ for a discussion on finer points
of the #! convention.

It looks like better qualified people have already critiqued your code,
so I won't bother with that....

-- 
Shimpei Yamashita                  <http://socrates.caltech.edu/%7Eshimpei/>



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

Date: 14 Mar 1997 16:51:09 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: We've baffled tech support, now on to Usenet...
Message-Id: <5gbvlt$orh$3@csnews.cs.colorado.edu>

 [courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc, 
    cseawood@telabridge.com (Christopher) writes:
:The only thing that immediately pops into mind is that you'll need to escape
<BAD WRAP>the @ in the address.
:Use $recipient = 'office\@claytorre.com';

Um, not when it's single-quoted.  That has no effect.  It's the
interpolative contexts (double-quoted) that have the problem that
that fixes.

--tom
-- 
	Tom Christiansen	tchrist@jhereg.perl.com
    Does the same as the system call of that name.
    If you don't know what it does, don't worry about it.
            --Larry Wall in the perl man page regarding chroot(2)


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

Date: Fri, 14 Mar 1997 18:24:00 +0000
From: Douglas Seay <seay@absyss.fr>
To: Ronald Fischer <rfi@uebemc.siemens.de>
Subject: Re: What language do Perl REs recognize?
Message-Id: <332997C0.6B67@absyss.fr>

Ronald Fischer wrote:
> 
> >>>>> On Thu, 13 Mar 1997 00:15:41 GMT
> >>>>> "Bernie" == Bernie Cosell <bernie@fantasyfarm.com> wrote:
> Bernie> I was wondering if anyone has characterized the languages accepted by Perl
> Bernie> Regular Expressions. The class is larger than the Regular Languages but
> Bernie> isn't the context-free languages... what is it?
> Could you give an example of a Perl RE that describes a language that
> can not be recognized by a type 3 grammar?
> --
> Ronald Otto Valentin Fischer
> business:       ronald.fischer@uebemc.siemens.de
> private:        ronald.fischer@acm.org
> http://ourworld.compuserve.com/homepages/ronald_fischer


When I studied automata I didn't use the term "type 3 grammar",
but I'll take it to be a regular expression.

The use of back references is non-regular.  All REs can be
described with

	A -> bC
	A -> d
	A -> lambda

where A & C are non-terminals, b & d are terminals
and lambda is NULL/nothing/void.  Perl allows limited
used of

	A -> bcb

with a back reference, such as

	/([abc])[yxz]+\1/

which will match [abc] followed by [xyz]+, followed
by which ever letter was matched in [abc]

	axa	matches
	axb	doesn't, because the back reference \1
		refers to the "a", not "[abc]"

note that this is not all the way to a CFG acceptance
because that requires

	A -> bCb  (not just A -> bcb)

doug seay


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

Date: 14 Mar 1997 08:15:24 -1000
From: Joseph Dane <jdane@honlab.nmfs.hawaii.edu>
Subject: Re: What language do Perl REs recognize?
Message-Id: <wowwraxrur.fsf@menpachi.nmfs.hawaii.edu>

>>>>> "Ronald" == Ronald Fischer <rfi@uebemc.siemens.de> writes:

>>>>> On Thu, 13 Mar 1997 00:15:41 GMT
>>>>> "Bernie" == Bernie Cosell <bernie@fantasyfarm.com> wrote:
    Bernie> I was wondering if anyone has characterized the languages
    Bernie> accepted by Perl Regular Expressions. The class is larger
    Bernie> than the Regular Languages but isn't the context-free
    Bernie> languages... what is it?

    Ronald> Could you give an example of a Perl RE that describes a
    Ronald> language that can not be recognized by a type 3 grammar?
    Ronald> -- Ronald Otto Valentin Fischer business:
    Ronald> ronald.fischer@uebemc.siemens.de private:
    Ronald> ronald.fischer@acm.org
    Ronald> http://ourworld.compuserve.com/homepages/ronald_fischer

I think maybe what he was referring to was a place somewhere between a
context free grammar and a regular set.  Perl RE's are not regular
(backreferences, for instance) but they are not as powerful as CFGs
either.  The grammar

S -> (S)S

is context free, but generates a language (the set of all balanced
parentheses) that is not recognizable by a perl RE.

Maybe someone should come up with a name?  Type 2.5 grammars?
Peregualar Expressions?

Joe


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

Date: 14 Mar 1997 16:34:23 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: What's wrong with "an email" (was: How to spam - legitimately)
Message-Id: <5gbumf$orh$1@csnews.cs.colorado.edu>

 [courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc, Ronald Fischer <rfi@uebemc.siemens.de> writes:
:It is always an interesting experience for a native speaker of the
:German language to follow discussions of English speakers about their
:language. Assuming that I am not the sole foreign subscriber to this group,
:would you mind explaining to us what's the problem with writing "the email"
:(as in "did you get my email yesterday", or "what's in the email
:today"), and why I should not cook my eggs in a frying pan (do I have
:to give up fried eggs :-(?).

There's nothing wrong with your usage of "email" above.

What instead we've been complaining about in these parts is the pernicious
mut(il)ation of "email" into a count noun, much the way many Germans
(improperly) do with "information" when first learning to speak English.
You see, in English neither "mail" nor "information", nor by extension
"email", may be counted.   Thus "mails" and "informations" both sound
rather peculiar and unnatural to the ear.  The distinction is that one
receives "much or little mail or information", not the malformed "many
or few mails or informations" [sic].

I have come to believe that the linguistic dissonance we're experiencing
is rooted in this: that the American mass media, a body congenitally
devoid of all semblance of clue and subtlely, have insistently pushed the
nontechnical masses on the internet bandwagon, and in so doing, they have
unknowingly mangled an established term.  (Some would quite reasonably
argue that it was the public who pushed the media, not vice-versa.)
By following this poor example, those new to email have manged to pick
up a bad habit, one that may or may not be destined to be elevated to 
accepted usage.

But for now, there would seem no reason to emulate them.

Once upon a time there was (well, and still to this day remains) the term
"pseudointellectual", generally used for a person prone to sputter the buzz
words and name-dropping reminiscent of the so-called intelligentsia,
yet without any profound understanding of the terms they were employing.
In the same vein, many of us greybeards perceive the misuse of "emails"
as a count noun to be an indication of a mere "pseudogeek", a person who
ingenuously engages in trendy pseudotechnobabble for the simple sake of
appearing technically astute to those who are not.  Such unabashed (and
uninformed) cybercant has the unwanted effect of triggering precisely
the opposite reaction  on the rest of us.

This is what the current imbroglio is all about.

On the other hand, the term "pseudointellectual", just like the term
"elite", is now all too often used as a mean-spirited term with which
to bash others whom one perceives as less gifted, educated, or cultured
than oneself.  It is not entirely outside the realm of possibility that
a not dissimilar phenomenon is at work in this particular case.

--tom
-- 
	In the common people there is no wisdom, 
	no penetration, no power of judgment.
			    --Marcus Cicero


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

Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 8 Mar 97)
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.misc (and this Digest), send your
article to perl-users@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.

The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.

The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.

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 V8 Issue 118
*************************************

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