[10706] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 4305 Volume: 8

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Nov 27 02:07:17 1998

Date: Thu, 26 Nov 98 23:00:18 -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           Thu, 26 Nov 1998     Volume: 8 Number: 4305

Today's topics:
    Re: "ELSE" command in Perl?? (Robin D.F. Silk)
        about upgrading perl version (5.001-->5.005_02) <b333727@mailserv.cuhk.hk>
        Accessing script in cgi-bin <evanp@technologist.com>
    Re: ADODB Problems, sample code inside with fix <lss@shaw.wave.ca>
    Re: ADODB Problems, sample code inside with fix <lss@shaw.wave.ca>
        Can you suggest a(n) URL? <_larryf@micron.net_>
        does perl support Digital UNIX? (GEMINI)
    Re: does perl support Digital UNIX? <rick.delaney@shaw.wave.ca>
        I have a question about Perl and CgI? <rollo@enter.net>
        matching $ with \$ (was Re: Anti-Spam Filter - Difficul <Russell_Schulz@locutus.ofB.ORG>
    Re: netscape bookmark <jim.gillespie@usa.net>
    Re: Perl compiler? (Robin D.F. Silk)
    Re: Perl compiler? (Martien Verbruggen)
        Perl in NT login script quinnrob@my-dejanews.com
        Perl Scripting Error <Webmaster@Freeness.net>
    Re: Stupid question:  Script never terminates? (Abe)
    Re: Stupid question:  Script never terminates? (Abe)
    Re: The dumbest question ever - HELP!!! <wowadmin@northcom.net>
    Re: Why it doesn't work? (Stephen Judd)
        Y2K and Programmer Denial finsol@ts.co.nz
    Re: Y2K and Programmer Denial <rick.delaney@shaw.wave.ca>
    Re: Y2K and Programmer Denial (David Formosa)
        Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)

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

Date: Fri, 27 Nov 98 00:57:35 GMT
From: silk@interlog.com (Robin D.F. Silk)
Subject: Re: "ELSE" command in Perl??
Message-Id: <silk.1262515895E@news.interlog.com>

Try:

if ($web eq "") {
    print "<b>$com</b><br>\n";
}
else {
    print "<a href=\"$web\">$com</a>\n";
}

In Article <slrn75jvk4.5mv.richm@ll.aa2ys.ampr.org>,
richm@ucesucks.mulveyr.roc.servtech.com (Rich) wrote:
>On Mon, 23 Nov 1998 21:53:17 +0100, Jeroen Roeper <lookitsme@cyberspam.com>
wrote:
>>Hi perl wizards,
>>
>>a question, I have a Perl script that displays a flat text database. Now I
>>want to know if there is such thing as the If-Then-Else command such as in
>>VB
>>
>>This is the chunk of code I use now, but it doesn't seem to work, any
>>ideas??
>>
>>   if( $web = "" )
>>   {
>>   print "<b>$com</b><br>";
>>   else
>>   print "<a href=\"$web\">$com</a>";
>>   }
>>
>
>   You might want to look up the difference in syntax between the comparison
>and assignment operators, not to mention the details about which ones to use
>for different datatypes.
>
>- Rich
>
>--
>Rich Mulvey                                         
>My return address is my last name, 
>   followed by my first initial, @mulveyr.roc.servtech.com        
>http://mulveyr.roc.servtech.com
>Amateur Radio: aa2ys@wb2wxq.#wny.ny.usa


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

Date: Fri, 27 Nov 1998 10:30:15 +0800
From: b333727 <b333727@mailserv.cuhk.hk>
Subject: about upgrading perl version (5.001-->5.005_02)
Message-Id: <365E0EB7.2837BF19@mailserv.cuhk.hk>

Hello everyone:
    Would you like to me how to upgrade my perl version to the latest.My
server configuration is like that:
    Server kernel :Linux 1.2.13 (slackware 3.0)
    perl version    :5.001

I have followed the instruction of "build and install guide for perl
5",but it doesn't work.

Would anyone tell me how to upgrade my perl 5 step by step
briefly.Thanks a lot !!


Tom Cheung

27-11-98




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

Date: Thu, 26 Nov 1998 22:28:18 -0500
From: Evan Panagiotopoulos <evanp@technologist.com>
Subject: Accessing script in cgi-bin
Message-Id: <365E1C52.A10415DC@technologist.com>

This is a multi-part message in MIME format.
--------------21A0F92AA1D881765FEA851F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello to all,
I'm processing a form and the perl script resides in cgi-bin directory
of the server. I have the following line:
<form action="http://10.3.3.2/cgi-bin/form.cgi" method="POST">
which doesn't workbecause the script's path is not found.  How do I
access it?  The script is in the cgi-bin directory.

Thanks for the help,

--------------21A0F92AA1D881765FEA851F
Content-Type: text/x-vcard; charset=us-ascii;
 name="evanp.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Evan Panagiotopoulos
Content-Disposition: attachment;
 filename="evanp.vcf"

begin:vcard 
n:Panagiotopoulos;Evan
tel;fax:(914) 457-4056
tel;home:Home Sweet Home
tel;work:Valley Central High School (914) 457-3122
x-mozilla-html:TRUE
org:Valley Central High School;Mathematics Department
adr:;;;;;;
version:2.1
email;internet:evanp@technologist.com
title:Computer Teacher
fn:Evan Panagiotopoulos
end:vcard

--------------21A0F92AA1D881765FEA851F--



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

Date: Fri, 27 Nov 1998 06:06:08 GMT
From: "LSS" <lss@shaw.wave.ca>
Subject: Re: ADODB Problems, sample code inside with fix
Message-Id: <kjr72.65$Y06.34616@news.rdc1.on.wave.home.com>

Solved my own problem.  It seems that I updated ADO components recently but
did not appreciate the impact this might have on error handling with some
database engines.  The behaviour is dependent on the underlying ODBC
components.  The original code below works correctly with older ODBC
drivers.  New drivers return errors as warnings.  I did not expect this
change in the interpretation of what an error is.

The code below is the fix.  We assume that if Win32::OLE::LastError() is
zero, then the reported error, if there is one, is actually a warning.  I
appologize for implying that the Activestate Perl implementors were at
fault.  Their web site ADO sample is broken, but probably for unrelated
reasons.

The fix:

Where the setup is something like:

$dbconnection = 'DBQ=I:\Inventory.mdb;Driver={Microsoft Access Driver
(*.mdb)};Uid=sa;Pwd=;';
dbOpen($Cn1, $Cm1, $Rs1, $dbconnection);
$Cm1->{CommandText} = "SELECT * FROM Items";
$Rs1->Open($Cm1);


sub dbOpen
{
  my($Cn, $Cm, $Rs, $Errors, $LoadName, $retval);

  $LoadName = $_[3];

 $retval = 0;

  $Cn = CreateObject OLE 'ADODB.Connection';

  if ( $Cn )
  {
    $Cn->{ConnectionTimeout} = 15;
    $Cn->{CommandTimeout} = 30;
    $Cm = CreateObject OLE 'ADODB.Command';

    if ( $Cm )
    {
      $Rs = CreateObject OLE 'ADODB.Recordset';

      if ( $Rs )
      {
        $Cn->Open($LoadName, "", "");

        # Some alternatives that I played with thinking the fault was with
the open semantics.
        #$Cn->Open($LoadName);
        #print ">> " . $LoadName;
        #print "\n";
        #$Cn->{ConnectionString} = $LoadName;
        #$Cn->Open();
        #$Cm->{ActiveConnection} = $Cn;

        if ( Win32::OLE::LastError() )
        {
          $Errors = $Cn->Errors();

          $retval = keys %$Errors;

          $retval = 0;
          foreach $item ( keys %$Errors )
          {
            print "$item->{Description}\n"
          }
          SetErrMsg("Unable to open ADO connection.");
        }
        else
        {
          $Cm->{ActiveConnection} = $Cn;
          $Cm->{CommandType} = 1;

          $Rs->{CursorType} = 1;
          $Rs->{LockType} = 3;

          $_[0] = $Cn;
          $_[1] = $Cm;
          $_[2] = $Rs;

          $retval = 1;
        }
      }
      else
      {
        SetErrMsg("Unable to create ADO recordset object.");
      }
    }
    else
    {
      SetErrMsg("Unable to create ADO command object.");
    }
  }
  else
  {
    SetErrMsg("Unable to create ADO connection object.");
  }

  return $retval;
}



>The code below once worked.  As of the merged Win32 perl builds it fails.
>
>sub dbOpen
>{
>  my($Cn, $Cm, $Rs, $Errors, $LoadName, $retval);
>
>  $LoadName = $_[3];
>
>$retval = 0;
>
>  $Cn = CreateObject OLE "ADODB.Connection";
>
>  if ( $Cn )
>  {
>    $Cn->{ConnectionTimeout} = 15;
>    $Cn->{CommandTimeout} = 30;
>    $Cm = CreateObject OLE "ADODB.Command";
>
>    if ( $Cm )
>    {
>      $Rs = CreateObject OLE "ADODB.Recordset";
>
>      if ( $Rs )
>      {
>        $Cn->Open($LoadName, "", "");
>        #print ">> " . $LoadName;
>        #print "\n";
>        #$Cn->{ConnectionString} = $LoadName;
>        #$Cn->Open();
>        #$Cm->{ActiveConnection} = $Cn;
>
>        $Errors = $Cn->Errors();
>
>        $retval = keys %$Errors;
>
>        if ( $retval )
>        {
>          $retval = 0;
>          print "Load Name: $LoadName\n";
>          foreach $item ( keys %$Errors )
>          {
>            print "$item->{Description}\n"
>          }
>          SetErrMsg("Unable to open ADO connection.");
>        }
>        else
>        {
>          $Cm->{ActiveConnection} = $Cn;
>          $Cm->{CommandType} = 1;
>
>          $Rs->{CursorType} = 1;
>          $Rs->{LockType} = 3;
>
>          $_[0] = $Cn;
>          $_[1] = $Cm;
>          $_[2] = $Rs;
>
>          $retval = 1;
>        }
>      }
>      else
>      {
>        SetErrMsg("Unable to create ADO recordset object.");
>      }
>    }
>    else
>    {
>      SetErrMsg("Unable to create ADO command object.");
>    }
>  }
>  else
>  {
>    SetErrMsg("Unable to create ADO connection object.");
>  }
>
>  return $retval;
>}
>
>The jet engine reports:
>[Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed
>
>The failure is during the Open().  Note the commented form of open is
>equivalent.  The Activesate ADO samples on their web site are also broken
>(now).  Their error checking should be as show above.
>
>Any ideas?
>
>
>
>




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

Date: Fri, 27 Nov 1998 06:14:53 GMT
From: "LSS" <lss@shaw.wave.ca>
Subject: Re: ADODB Problems, sample code inside with fix
Message-Id: <xrr72.66$Y06.39816@news.rdc1.on.wave.home.com>

Solved my own problem.  It seems that I updated ADO components recently but
did not appreciate the impact this might have on error handling with some
database engines.  The behaviour is dependent on the underlying ODBC
components.  The original code below works correctly with older ODBC
drivers.  New drivers return errors as warnings.  I did not expect this
change in the interpretation of what an error is.

The code below is the fix.  We assume that if Win32::OLE::LastError() is
zero, then the reported error, if there is one, is actually a warning.  I
appologize for implying that the Activestate Perl implementors were at
fault.  Their web site ADO sample is broken, but probably for unrelated
reasons.

The fix:

Where the setup is something like:

$dbconnection = 'DBQ=I:\Inventory.mdb;Driver={Microsoft Access Driver
(*.mdb)};Uid=sa;Pwd=;';
dbOpen($Cn1, $Cm1, $Rs1, $dbconnection);
$Cm1->{CommandText} = "SELECT * FROM Items";
$Rs1->Open($Cm1);


sub dbOpen
{
  my($Cn, $Cm, $Rs, $Errors, $LoadName, $retval);

  $LoadName = $_[3];

$retval = 0;

  $Cn = CreateObject OLE 'ADODB.Connection';

  if ( $Cn )
  {
    $Cn->{ConnectionTimeout} = 15;
    $Cn->{CommandTimeout} = 30;
    $Cm = CreateObject OLE 'ADODB.Command';

    if ( $Cm )
    {
      $Rs = CreateObject OLE 'ADODB.Recordset';

      if ( $Rs )
      {
        $Cn->Open($LoadName, "", "");

        # Some alternatives that I played with thinking the fault was with
the open semantics.
        #$Cn->Open($LoadName);
        #print ">> " . $LoadName;
        #print "\n";
        #$Cn->{ConnectionString} = $LoadName;
        #$Cn->Open();
        #$Cm->{ActiveConnection} = $Cn;

        if ( Win32::OLE::LastError() )
        {
          $Errors = $Cn->Errors();

          $retval = keys %$Errors;

          $retval = 0;
          foreach $item ( keys %$Errors )
          {
            print "$item->{Description}\n"
          }
          SetErrMsg("Unable to open ADO connection.");
        }
        else
        {
          $Cm->{ActiveConnection} = $Cn;
          $Cm->{CommandType} = 1;

          $Rs->{CursorType} = 1;
          $Rs->{LockType} = 3;

          $_[0] = $Cn;
          $_[1] = $Cm;
          $_[2] = $Rs;

          $retval = 1;
        }
      }
      else
      {
        SetErrMsg("Unable to create ADO recordset object.");
      }
    }
    else
    {
      SetErrMsg("Unable to create ADO command object.");
    }
  }
  else
  {
    SetErrMsg("Unable to create ADO connection object.");
  }

  return $retval;
}



>The code below once worked.  As of the merged Win32 perl builds it fails.
>
>sub dbOpen
>{
>  my($Cn, $Cm, $Rs, $Errors, $LoadName, $retval);
>
>  $LoadName = $_[3];
>
>$retval = 0;
>
>  $Cn = CreateObject OLE "ADODB.Connection";
>
>  if ( $Cn )
>  {
>    $Cn->{ConnectionTimeout} = 15;
>    $Cn->{CommandTimeout} = 30;
>    $Cm = CreateObject OLE "ADODB.Command";
>
>    if ( $Cm )
>    {
>      $Rs = CreateObject OLE "ADODB.Recordset";
>
>      if ( $Rs )
>      {
>        $Cn->Open($LoadName, "", "");
>        #print ">> " . $LoadName;
>        #print "\n";
>        #$Cn->{ConnectionString} = $LoadName;
>        #$Cn->Open();
>        #$Cm->{ActiveConnection} = $Cn;
>
>        $Errors = $Cn->Errors();
>
>        $retval = keys %$Errors;
>
>        if ( $retval )
>        {
>          $retval = 0;
>          print "Load Name: $LoadName\n";
>          foreach $item ( keys %$Errors )
>          {
>            print "$item->{Description}\n"
>          }
>          SetErrMsg("Unable to open ADO connection.");
>        }
>        else
>        {
>          $Cm->{ActiveConnection} = $Cn;
>          $Cm->{CommandType} = 1;
>
>          $Rs->{CursorType} = 1;
>          $Rs->{LockType} = 3;
>
>          $_[0] = $Cn;
>          $_[1] = $Cm;
>          $_[2] = $Rs;
>
>          $retval = 1;
>        }
>      }
>      else
>      {
>        SetErrMsg("Unable to create ADO recordset object.");
>      }
>    }
>    else
>    {
>      SetErrMsg("Unable to create ADO command object.");
>    }
>  }
>  else
>  {
>    SetErrMsg("Unable to create ADO connection object.");
>  }
>
>  return $retval;
>}
>
>The jet engine reports:
>[Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed
>
>The failure is during the Open().  Note the commented form of open is
>equivalent.  The Activesate ADO samples on their web site are also broken
>(now).  Their error checking should be as show above.
>
>Any ideas?
>
>
>
>





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

Date: Thu, 26 Nov 1998 21:44:29 -0700
From: Steve Fullmer <_larryf@micron.net_>
Subject: Can you suggest a(n) URL?
Message-Id: <365E2E2C.1AFA670B@micron.net_>

    Question for Win32 version of Perl:  I have no compiler to setup the
Perl interpreter, so I downloaded one from the web.  Easy enough.  I
installed, used... blah blah blah.  It works fine to run the programs
and spit out the necessary output, but my question is how to access the
PERL program (cgi, .pl, etc) with a web browser.  It runs the program
but spits the output to the COMMAND.COM shell.  Which web sites might
cover this, and explain how to set up my machine to run Perl without
this problem?
    I've read through most of the FAQ that I thought would be relevant,
and a lot on the http://www.perl.com/ and http://www.perl.com/CPAN/
sites.  I may just have overlooked it.

    -Steve Fullmer
    larryf@micron.net (mailto:larryf@micron.net)
    You can reply by email if necessary, but I DO read the newsgroup
often



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

Date: 27 Nov 1998 02:13:37 GMT
From: dennis@info4.csie.nctu.edu.tw (GEMINI)
Subject: does perl support Digital UNIX?
Message-Id: <73l1sh$6pv$1@netnews.csie.NCTU.edu.tw>

hi there,

our company are planning to purchase
a DEC workstation & use Digital UNIX
as the OS. I am wondering if the perl
suuport it? 
thanks.



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

Date: Fri, 27 Nov 1998 02:24:20 GMT
From: Rick Delaney <rick.delaney@shaw.wave.ca>
Subject: Re: does perl support Digital UNIX?
Message-Id: <365E0F08.A4434AA0@shaw.wave.ca>

[posted & mailed]

GEMINI wrote:
> 
> hi there,
> 
> our company are planning to purchase
> a DEC workstation & use Digital UNIX
> as the OS. I am wondering if the perl
> suuport it?
> thanks.

Yes.

http://www.perl.com/CPAN/ports/index.html

-- 
Rick Delaney
rick.delaney@shaw.wave.ca


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

Date: 27 Nov 1998 00:38:08 +0500
From: "Rollo Lawson" <rollo@enter.net>
Subject: I have a question about Perl and CgI?
Message-Id: <01be19c8$9a8c6b80$8410aacc@cory>

I am a newbie to cgi-bin.  I have been studying perl5 for the last week or
so.  I have a network installed in my house and I have a question.  I was
wondering if I could put the script in the perl directory on one machine. 
And on the other machine if I access an html file with a form in it that is
submitted right to the computer with the script on it if it.  Would it 
process the script and show the results.  Or do you need web server
software or something like that to test scripts.  And also is the only way
to interact with cgi 
scripts via the <form> tag or can it be with other html elements.  


Please Help
rollo@enter.net



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

Date: Thu, 26 Nov 1998 22:25:31 -0500
From: Russell Schulz <Russell_Schulz@locutus.ofB.ORG>
Subject: matching $ with \$ (was Re: Anti-Spam Filter - Difficult Pattern Matching Question)
Message-Id: <19981126.222531.9K1.rnr.w164w_-_@locutus.ofB.ORG>

"Scott Brumley" <Scott@Brumley.com> writes:

> I want to do a pattern match on  the common spam flag  "$$$" However
> since the $ character is an special anchor character I am having
> difficulty.  I thought I could use \$\$\$  but it does not seem to
> work either.

in posting this, you HAD to realize people would need more to go on
than just this.  it DOES work when escaped.  for EVERYONE.

so you need to post what you're doing, that doesn't, so we can help.
-- 
Russell_Schulz@locutus.ofB.ORG  Shad 86c


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

Date: 26 Nov 1998 14:43:53 +0000
From: James Gillespie <jim.gillespie@usa.net>
Subject: Re: netscape bookmark
Message-Id: <biiemqqqzth.fsf@usa.net>

Rouslan Zenetl <zr@iname.com> writes:

> being a newbie, my question is, what is the "right" (or the most
> efficient, pretty, correct etc) way to parse netscape bookmark file
> in perl? any ideas? or may be pointers?

    Having had to do this recently, I found it reasonably easy to use
HTML::TreeBuilder.  I can't post the code cos it's proprietary :-(
But I can tell you what I did :-)  This all refers to Netscape 4.05.

    I had to write stuff to manipulate the bookmarks file and leave it
as still readable by Netscape, so I had to alter
HTML::Element::starttag to *not* encode ampersands in attributes -
they would appear as "&amp;" when displayed by Netscape.  And I had to
alter HTML::Parser::parse to allow underscores in attribute names.

    Apart from that, you just have to keep an eye on the nesting,
because end-tags tend to be omitted.  HTML::Treebuilder will parse it,
but the nesting will be a bit odd.

    If there's anyone out there at Netscape/AOL/Mozilla/whatever,
*PLEASE* use real HTML in the bookmarks file in future!  What is the
point of using almost-but-not-quite-HTML?  Are you trying to make life
difficult?

                Jim
--
Jim.Gillespie@     ,'_            I think all women should fancy blokes.
   USA.net        / -.--.    ___  In fact I could be more specific...
+44 171 721 2672 _\_x \__`--'_,-' 
                / /\\    \--'_-\\ 
'94 BYO         \__/ `---'  \__/                               -- marvin


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

Date: Fri, 27 Nov 98 01:08:49 GMT
From: silk@interlog.com (Robin D.F. Silk)
Subject: Re: Perl compiler?
Message-Id: <silk.1262516569F@news.interlog.com>

Perl programs do not need to be compiled -- it is an interpreted language.
You do need to install the perl interpreter which is freely available in a
pre-compiled (binary) form for almost all platforms, or you can download the
source and compile it yourself if you are so inclined.


In Article <365DC826.D6F06D96@studbox.uni-stuttgart.de>, Pete Gilbert
<pkg@studbox.uni-stuttgart.de> wrote:
>Mattjm82 wrote:
>> 
>> Douse Perl need a complier like c++ and other programming languages? If so
>> about how much douse it go for? Thanks alot.
>
>to run perl you need a perl interpreter (which may need a one time
>compilation itself).
>look around at http:/www.cpan.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Robin Silk                      POTS:   (416) 366-2108
35 Church St., Suite 815        e-mail: silk@interlog.com
Toronto, Ontario, M5E 1T3


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

Date: Fri, 27 Nov 1998 01:25:25 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: Perl compiler?
Message-Id: <9cn72.63$tN2.128@nsw.nnrp.telstra.net>

In article <silk.1262516569F@news.interlog.com>,
	silk@interlog.com (Robin D.F. Silk) writes:
> Perl programs do not need to be compiled -- it is an interpreted language.

Check out the following to find out why that statement is not exactly
correct:

# perldoc perlfaq1
[snip]
     Is it a Perl program or a Perl script?

Perl is compiled by perl, internally, and the result of that is
executed. You don't get bytecode output to run again later, but that
does not make perl and interpreter per se.

Martien
-- 
Martien Verbruggen                  | 
Webmaster www.tradingpost.com.au    | For heaven's sake, don't TRY to be
Commercial Dynamics Pty. Ltd.       | cynical. It's perfectly easy to be
NSW, Australia                      | cynical.


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

Date: Fri, 27 Nov 1998 02:44:42 GMT
From: quinnrob@my-dejanews.com
Subject: Perl in NT login script
Message-Id: <73l3mo$33b$1@nnrp1.dejanews.com>

I wanted to run a perl program I've created from a NT login script. The
program will backup files to the server. Currently the only way I think I can
get perl to work, without installing it on each PC, is to attempt to mount a
drive letter to a share on the server containing perl and run the file.
Ideas?

Here's the basic concept in the script:

1. I /d (dismount any previously connected drive letters)
2. I mount all new drives including the drive with Perl
3. I attempt to run Perl -

    g:\winset %path%=g:\perl\bin;
    g:\bin\perl.exe g:\myperl.pl;

In this example I've tried to use the winset utility that comes with 95 to
set the path to the Perl bin directory. When I run the batch file I only get
a "bad command or file name" message.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    


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

Date: Fri, 27 Nov 1998 01:15:42 -0500
From: "Freeness" <Webmaster@Freeness.net>
Subject: Perl Scripting Error
Message-Id: <73lg3u$bln$1@birch.prod.itd.earthlink.net>

Can anyone point out anything wrong with the following script? I have had a
13-hour-long head ache from this... after I type perl -w gotoad.cgi in
telnet it says "syntax error at gotoad.cgi line 15, near ")

open"
Execution of gotoad.cgi aborted due to compilation errors.
--PLEASE HELP!

#!/usr/local/bin/perl
$input = $ENV{'QUERY_STRING'};
@input = split(/&/, $input);
foreach $subinput(@input) {
	($name, $value) = split(/=/, $subinput);
	$name =~ tr/A-Z/a-z/;
	$value =~ tr/A-Z/a-z/;
	$name = $value;
}
$account =~ tr/a-z/A-Z/;
open(DISPLAY, "accounts/$account.txt");
@file = <DISPLAY>;
close(DISPLAY)

open(DKPC, ">accounts/$account.txt");
foreach $line(@file) {
	($advert, $hits) = split(/=/, $line);
	if ($advert eq $ad) {
		print DKPC "$advert=++$hits";
	}
	else {
		print DKPC "$advert=$hits";
	}
}

print "Content-type: text/html\n\n";
print "The Ad: $ad for Account: $account was accounted for";
exit;





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

Date: Fri, 27 Nov 1998 05:02:44 GMT
From: abe@abe.com (Abe)
Subject: Re: Stupid question:  Script never terminates?
Message-Id: <Unq72.1668$eZ4.3567851@news4.atl>

In article <73hieu$nts$1@news.cyberhighway.net>, eln@cyberhighway.net (Erik) wrote:
>[Posted and mailed]

abe@abe.com is a spamfoiler.  I just found out that there really is 
an abe.com and some poor guy named Abe is getting emails that are meant 
for me.  Guess I need a new spamfoiler. :)


>> 
>> sub GetSpecs
>> {
>>   $GotSpecs = 1;
>>   open (SPECS, "<$dir/specs.txt") || &error_notfound;
>>   $lockerror = &LockFile(SPECS);
>
>You really shouldn't worry about locking a file if all you're doing
>is reading from it...particularly if it's only one line.

I wasn't sure about it, and I thought, "Better safe than sorry."  I 
guess not.

>
>>       @Spec = <SPECS>;
>
>Do you _know_ that this is always going to be one line?  If so, just use
>$line = <SPECS>; # slurp the first (and in this case, only) line
>@Specs = split '|',$line;

Thanks.  I knew there had to be a better way to do it than using a 
foreach.

>I'm of the opinion that your server admins are not playing with a full
>deck (doesn't surprise me...most admins these days aren't exactly
>abundantly clued).  I can't immediately see any problem with this
>particular subroutine, unless there's some problems with other
>subroutines that are being called from it.  The foreach thing is messy,
>particularly for only one line (in which case use what I outlined above
>instead).  If it's ever more than one line, you'll have problems,
>since your variables will only contain information from the last line
>read.

It will always be one line.

>I would suggest, for debugging purposes, opening up a log file and
>printing out the variable names and values into that file immediately
>after each one is assigned, in case it's locking up in one of those
>other subroutines that are being called in the variable assignments.
>
>Another theory, although not necessarily likely, is that since that one
>single line is so bleeding long, you're running into buffer size
>limitations.  Some systems limit single buffers to a certain max size,
>although IIRC that limit is rather high in most cases.  However, some of
>those elements look rather large, so it might very well be this.
>To test that, try the script with a smaller subset of information
>contained in that file.  Or, split it into lines (which would make
>it more extensible anyway).

This makes a lot of sense to me.  The lines do tend to be quite 
large.  Problem is, some of the values might be blank.  The one line 
database works because it counts the number of individual elements by 
where the "|" is and not whether there's actually a value there.  Is it 
possible to split it into lines and still have it read the values 
properly?  I can create a blank line with print "\n"; but when I use a 
foreach to read the file, will it skip the blank lines or will it 
correctly read a value of nothing into the current variable?

>So where does the script actually print things out?  At the end?  What
>code (if any) is executed after the stuff that you're seeing is
>printed out?  Is the script in a "run" or "sleep" state for those 4 hours,
>or is it a zombie?

It prints out an HTML file to the screen(but not to disk) that is highly 
customized based upon the values entered.  It doesn't actually do 
anything after the HTML file is printed.  It does all the customizations 
correctly, so I'm stumped as to why that subroutine continues to run.


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

Date: Fri, 27 Nov 1998 06:39:18 GMT
From: abe@abe.com (Abe)
Subject: Re: Stupid question:  Script never terminates?
Message-Id: <qOr72.1678$eZ4.3614740@news4.atl>

Never mind.  I feel so damn stupid now that I see what I did.  Sub 
error_notfound called sub Header which called sub GetSpecs which called 
sub error_notfound, etc.  There's the endless loop.  Newbie mistake I 
guess.  Yikes.

Thanks to everyone for all the advice.


In article <Unq72.1668$eZ4.3567851@news4.atl>, abe@abe.com (Abe) wrote:
>In article <73hieu$nts$1@news.cyberhighway.net>, eln@cyberhighway.net (Erik)
> wrote:
>>[Posted and mailed]
>
>abe@abe.com is a spamfoiler.  I just found out that there really is 
>an abe.com and some poor guy named Abe is getting emails that are meant 
>for me.  Guess I need a new spamfoiler. :)
>
>
>>> 
>>> sub GetSpecs
>>> {
>>>   $GotSpecs = 1;
>>>   open (SPECS, "<$dir/specs.txt") || &error_notfound;
>>>   $lockerror = &LockFile(SPECS);
>>
>>You really shouldn't worry about locking a file if all you're doing
>>is reading from it...particularly if it's only one line.
>
>I wasn't sure about it, and I thought, "Better safe than sorry."  I 
>guess not.
>
>>
>>>       @Spec = <SPECS>;
>>
>>Do you _know_ that this is always going to be one line?  If so, just use
>>$line = <SPECS>; # slurp the first (and in this case, only) line
>>@Specs = split '|',$line;
>
>Thanks.  I knew there had to be a better way to do it than using a 
>foreach.
>
>>I'm of the opinion that your server admins are not playing with a full
>>deck (doesn't surprise me...most admins these days aren't exactly
>>abundantly clued).  I can't immediately see any problem with this
>>particular subroutine, unless there's some problems with other
>>subroutines that are being called from it.  The foreach thing is messy,
>>particularly for only one line (in which case use what I outlined above
>>instead).  If it's ever more than one line, you'll have problems,
>>since your variables will only contain information from the last line
>>read.
>
>It will always be one line.
>
>>I would suggest, for debugging purposes, opening up a log file and
>>printing out the variable names and values into that file immediately
>>after each one is assigned, in case it's locking up in one of those
>>other subroutines that are being called in the variable assignments.
>>
>>Another theory, although not necessarily likely, is that since that one
>>single line is so bleeding long, you're running into buffer size
>>limitations.  Some systems limit single buffers to a certain max size,
>>although IIRC that limit is rather high in most cases.  However, some of
>>those elements look rather large, so it might very well be this.
>>To test that, try the script with a smaller subset of information
>>contained in that file.  Or, split it into lines (which would make
>>it more extensible anyway).
>
>This makes a lot of sense to me.  The lines do tend to be quite 
>large.  Problem is, some of the values might be blank.  The one line 
>database works because it counts the number of individual elements by 
>where the "|" is and not whether there's actually a value there.  Is it 
>possible to split it into lines and still have it read the values 
>properly?  I can create a blank line with print "\n"; but when I use a 
>foreach to read the file, will it skip the blank lines or will it 
>correctly read a value of nothing into the current variable?
>
>>So where does the script actually print things out?  At the end?  What
>>code (if any) is executed after the stuff that you're seeing is
>>printed out?  Is the script in a "run" or "sleep" state for those 4 hours,
>>or is it a zombie?
>
>It prints out an HTML file to the screen(but not to disk) that is highly 
>customized based upon the values entered.  It doesn't actually do 
>anything after the HTML file is printed.  It does all the customizations 
>correctly, so I'm stumped as to why that subroutine continues to run.


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

Date: Thu, 26 Nov 1998 22:51:48 -0500
From: "Mark W." <wowadmin@northcom.net>
Subject: Re: The dumbest question ever - HELP!!!
Message-Id: <365E21D4.702FBD46@northcom.net>

Thanks all this newbie found it quite informative:)

And ill get that editor.


Mark



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

Date: Fri, 27 Nov 1998 14:57:25 +1300
From: stephen@waikato.ac.nz (Stephen Judd)
Subject: Re: Why it doesn't work?
Message-Id: <stephen-ya023580002711981457250001@news.waikato.ac.nz>

In article <365CBBA6.A50CF214@aol.com>, Ryuji Yokoyama <ryujiy@aol.com> wrote:

>I am a newbie and have a question.  I wrote following code as my
>practice.  It supposed to read a file and store into array.  Then print
>out the array.  However,
>it prints out only even line number of  contents of the file except the
>last line.

<snip>

This is happening because of the way you are using the file input <> operator.

<FOO> returns a line _and_ advances to the next line of the file.

Here's your code:

while(<IN1>) { # this reads a line from IN1, stores it in $_, and advances
               # to the next line
    $in_val = <IN1>; # this reads the _next_ line and stores it in $in_val
                     # that's why you are only getting the even-numbered lines
      (...)

}

Personally, I would have written:

while (<IN>) {
   chomp;         # for most purposes it's handy to strip the newline off
   push @temp, $_;   
}

<snip>

>Before the while loop is executed, "$len = $#temp;"  statement is
<snip>
>      $len = $#temp;
>      for($i = 0; $i < $len; $i++)
>      {
>        print $temp[$i];
>        print "\n";
>    }
>close(IN1);

A more usual way to write this would be to use foreach:

foreach $line(@temp) {
   print $line, "\n";
}

Regards

Stephen

-- 
Stephen Judd                       |   Warning! I have a greater
Interactive Media Consultant       | than average number of legs. 
Campus Media                       |         Want my PGP key?
University of Waikato, New Zealand |  http://stephen.its.waikato.ac.nz/ 


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

Date: Fri, 27 Nov 1998 01:30:37 GMT
From: finsol@ts.co.nz
Subject: Y2K and Programmer Denial
Message-Id: <73kvbt$vjb$1@nnrp1.dejanews.com>



Recent debate on this and other programming newsgroups, regarding Y2K issues,
has prompted me to write on the subject of programmer denial. This article was
recently published in NZ Computerworld.

Many of you following the debate may be interested in reading further on the
subject discussed.  My first article was on 'booby trap code', a problem that
affects programming languages such as Perl, MacPerl, C, C++, Java,
Javascript, CGI, MVS and CICS.	The second article describes the widespread
programmer denial that I encountered.  Initially, this denial was provoked by
my research into the subject and then, later, further debate arose when my
"booby trap code" article was published.

For those interested, links to these articles can be found at URL:
http://www.ts.co.nz/~finsol/y2k_articles.htm

Regards
Jocelyn Amon

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    


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

Date: Fri, 27 Nov 1998 02:19:43 GMT
From: Rick Delaney <rick.delaney@shaw.wave.ca>
Subject: Re: Y2K and Programmer Denial
Message-Id: <365E0DE1.63C613B9@shaw.wave.ca>

finsol@ts.co.nz wrote:
> 
> The second article describes the widespread
> programmer denial that I encountered.

>From _Programmer denial threatens Y2K projects_ by Jocelyn Amon:

    If these commentators have nothing constructive to offer, the 
    sensible thing to do is move on and not add to the general noise 
    level. However, like a grisly traffic accident they are compelled to
    look again and again at the carnage. 

I must confess that I couldn't resist looking at the twisted wreckage
and I am very ashamed.  It would, however, be nice if there weren't so
many accidents to look at on this highway.

Please take your own advice and stop adding to the general noise level
here.  That article had nothing constructive to offer.

Good luck with your crusade in the appropriate fora.

-- 
Rick Delaney
rick.delaney@shaw.wave.ca


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

Date: 27 Nov 1998 03:28:46 GMT
From: dformosa@zeta.org.au (David Formosa)
Subject: Re: Y2K and Programmer Denial
Message-Id: <slrn75s73f.d58.dformosa@godzilla.zeta.org.au>

In article <73kvbt$vjb$1@nnrp1.dejanews.com>, finsol@ts.co.nz wrote:

>	The second article describes the widespread
>programmer denial that I encountered.  Initially, this denial was provoked by
>my research into the subject and then, later, further debate arose when my
>"booby trap code" article was published.

In your web page you say 

]If I hadn't received several emails confirming that the "booby-trap
]code" is, in fact, very prevalent,

Isn't this a "lurkers support me in email" type of stament.
Inpossable to confurm because the infomation isn't public?

In responce to your comments in "Y2K not wanted here" the Y2K was a
FAQ, previously discussed.  It was not on topic because it had
previously been done to death.


-- 
Please excuse my spelling as I suffer from agraphia. See
http://www.zeta.org.au/~dformosa/Spelling.html to find out more.



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

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

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