[8896] in Perl-Users-Digest
Perl-Users Digest, Issue: 2514 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed May 6 10:07:22 1998
Date: Wed, 6 May 98 07:02:25 -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 Wed, 6 May 1998 Volume: 8 Number: 2514
Today's topics:
Re: IS THIS POSSIBE IN PERL! <perlguy@inlink.com>
Re: IS THIS POSSIBE IN PERL! <perlguy@inlink.com>
Re: IS THIS POSSIBE IN PERL! (Tina Marie Holmboe)
Re: Localtime--dumb question probably <mpeck@pobox.com>
Re: Localtime--dumb question probably (Hakan Hjelmstrom)
Re: Newbie Q: access file handles in a subroutine? (jgoldberg)
Re: out of memory problem (Dominic Dunlop)
Re: Perl bug(?): do ne eval `cat` <oren@capella.co.il>
Perl on Win95? <gdavis@surveystar.com>
Re: Perl on Win95? (Tina Marie Holmboe)
Problem installing Perl 5.004_04 on Solaris 2.5.1 <mpeck@pobox.com>
Re: problem reading DB_File on win32 platform (robert)
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 6 May 1998 11:09:47 GMT
From: Brent Michalski <perlguy@inlink.com>
Subject: Re: IS THIS POSSIBE IN PERL!
Message-Id: <355044FB.8B9E6934@inlink.com>
Don't blow $750 on a product if you are just looking to do a simple
task. That's like saying "Is driving possible?" and getting a reply of
"Yes, but only if you buy a Ferrari from me"...
If I am not mistaken, there have been articles in WebTechniques and
there are modules which will allow you to do this fairly easily.
Can some of those more familiar with this task lend a hand?
Ken, it looks like you may have a nice product but I know I couldn't
justify spending $750 for a product that just checks links when I can
get something like Web Analyzer for about 1/3 the cost. Good luck.
HTH,
Brent
Ken Churilla wrote:
>
> On 5 May 1998 21:54:44 GMT, capned@itchy.serv.net (Keith Woodman) wrote:
>
> >My company needs to have a program that will go out and check to see if the links we have on
> >pages around the world are still active on those pages.
> >We don't want to have to do it manualy for obvious time reasons.
> >If this is possilbe to write such a program please mail me at the following address
>
> More than possible. It's been done. LinkScan is a perl program
> that does it. Don't recommend you writing it yourself. LinScan
> has thousands of hours of development invested in it.
>
> Our studies show that most websites have significant
> problems. These include up to 30% of the external links
> being broken, missing files, orphaned pages, and faulty
> mailto addresses. Yet most webmasters are blissfully
> unaware that they even have these problems. Why? Because
> they don't regularly check their sites for these problems.
> In fact, in many cases, they have never, ever checked for
> these problems. The reason is it's too time consuming and
> difficult to do manually.
>
> The solution is to use a link validator to test every link
> on your website. LinkScan is the most thorough and fastest
> quality assuarance tool available. It runs on any Unix or
> NT server and with virtually any browser on any platform.
> LinkScan has worked successfully on websites with over 250,000
> pages and more than 50,000 external links. It checks external
> links at a rate exceeding 40,000 links per hour. LinkScan is
> essential to a professionally managed web site, and to those
> that want to just look like they are professionally managed.
> And you don't need to know Unix to run it. It sets up all
> directories and permissions and builds your configuation file
> automatically. Most users have it running in minutes.
>
> You can check your entire website today by downloading a
> free evaluation copy of LinkScan. The file is less than
> 240 KBs so it will only take a few minutes.
>
> Don't get caught with your links down. Don't let your visitors
> think your site sucks! Fix those broken links today. Download
> your free evaluation copy now at:
>
> http://www.elsop.com/linkscan/
>
> Ken Churilla
> President
> Electronic Software Publishing Corporation
------------------------------
Date: Wed, 6 May 1998 11:17:51 GMT
From: Brent Michalski <perlguy@inlink.com>
Subject: Re: IS THIS POSSIBE IN PERL!
Message-Id: <355046DF.1CE1ECD3@inlink.com>
Now that I think about it,
It looks like Ken didn't read the message carefully. This post is
regarding checking to see if distant links are still pointing BACK to
this persons site. NOT for checking the links that are on their site.
I'd hate to see someone spend $750 and find out that the product didn't
work how they needed it to.
Brent
------------------------------
Date: 6 May 1998 11:50:25 GMT
From: tina@scandinaviaonline.se (Tina Marie Holmboe)
Subject: Re: IS THIS POSSIBE IN PERL!
Message-Id: <6ipiq1$em4$1@news1.sol.no>
In article <6io1r4$10e$1@dns2.serv.net>,
capned@itchy.serv.net (Keith Woodman) writes:
> My company needs to have a program that will go out and check to see if the links we have on
> pages around the world are still active on those pages.
It is certainly possible - such a program would, given that you know which
pages you want to check, need to do the following:
a) Download the document in question - there are modules in CPAN for this.
b) Check the source of the same document for any links, and
c) Check these links to see if the one(s) matching your company's
name/profile point to the correct place.
Whilst it isn't a program one write in 10 minutes, it *certainly* isn't
something which need cost huge amounts - the sum $750 which has been mentioned
in the thread is *way* of for something which is in essence a very restricted
web crawler.
If, on the other hand, you *don't* know on which pages you link appear, and
want to check *that* ... well, then the problem is a slightly different beast.
We wouldn't exactly be talking O(n) in that case, to put it mildly.
--
Tina Marie Holmboe
Application Developer (Geeks'R'Us) [tina@tech.scandinaviaonline.se]
Scandinavia Online AB Development Dept. (+46) 08 587 81000 (switchboard)
(+46) 08 587 81189 (direct)
------------------------------
Date: 6 May 1998 07:13:01 -0500
From: Michael Peck <mpeck@pobox.com>
Subject: Re: Localtime--dumb question probably
Message-Id: <3550539D.A0071990@pobox.com>
johnny99@sydney.dialix.oz.au wrote:
>
> I've got
>
> $timesent=localtime;
>
> and then
>
> print (SM $timesent);
>
> but nothing comes out. It doesn't die, it just doesn't do anything.
>
localtime is a function that accepts a optional 'time' parameter, and
returns a list (array) of values. It can be used like this:
($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) =
localtime ;
all values returned are numeric. $mon is in the range 0..11, $wday is
in the range 0..6, and year has had 1900 subtracted from it. Try this:
$year += 1900 ;
$dow = (Sun, Mon, Tue, Wed, Thu, Fri, Sat)[$wday] ;
$month = (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov,
Dec)[$mon] ;
print "$dow, $mon $mday, $year\n" ;
For more info, look in "Programming Perl (The Camel Book), by Larry
Wall, Tom Christiansen, and Randal L. Schwartz, page 185.
By the way, there's also a gmtime function (that works the same way)
that returns the Greenwich Mean Time (GMT).
------------------------------
Date: Wed, 06 May 1998 13:45:22 GMT
From: hawk@algonet.se (Hakan Hjelmstrom)
Subject: Re: Localtime--dumb question probably
Message-Id: <355263b0.82505086@news.algonet.se>
On 6 May 1998 07:13:01 -0500, Michael Peck <mpeck@pobox.com> wrote:
> johnny99@sydney.dialix.oz.au wrote:
> > I've got
> > $timesent=localtime;
> > and then
> > print (SM $timesent);
> > but nothing comes out. It doesn't die, it just doesn't do anything.
> localtime is a function that accepts a optional 'time' parameter, and
> returns a list (array) of values. It can be used like this:
> ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) = localtime ;
<snip>
Yes, but it can be used in a scalar context as well.
"In a scalar context, returns the ctime value:
$now_string = localtime; # e.g., "Thu Oct 13 04:54:34 1994"
The script above should work provided SM is opened in write mode.
Also, I'd leave the filehandle outside the parenthesis but it works
both ways.
If this script were to be run with the -w switch it'd probably
generate a "print on closed filehandle" message.
Hekan Hjelmstrvm
hawk@algonet.se
------------------------------
Date: Wed, 6 May 1998 14:13:06 +0100
From: "Pipex (jgoldberg)" <jgoldberg@dial.pipex.com>
Subject: Re: Newbie Q: access file handles in a subroutine?
Message-Id: <6ipnls$6vg$1@plug.news.pipex.net>
>I think you want to know how to pass and return filehandles (and other
>values) to your subroutine. The perlsub manpage explains that.
Yes - it turns out all you have to do is:
local( *FILEHANDLE, $filename ) = @_;
Obvious in hindsight...
Thanks.
------------------------------
Date: Wed, 6 May 1998 12:52:14 +0000
From: domo@tcp.ip.lu (Dominic Dunlop)
Subject: Re: out of memory problem
Message-Id: <1d8lp4d.dkjgcb184sv0mN@ppp61.vo.lu>
Tom Phoenix <rootbeer@teleport.com> wrote:
> On Tue, 5 May 1998, Brian Wilson wrote:
>
> > I get an 'out of memory!' error while building a scalar with an
> > sprintf().
>
> Well, that may be a bug in perl...
If you decide that it is, please report it using the perlbug program
supplied with Perl.
> > $in_list = sprintf("%s%s,", $in_list, $k);
>
> ...But that's probably not the best way to use Perl, anyway! :-) Try this
> line instead.
>
> $in_list .= "$k,";
Either approach can cause pathological behaviour if perl is using a
malloc() that's bad at coalescing free()d space. What happens is that,
as $in_list grows, a succession of buffers too small to hold it is
free()d. Unless malloc() can coalesce them and so make the space
available for use by the expanded form of $in_list, perl's memory use
balloons.
However, I'm not aware that HP-UX has this problem: on this platform
perl uses its own malloc(), which doesn't waste memory in this
situation. It's on hosts where perl has to use the system's malloc()
that the problem can bite. You get better behaviour on such systems
with something like this:
push(@bits, $stuff) while $more_stuff;
$whole_ball_of_wax = "@bits";
Change a local copy of $" to your preferred separator if you don't like
the default of a space, or consider using join() instead, as Tom
suggested:
>
> Of course, you could probably do what you want with join. Hope this helps!
Finally, you said
>The machine is running HP-UX 10.20 and perl5.004 with lots of memory.
There's a possibility that you can't get at "lots of memory" because
you're being bitten by some memory quota imposed by your system
administrator and/or the shell (although I'd expect you to get some
warning if your program is being shot down for exceeding a quota). But
anyway, see what limit, ulimit or its analogue in your shell has to
say.
--
Dominic Dunlop
------------------------------
Date: Wed, 6 May 1998 14:46:27 +0300
From: "Oren Ben-Kiki" <oren@capella.co.il>
Subject: Re: Perl bug(?): do ne eval `cat`
Message-Id: <6ipiuc$ht6$1@news.netvision.net.il>
>In the Camel book (2nd edition), page 158, "do 'stat.pl'" is said to be
>equivalent to "eval `cat stat.pl`", except for being more efficient (and
>locating the file for you). Well... this turns out NOT to be the case.
>
>If there is a 'die' in 'stat.pl', $EVAL_ERROR ($@) does NOT get set in the
>calling script. This was not fun, since I needed the error string. I ended
>having to prefix each '.pl' script with code to install a '__DIE__'
handler
>which set a global '$DO_ERROR' variable, then called 'die' again. Yuch.
As Tom Phoenix pointed out to me, doing:
eval {
delete($INC{$script});
require($script);
}
Does the trick.
>I tried this on both Win32 and Linux, in different versions of Perl, with
>the same results. Any idea whether this is a bug, a feature, a wart or
what?
>Any chance of it being fixed in a future version?
The question still stands. WHY doesn't a simple 'do' sufficient?
---
Oren Ben-Kiki oren@capella.co.il
"Life is tough and the hard ships are many"
------------------------------
Date: Wed, 06 May 1998 09:16:38 -0700
From: Glenn Davis <gdavis@surveystar.com>
Subject: Perl on Win95?
Message-Id: <35508CE6.485C@surveystar.com>
Is there a Win95 version or Perl? If not, is it possible to run a Perl
installed on a WinNT server from Win95 workstations. Can anyone provide
me some clue of where to start.
Any help would be appreciated.
Thanks,
Glenn
------------------------------
Date: 6 May 1998 13:55:22 GMT
From: tina@scandinaviaonline.se (Tina Marie Holmboe)
Subject: Re: Perl on Win95?
Message-Id: <6ipq4a$gfo$3@news1.sol.no>
In article <35508CE6.485C@surveystar.com>,
Glenn Davis <gdavis@surveystar.com> writes:
> Is there a Win95 version or Perl? If not, is it possible to run a Perl
> installed on a WinNT server from Win95 workstations. Can anyone provide
CPAN, to qoute someone partially famous, is your friend:
http://www.cpan.org/ports/
--
Tina Marie Holmboe
Application Developer (Geeks'R'Us) [tina@tech.scandinaviaonline.se]
Scandinavia Online AB Development Dept. (+46) 08 587 81000 (switchboard)
(+46) 08 587 81189 (direct)
------------------------------
Date: 6 May 1998 06:56:00 -0500
From: Michael Peck <mpeck@pobox.com>
Subject: Problem installing Perl 5.004_04 on Solaris 2.5.1
Message-Id: <35504FCD.B7C4BE7A@pobox.com>
I have freshly installed Solaris 2.5.1 on a Sun Sparc 5. I have also
installed all of the compilers and tools I can think of prior to
installing Perl. When I try to make perl I get the following error
messages:
In file included from pp_sys.c:35:
/usr/local/lib/gcc-lib/sparc-sun-sunos5.5/2.7.2.2/include/netdb.h:66:
sys/bitypes.h: No such file or directory
/usr/local/lib/gcc-lib/sparc-sun-sunos5.5/2.7.2.2/include/netdb.h:68:
sys/cdefs.h: No such file or directory
make: *** [pp_sys.o] Error 1
>From what I've discovered so far, it looks like 'bitypes.h' and
'cdefs.h' are both distributed with BIND 4.9.3. Why does perl require
these when only a nameserver needs to run BIND?
Thanks,
Mike Peck.
mpeck@pobox.com
------------------------------
Date: 6 May 1998 12:18:09 +0200
From: robert@il.fontys.nl (robert)
Subject: Re: problem reading DB_File on win32 platform
Message-Id: <6ipdd1$olh@bsd1.ilse.net>
Hugo ter Doest <terdoest@cs.utwente.nl>:
>Piet van Oostrum wrote:
>> But DB files are binary files, so they should be in principle
>> transportable, without CR/LF problems.
>maybe it's a big/small-endian problem?
It could still be a cr/lf problem, if the keys in the database are
stored including (a) newline character(s). A quick way to find out might
be viewing the DB file with a binary editor/viewer.
robert
------------------------------
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 2514
**************************************
