[9617] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 3211 Volume: 8

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 21 06:07:36 1998

Date: Tue, 21 Jul 98 03:00:20 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Tue, 21 Jul 1998     Volume: 8 Number: 3211

Today's topics:
        [NEEDED]:Password History Script <simon.whiting@dpie.gov.au>
    Re: Bug in regex quantifiers? (Craig Berry)
    Re: clp.moderated <davidc@selectst.com>
    Re: Finding new files (create after a time stamp) ()
    Re: Finding new files (create after a time stamp) <jwb79@mail.idt.net>
    Re: Fun with large hashes (Ilya Zakharevich)
    Re: Fun with large hashes (M.J.T. Guy)
    Re: Fun with large hashes (Ilya Zakharevich)
        GIF Line-Breaks in Perl <wesley@nospam.com>
    Re: GIF Line-Breaks in Perl (Craig Berry)
    Re: GIF Line-Breaks in Perl (Larry Rosler)
    Re: How to connect to a socket ? <davidc@selectst.com>
    Re: How to tell if a scalar is a number? (Larry Rosler)
    Re: Is 3484000000 a negative number ? (courtesy)
    Re: Is 3484000000 a negative number ? (M.J.T. Guy)
    Re: mod_perl on RedHat 5.1 (Leslie Mikesell)
    Re: open (IN, "foo.txt") works, open (IN, "$foo") does  (J|rgen P|nter)
    Re: open (IN, "foo.txt") works, open (IN, "$foo") does  <tom@smart.ruhr.de>
    Re: Overriding builtin functions <tchrist@mox.perl.com>
    Re: Perl for kids <ryan@steelplan.com.au>
        Restricting refering domains access to script? (Mark-Jason Dominus)
    Re: subscript on numeric (J|rgen P|nter)
    Re: temp directory for both unix and windows platform (M.J.T. Guy)
    Re: What is awk better at than perl? (Larry quote) (Ilya Zakharevich)
        What's wrong? <henrwi00@usfca.edu>
    Re: Wierd behaviour of .. operator (M.J.T. Guy)
        Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)

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

Date: Tue, 21 Jul 1998 16:51:07 +1000
From: Simon Whiting <simon.whiting@dpie.gov.au>
Subject: [NEEDED]:Password History Script
Message-Id: <35B43A5A.BD1C1A65@dpie.gov.au>

G'day All,

I have a UNIX systems that requires a password history of
the last 5 passwords.  I've searched for such a script, but
haven't found anything.  Does such a script exist?

Cheers,
Simon.




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

Date: 21 Jul 1998 05:47:44 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Bug in regex quantifiers?
Message-Id: <6p1a21$fo$1@marina.cinenet.net>

Larry Rosler (lr@hpl.hp.com) wrote:
: The '1234' part of '123456789' matches your regex, doesn't it?  If you 
: want this not to match, you have to tell it that the next thing (if 
: any) is not a digit:
: 
: if ($patch_num !~ /^\d{3,4}(?!\d)/) {
: 
: I've also added a front anchor, just in case, and replaced your digit 
: ranges by the more shapely '\d'.

Actually, the front anchor is not "just in case", but rather required to
get the desired functionality.  Otherwise, the regex could match '6789' in
'123456789'.

---------------------------------------------------------------------
   |   Craig Berry - cberry@cinenet.net
 --*--    Home Page: http://www.cinenet.net/users/cberry/home.html
   |      Member of The HTML Writers Guild: http://www.hwg.org/   
       "Every man and every woman is a star."


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

Date: Tue, 21 Jul 1998 19:15:42 +1000
From: David Coldrick <davidc@selectst.com>
Subject: Re: clp.moderated
Message-Id: <35B45C3E.7BE68BDB@selectst.com>

Anyone have the details on how to register for perl moderated? Only
thing I've found is a ref to something on plover.com that says you need
to give the right subject to your email request, but doesn't actually
say what that subject is to be :-(

Regeards,
David


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

Date: 21 Jul 1998 05:45:54 GMT
From: eyanar@dax-atm.rz.uni-frankfurt.de ()
Subject: Re: Finding new files (create after a time stamp)
Message-Id: <6p19ui$iam$1@grapool30.rz.uni-frankfurt.de>

drubin@gatekeeper.cb.att.com wrote:
> Hello,

> What is the best way (using ksh or perl) to find all files in a directory
> created after a timedate stamp (such as 07/20/98:10:10)?  I was hoping this
> would be simple, but I keep coming up with very messy solutions.

> Thanks for any suggestions.

>      - Dan

find . -type f -newer XXX -print
Wher XXX is a file created which touch.
Which touch you can modify exactly the timestamp of the file.
man touch

Tschau

Erkan



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

Date: 21 Jul 1998 08:08:06 GMT
From: "jim babbington" <jwb79@mail.idt.net>
Subject: Re: Finding new files (create after a time stamp)
Message-Id: <01bdb47d$a3818cd0$6488fdc7@dixon>



drubin@gatekeeper.cb.att.com wrote in article
<6p09lq$j8j$1@nnrp1.dejanews.com>...
: What is the best way (using ksh or perl) to find all files in a directory
: created after a timedate stamp (such as 07/20/98:10:10)?  I was hoping
this
: would be simple, but I keep coming up with very messy solutions.

Using perl, you can use the -M test to determine the age of the file:

foreach (<*>) { 
	$age = -M $_;
	print $_, " is ", $age, " days old\n";
}

Then  subtract that from the current date to get its create date. 
--
I hope this helps,
Jim


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

Date: 21 Jul 1998 06:10:42 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: Fun with large hashes
Message-Id: <6p1bd2$45t$1@mathserv.mps.ohio-state.edu>

[A complimentary Cc of this posting was sent to Martin Gleeson
<gleeson@unimelb.edu.au>],
who wrote in article <gleeson-ya02408000R2107981333160001@news.unimelb.edu.au>:
> Running this gives the error:
> Allocation too large at ./foo.pl line 13.
> 
> Line 13 is the 'while' line. It got 35,097 items through the hash before
> dying with this error. The error is described in the blue camel as
> "You can't allocate more than 64K on an MS-DOS machine". Well, I'm
> not on an MS-DOS machine (nor am I likely to ever be :), and perl -v
> says: "This is perl, version 5.004_04 built for alpha-dec_osf". It's on
> an AlphaServer 4100.

As it is explained in all the manuals, you are running a dosish perl,
whatever you claim.  This message *cannot* be printed unless
HAS_64K_LIMIT is defined, and it is defined only in dosish.h.  In
turn, this file is included only if DOSISH is defined, and it is
defined only if

    if defined(MSDOS) || defined(atarist) || defined(WIN32)

As a last resort, inspect your perl -V.

Ilya


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

Date: 21 Jul 1998 06:29:34 GMT
From: mjtg@cus.cam.ac.uk (M.J.T. Guy)
Subject: Re: Fun with large hashes
Message-Id: <6p1cge$h58$1@pegasus.csx.cam.ac.uk>

Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
>[A complimentary Cc of this posting was sent to Martin Gleeson
><gleeson@unimelb.edu.au>],
>who wrote in article <gleeson-ya02408000R2107981333160001@news.unimelb.edu.au>:
>> Running this gives the error:
>> Allocation too large at ./foo.pl line 13.
>> 
>> Line 13 is the 'while' line. It got 35,097 items through the hash before
>> dying with this error. The error is described in the blue camel as
>> "You can't allocate more than 64K on an MS-DOS machine". Well, I'm
>> not on an MS-DOS machine (nor am I likely to ever be :), and perl -v
>> says: "This is perl, version 5.004_04 built for alpha-dec_osf". It's on
>> an AlphaServer 4100.
>
>As it is explained in all the manuals, you are running a dosish perl,
>whatever you claim.  This message *cannot* be printed unless
>HAS_64K_LIMIT is defined, and it is defined only in dosish.h.  In
>turn, this file is included only if DOSISH is defined, and it is
>defined only if
>
>    if defined(MSDOS) || defined(atarist) || defined(WIN32)

Wrong.   You are talking about the wrong error message.

Perl confusingly has two error messages which are very similarly worded.
>From   perldoc perldiag:

     Allocation too large: %lx
         (X) You can't allocate more than 64K on an MS-DOS
         machine.

     Allocation too large
         (F) You can't allocate more than 2^31+"small amount"
         bytes.

Martin is suffering from the second message, not the first.   Note the
absence of a colon in his quote.

And what causes that, you probably need a DB_File expert to answer.


Mike Guy


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

Date: 21 Jul 1998 09:49:16 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: Fun with large hashes
Message-Id: <6p1o6s$1m3$1@mathserv.mps.ohio-state.edu>

[A complimentary Cc of this posting was sent to M.J.T. Guy
<mjtg@cus.cam.ac.uk>],
who wrote in article <6p1cge$h58$1@pegasus.csx.cam.ac.uk>:
> Wrong.   You are talking about the wrong error message.
> 
> Perl confusingly has two error messages which are very similarly worded.
                   ^^^
had!

> From   perldoc perldiag:
> 
>      Allocation too large: %lx
>          (X) You can't allocate more than 64K on an MS-DOS
>          machine.
> 
>      Allocation too large
>          (F) You can't allocate more than 2^31+"small amount"
>          bytes.

Mea culpa!  But not any more!  This is why I did not find this message
when grepping 5.004_72.

Nowadays (nowamorrow? ;-) all the out-of-memory messages start with
(guess?) "Out of memory".

Ilya


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

Date: Tue, 21 Jul 1998 01:34:42 -0500
From: Wesley Miaw <wesley@nospam.com>
Subject: GIF Line-Breaks in Perl
Message-Id: <35B43680.3CD758B8@nospam.com>

Hiya,

I'm encountering trouble with the following Perl code in a CGI when executed
on Windows NT using IIS 4.0 and Perl for win32 build 316 (Perl 5.003).

    print "Content-type: image/gif\n\n";
    open(IMAGE, "$members_dir\\$id\\$id\.gif") or return 0;
    binmode IMAGE;
    while (<IMAGE>) {
        print $_;
    }
    close IMAGE;

For some reason the above code returns the GIF data with DOS line breaks
instead of the correct UNIX line breaks. This is the only difference between
the data returned by a direct browser call to the image and the data returned
by the script. Naturally, the browser (and Photoshop) cannot decode the
"DOS'ed" file correctly.

Since the GIF file on the server is indeed stored with UNIX line breaks
(uploaded in binary mode from a Mac and downloaded through Fetch in binary
mode to double check), and the Perl script is only outputting exactly what
it's reading, this leads me to believe the server itself may be rewriting the output.

Thanks in advance for any help. I would greatly appreciate a reply via e-mail
to wesley@woais.com (not the Reply-To in the header) if it's not too much trouble.

Sincerely,
-- 
Wesley Miaw                               wesley@woais.com
World of Artists Internet Services        http://www.woais.com/
71 Middlesex Drive                        Tel: 518-439-0412
Slingerlands, NY 12159                    FAX: 518-439-9722


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

Date: 21 Jul 1998 05:58:39 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: GIF Line-Breaks in Perl
Message-Id: <6p1amf$fo$2@marina.cinenet.net>

Wesley Miaw (wesley@nospam.com) wrote:
: I'm encountering trouble with the following Perl code in a CGI when executed
: on Windows NT using IIS 4.0 and Perl for win32 build 316 (Perl 5.003).
: 
:     print "Content-type: image/gif\n\n";
:     open(IMAGE, "$members_dir\\$id\\$id\.gif") or return 0;

Useful secret:  Forward slashes work just fine in paths given as arguments
to system calls, even under DOSish OSes.  Also, backwhacking '.' doesn't
do anything.  So you can rewrite this more legibly as

  open IMAGE, "$members_dir/$id/$id.gif" or return 0;

:     binmode IMAGE;
:     while (<IMAGE>) {
:         print $_;
:     }

It never makes sense to read a binary file using the default value of $/,
which will attempt to read newline-terminated chunks which is a
meaningless or misleading thing to do to a binary file.  Replace the above
with

  binmode IMAGE;
  { local $/; print scalar <IMAGE> }

That is, set "file slurp mode" then use scalar <IMAGE> to get the entire
file as an argument to print.

:     close IMAGE;
: 
: For some reason the above code returns the GIF data with DOS line breaks
: instead of the correct UNIX line breaks. This is the only difference between
: the data returned by a direct browser call to the image and the data returned
: by the script. Naturally, the browser (and Photoshop) cannot decode the
: "DOS'ed" file correctly.

Note that there are no 'line breaks' in a GIF file.  Saying it that way
will only lead you astray.

---------------------------------------------------------------------
   |   Craig Berry - cberry@cinenet.net
 --*--    Home Page: http://www.cinenet.net/users/cberry/home.html
   |      Member of The HTML Writers Guild: http://www.hwg.org/   
       "Every man and every woman is a star."


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

Date: Mon, 20 Jul 1998 23:34:00 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: GIF Line-Breaks in Perl
Message-Id: <MPG.101dd63070a6fcb9989773@nntp.hpl.hp.com>

In article <35B43680.3CD758B8@nospam.com> on Tue, 21 Jul 1998 01:34:42 -
0500, Wesley Miaw <wesley@nospam.com> says...
 ...
> I'm encountering trouble with the following Perl code in a CGI when executed
> on Windows NT using IIS 4.0 and Perl for win32 build 316 (Perl 5.003).
> 
>     print "Content-type: image/gif\n\n";
>     open(IMAGE, "$members_dir\\$id\\$id\.gif") or return 0;
>     binmode IMAGE;
>     while (<IMAGE>) {
>         print $_;
>     }
>     close IMAGE;
> 
> For some reason the above code returns the GIF data with DOS line breaks
> instead of the correct UNIX line breaks. This is the only difference between
> the data returned by a direct browser call to the image and the data returned
> by the script. Naturally, the browser (and Photoshop) cannot decode the
> "DOS'ed" file correctly.

You have to do

binmode STDOUT;

also.  You should do that before the first 'print' statement.
 
> Thanks in advance for any help. I would greatly appreciate a reply via e-mail
> to wesley@woais.com (not the Reply-To in the header) if it's not too much trouble.

It is.

-- 
Larry Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com


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

Date: Tue, 21 Jul 1998 19:45:48 +1000
From: David Coldrick <davidc@selectst.com>
Subject: Re: How to connect to a socket ?
Message-Id: <35B4634C.27D27E92@selectst.com>

Well, so far, there's not much happening on clp.moderated - at least,
after it's been moderated :-)

Jim Brewer wrote:
> 
> Tom Christiansen <tchrist@mox.perl.com> writes:
> 
> > You didn't use the strict pragma.
> > You didn't use the Socket module.
> > You didn't use the -w flag.
> >
> > And I don't think you read the perlipc(1) manpage,
> > which answers this question in exhaustive detail.
> >
> > --tom
> 
> Who cares, you now have clp.moderated. Why are you still here? You got
> what you wanted. Why are you still here? There is no need. You are no
> safe from newbies and morons and idiots. What is your problem? Are you
> going to continue to your diatribes despite the delivered salvation
> you so endlessly pinned for? Why, oh why?
> 
> Jim Brewer,


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

Date: Mon, 20 Jul 1998 22:21:49 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: How to tell if a scalar is a number?
Message-Id: <MPG.101dc548b9c7dfd0989772@nntp.hpl.hp.com>

[Posted to comp.lang.perl.misc; copy mailed to Lloyd Zusman 
<ljz@asfast.com>.]

In article <ltpvezvnvp.fsf@asfast.com> on 21 Jul 1998 00:17:30 -0400, 
Lloyd Zusman <ljz@asfast.com> says...
 ...
>   sub isNumber {
>     my $n = shift;
>     local $noError = 1;
>     local $SIG{__WARN__} = sub { $noError = undef };
>     eval { my $x = $n + 0 };
>     return ($noError);
>   }
> 
> This only works when the `-w' flag is set, by the way.

How about

      local $^W = 1;

in the sub?  (Or, obfuscating a bit, replace $noError by $^W :-)

-- 
Larry Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com


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

Date: 21 Jul 1998 05:05:44 GMT
From: Bob Shair (courtesy) <rmshair@delphi.itg.uiuc.edu>
Subject: Re: Is 3484000000 a negative number ?
Message-Id: <6p17j8$g08$1@vixen.cso.uiuc.edu>

Michael Pavlov <misha@etsd.ml.com> wrote:

> Here is a quick one:

> #!/usr/local/etsd/ged/bin/perl
> $x = 3484000000;
> if ($x < 0 )
>  {
>          print("is negative\n");
>  }
>  else
>  {
>          print("it is pos\n");
>  }
>   
>  $x = 348000;
>   
>  if ($x < 0 )
>  {
>          print("is negative\n");
>  }
>  else
>  {
>          print("it is pos\n");
>  }
>   
>   
>  Produced on machine with perl 5.02
>   
>  is negative
>  it is pos
>   
>  Produced on machine with perl 5.04
>  it is pos
>  it is pos

> Is this a bug ?

Sounds like one to me.  
RS6000	AIX3	4.036	reports pos
RS6000	AIX4	5.003	reports pos
HP9000  HPUX10  5.004   reports pos
PC 	NT4	5.001	reports pos

Where did you get it to say "negative"?

BTW... doesn't look as if perl is limited to 32-bit integers:
   perl -d bigone

Loading DB routines from perl5db.pl version 1
Emacs support available.

Enter h or `h h' for help.

main::(bigone:2):       $x = 3484000000;
  DB<1> n
main::(bigone:3):       if ($x < 0 )
main::(bigone:4):        {
  DB<1> p $x
3484000000
  DB<3> $x++
  DB<4> p $x
3484000001
  DB<5> $x = $x * 2
  DB<6> p $x
6968000002
-- 

Bob Shair                          rmshair@delphi.itg.uiuc.edu
Open Systems Specialist    	   Champaign, Illinois		   
/*  Opinions expressed are mine... go get your own!       */


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

Date: 21 Jul 1998 05:55:22 GMT
From: mjtg@cus.cam.ac.uk (M.J.T. Guy)
Subject: Re: Is 3484000000 a negative number ?
Message-Id: <6p1aga$gil$1@pegasus.csx.cam.ac.uk>

Michael Pavlov  <misha@etsd.ml.com> wrote:
>  
> Produced on machine with perl 5.02
>  
> is negative
> it is pos
>  
> Produced on machine with perl 5.04
> it is pos
> it is pos
>
>Is this a bug ?

Yes.   Perl5.002 is more than two years old.    Many bugs have been
mended, including several security ones.   Upgrade to a current Perl.


Mike Guy


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

Date: 21 Jul 1998 00:22:09 -0500
From: les@MCS.COM (Leslie Mikesell)
Subject: Re: mod_perl on RedHat 5.1
Message-Id: <6p18i1$ahd$1@Venus.mcs.net>

In article <35B34F31.F9F7EB4A@molbio.sbphrd.com>,
Jonathan B. Joseph <josepj00@molbio.sbphrd.com> wrote:
>How can I determine whether mod_perl is really running on the apache web
>server (for RedHat Linux 5.1) ?
>
>I have RedHat 5.1 Linux and want to run mod_perl on the Apache web
>server.  When I listed the apache modules via the command 'httpd -l', I
>didn't see mod_perl listed.  However, I did see the file mod_perl.so in
>the /usr/lib/apache directory.  So I thought that perhaps apache was
>configured to run mod_perl.
>
>I uncommented an entry in the srm.conf apache configuration file:
>
>Add Alias /home/httpd/perl/    /perl/
><Location /perl>
>  SetHandler perl-script
>  PerlHandler   Apache::Registry
>  Options  +ExecCGI
></Location>
>
>I placed a cgi module in the /home/httpd/perl directory and it seemed to
>run okay.  It also ran a little differently, since it displayed on the
>web page, the 'Content-type: text/html' statement I always have to put
>in my cgi.   But did the perl program run under mod_perl or run as a
>regular cgi program ?

If you have the 'printenv' script that is distributed with apache or
some similar script that displays environment variables, 
you will see:
GATEWAY_INTERFACE = CGI/1.1       if you are running normal CGI and:
GATEWAY_INTERFACE = CGI-Perl/1.1  under mod_perl.

 Les Mikesell
  les@mcs.com


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

Date: 21 Jul 1998 05:58:50 GMT
From: Juergen.Puenter@materna.de (J|rgen P|nter)
Subject: Re: open (IN, "foo.txt") works, open (IN, "$foo") does not???
Message-Id: <6p1amq$40p$1@penthesilea.Materna.DE>

In article <emvgwo73.fsf@mailhost.panix.com>, jdf@pobox.com says...
>
>Juergen.Puenter@materna.de (J|rgen P|nter) writes:
>
>Okay, well, you're not going to get very meaningful support when you
>use a very old version of perl.

As I mentioned earlier in this thread, I am stuck with 5.001. Any 
support is welcome, meaningful or not.

>You ought to use CGI.pm.

I wish I could, but it's impossible - stupid management.


>> $path3 = "/a/b/c/this_is_My.fIle.001.001";            # this works
>> 
>> # $path1 = "/a/b/c/";                                 # this does not work
>> # $path2 = "this_is_My.fIle.001.001";
>> # $path3 = $path1.$path2;
>
>That's quite simply impossible. There is no way on earth for any
>entity to tell the difference between the first $path3 and the second.

Yes, this _now_ works (it really didn't last week, believe me) - but see
below for more strangeness.

### This just in ###
Further research - done while writing this - now brings to the light
new and improved errors.

Consider this (only the bare necessities this time):

  $path1 = "../a/b/";
  $path2 = "My_File.is.this";
  $path3 = $path1.$path2;
  print STDERR "\n\n|$path3|\n\n";
  open (FHIN, "<$path3") || die "Can't open '$path3' for read: $!";
  $line = <FHIN>;
  close (FHIN);
  print $line;

This works when called from the WWW. But when I substitute

  $path2 = "My_File.is.this";

with

  $path2 = $datei;

where $datei is input via POST and is equal to "My_File.is.this",
it dies with

  Can't open '../a/b/My_File.is.this' for read: No such file or directory.

even though 

    print STDERR "\n\n|$path3|\n\n";

gives the same output in both cases, i.e. $path3 is exactly the same in
both cases - still it fails in one case and works in the other.

Maybe I'm simply too stupid to see what's going on, but I'm just about
ready to shoot that damn script and be done with it :-(( 


Sorry for being longish, Thanks for your time

	Juergen Puenter



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

Date: 21 Jul 1998 09:28:43 +0200
From: Thomas Neumann <tom@smart.ruhr.de>
Subject: Re: open (IN, "foo.txt") works, open (IN, "$foo") does not???
Message-Id: <m3emvfu0gk.fsf@smart.ruhr.de>

Juergen.Puenter@materna.de (J|rgen P|nter) writes:

[script example deleted]

> This works when called from the WWW. But when I substitute
> 
>   $path2 = "My_File.is.this";
> 
> with
> 
>   $path2 = $datei;
> 
> where $datei is input via POST and is equal to "My_File.is.this",
> it dies with
> 
>   Can't open '../a/b/My_File.is.this' for read: No such file or directory.
> 
> even though 
> 
>     print STDERR "\n\n|$path3|\n\n";
> 
> gives the same output in both cases, i.e. $path3 is exactly the same in
> both cases - still it fails in one case and works in the other.


If $path2 and $datei are not absolute paths (that is, if they
don't start with / ), then it could very well be that upon
execution of your CGI script the working directory is not
what you think it is. Try to figure out the working directory
of CGI scripts when they get exec()'d by your webserver and
make sure your path can work relative to that---or give an absolute
path (the best solution, IMHO).


-t



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

Date: 21 Jul 1998 05:24:38 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Overriding builtin functions
Message-Id: <6p18mm$8j$1@csnews.cs.colorado.edu>

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

In comp.lang.perl.misc, 
    Yary H <yary@apicom.com> writes:
:*{$pack.'::chdir'} = *CORE::print
:causes error "Undefined subroutine &CORE::print called" down the road?

Core functions aren't really in the symbol table.  Hack CORE::AUTOLOAD
to work around.  Carefully.

--tom
-- 
    Even if you aren't in doubt, consider the mental welfare of the person who
    has to maintain the code after you, and who will probably put parens in
    the wrong place.  --Larry Wall in the perl man page 


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

Date: Tue, 21 Jul 1998 13:21:09 +0800
From: Ryan Snowden <ryan@steelplan.com.au>
Subject: Re: Perl for kids
Message-Id: <35B42545.509ACE1A@steelplan.com.au>

Steve Linberg wrote:

> I love Perl -- it *is* the game --, but I'm glad I didn't start with it.
> Plain vanilla C taught me more about programming than anything else,
> because you can't write C without understanding memory, data types, and
> data structures.  Once you know C, you can really appreciate everything
> Perl does for you.  It certainly isn't the easiest place to start, though.

At the wee age of 20, I find it easier to learn Perl than it is to learn C...
Don't ask why.

> for a bit.  Maybe start them in BASIC so they can quickly write programs

I agree with the basic deal..  i started out with line numbers and code on a
commodore 64, then jumped to pascal which is GREAT for structure.  The concept
of variables, and procedures is easier to understand sicne everything is
called...  well, it was for me anyway :)  Now, programming in Perl, only for
about 6 months now mind  you, I'm finding C easier *shrug*.



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

Date: 21 Jul 1998 02:19:21 -0400
From: mjd@op.net (Mark-Jason Dominus)
Subject: Restricting refering domains access to script?
Message-Id: <6p1bt9$s2v$1@monet.op.net>


I was just reading `The American Language', by H.L. Mencken, and the
whole first chapter is about all the awful neologisms and noncewords
which which the Americans mangled the King's English so that the English
sniffed and snorted and said what a bunch of barbarians we were.

Words like `donate', `notify', and `belittle'.

In article <6oq9c0$o3t$1@csnews.cs.colorado.edu>,
Tom Christiansen  <tchrist@mox.perl.com> wrote:
>Alas, there is no such thing as a `refering [sic] domain'!  

There is now!

>The writers of the HTTP docs don't seem to have been able to spell,
>or to spell-check.

There's also a chapter on spelling reform.  Every few years, some
crackpot like Noah Webster would decide that it was time to reform the
spelling, and would campiagn for a bunch of words like `thoro',
`jiraf', `lether', and `biskit'.  And of course none of those ever
caught on, and they all remained idiotic mistakes perpetrated by
illiterates.

Except for `program', `catalog', `jail', `honor', `wagon', `quartet',
`syphon', and a few (dozen) others.  (Puzzle:  Guess the original
spellings.)  

[ Note to puzzled readers: The HTTP standard specifies a header which
  the client may send to communicate the URL of the referring
  document; this header was accidentally spelled `Referer', and so it
  must remain. ]

[ Followups to misc.misc, on the chance that the alt.usage.english
  folks are sick of this disscussion already.]



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

Date: 21 Jul 1998 06:13:07 GMT
From: Juergen.Puenter@materna.de (J|rgen P|nter)
Subject: Re: subscript on numeric
Message-Id: <6p1bhj$40p$2@penthesilea.Materna.DE>

In article <6ovnuc$3a9$1@front3.grolier.fr>, delta@netpage.tm.fr says...
>
>print "\t<option value=\""#ffffff"\"";

Hmm, first you correctly use \", then you immediately trash it all with
another ". Better use: print "\t<option value=\"#ffffff\"";

>if ($fond1 == "#ffffff" ) { print "selected" };

Do you really want numeric comparison here? If not, try string 
comparison like: $fond1 eq "#ffffff".

HTH
	Juergen Puenter



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

Date: 21 Jul 1998 05:14:51 GMT
From: mjtg@cus.cam.ac.uk (M.J.T. Guy)
Subject: Re: temp directory for both unix and windows platform
Message-Id: <6p184b$ft2$1@pegasus.csx.cam.ac.uk>

Anandan Balaji  <balaji@emicx.mentorg.com> wrote:
>Hi,
>
>I am writing some perl scripts, which can run on both unix and
>windows platform. Does any one have solution for how to take
>care /tmp directory in the scripts?

See IO::File::new_tmpfile or POSIX::tmpnam.


Mike Guy


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

Date: 21 Jul 1998 06:00:17 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: What is awk better at than perl? (Larry quote)
Message-Id: <6p1aph$2pu$1@mathserv.mps.ohio-state.edu>

[A complimentary Cc of this posting was sent to Uri Guttman 
<uri@sysarch.com>],
who wrote in article <x7af63nc2e.fsf@sysarch.com>:
> and anyhow ilya (IIRC) has said that this feature will be in 5.005, so
> it is moot about how deep perl will go with $/ being a regex. it will go
> as deep as you tell it to.

Exactly the opposite.

Hope this helps,
Ilya


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

Date: Tue, 21 Jul 1998 00:38:30 -0700
From: Wilson Henriquez <henrwi00@usfca.edu>
Subject: What's wrong?
Message-Id: <35B44576.E2495697@usfca.edu>

    I'm starting to learn perl from Learning Perl(O'reilly), and I am
having trouble.  I'm running Linux and use joe to create a text file
named ex.  In ex I put the following code,
#! /usr/bin/perl
print ("Hello, world!\n");
Then I save the file and do, chmod +x ex.  Next I try to run the
exeecutable file I get the message "print not found".  What am I doing
wrong?



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

Date: 21 Jul 1998 05:43:25 GMT
From: mjtg@cus.cam.ac.uk (M.J.T. Guy)
Subject: Re: Wierd behaviour of .. operator
Message-Id: <6p19pt$gcj$1@pegasus.csx.cam.ac.uk>

Ronald J Kimball <rjk@coos.dartmouth.edu> wrote:
>Richard Proctor <Richard@waveney.demon.co.uk> wrote:
>
>> > > foreach('A1'..'A13') ...
>> 
>> Basicly I think what it did was not what exactly 'right', Perl should either
>> do it 'right' or at least have given a warning that the endpoint was never
>> reached.
>
>And then you've solved the halting problem.  :-)

No, actually.    perlop says

                                       If the final value
     specified is not in the sequence that the magical increment
     would produce, the sequence goes until the next value would
     be longer than the final value specified.

which defines the algorithm: if you get a next value longer than the
final value specified, you will never reach the endpoint.    So it
would be easy to add a warning.

Not sure it's a good idea, though.


Mike Guy


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

Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>


Administrivia:

Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.

If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu. 


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

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