[15741] in Perl-Users-Digest
Perl-Users Digest, Issue: 3154 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed May 24 21:06:47 2000
Date: Wed, 24 May 2000 18:05:16 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <959216715-v9-i3154@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Wed, 24 May 2000 Volume: 9 Number: 3154
Today's topics:
Re: @anything = <STDIN> has a problem on win98 systems <kiera@nnickee.com>
Re: @anything = <STDIN> has a problem on win98 systems <rootbeer@redcat.com>
@anything = <STDIN> has a problem on win98 systems (min <kiera@nnickee.com>
Re: @anything = <STDIN> has a problem on win98 systems <rootbeer@redcat.com>
Re: [LWP] Requesting from the clients' IP, not the serv (John Stanley)
Re: [LWP] Requesting from the clients' IP, not the serv <charles.henry@engineer2k.com>
Re: [LWP] Requesting from the clients' IP, not the serv (John Stanley)
Re: array within array revisited <r28629@email.sps.mot.com>
Calling another perl script to run in the background baeron@my-deja.com
Re: Calling another perl script to run in the backgroun (Clinton A. Pierce)
Re: Calling another perl script to run in the backgroun <zapcs@icon.co.za>
Re: Can't Knit Two Files Together <godzilla@stomp.stomp.tokyo>
Re: Can't Knit Two Files Together <godzilla@stomp.stomp.tokyo>
Re: Can't Knit Two Files Together (Gwyn Judd)
Re: Can't Knit Two Files Together <rootbeer@redcat.com>
Re: Can't Knit Two Files Together <godzilla@stomp.stomp.tokyo>
daemon programming (Markus Svilans)
Re: daemon programming <makarand_kulkarni@My-Deja.com>
Re: daemon programming <rootbeer@redcat.com>
Re: daemon programming (Colin Watson)
debugging perl in win2000 (Patrick Erler)
Re: debugging perl in win2000 <zapcs@icon.co.za>
Re: Finding IP addresses+ (Dave Vandervies)
Re: Finding IP addresses+ (Ben Smithurst)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 24 May 2000 19:40:57 -0500
From: Kiera <kiera@nnickee.com>
Subject: Re: @anything = <STDIN> has a problem on win98 systems (mine at least)
Message-Id: <F68FE4760285DC7A.38ACBBFB58C49DCE.B7FDFAE0232D6762@lp.airnews.net>
On Wed, 24 May 2000 17:15:28 -0700, someone claiming to be Tom Phoenix
<rootbeer@redcat.com> said:
>On Wed, 24 May 2000, Kiera wrote:
>> Subject: @anything = <STDIN> has a problem on win98 systems (mine at least)
>Are you following victim to the bug in Windows console I/O where (I'm
>told) the user doesn't get the first line of output after pressing Ctrl-Z?
>If that's it, try adding a "throwaway" line of output before your real
>output if you're going to have the user's input run to end-of-file.
I'm not sure I understand... like this?
chomp(@words = <STDIN>);
foreach $word (@words) {
$count{word} = $count{$word}++;
}
print "throwaway line\n";
foreach $word (keys %count) {
print "$word was seen $count{$word} times\n";
}
E:\>perl chap5b.pl
one
two
three
three
three
three was seen 3 times
two was seen 1 times
one was seen 1 times
word was seen 2 times
(again, where did it see "word" ???)
Even more puzzling:
E:\>perl chap5b.pl
word
word
word
word was seen 0 times
>Good luck with it!
thanx :)
Kiera
------------------------------
Date: Wed, 24 May 2000 17:55:46 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: @anything = <STDIN> has a problem on win98 systems (mine at least)
Message-Id: <Pine.GSO.4.10.10005241752130.14618-100000@user2.teleport.com>
On Wed, 24 May 2000, Kiera wrote:
> I'm not sure I understand... like this?
You're close. :-)
> $count{word} = $count{$word}++;
That line isn't doing what you want, in two different ways.
> (again, where did it see "word" ???)
Does that give you a clue about the line above? (I'm not trying to be mean
by withholding the answer; this is homework you're doing, after all. :-)
If you're still stuck, of course, you'll be welcome to ask again. Cheers!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Wed, 24 May 2000 18:38:01 -0500
From: Kiera <kiera@nnickee.com>
Subject: @anything = <STDIN> has a problem on win98 systems (mine at least)
Message-Id: <4B09DDD64C54AFC7.ADCE5F2D24F297ED.56E4C372B718E01E@lp.airnews.net>
Ok, ran into another problem while doing the exercises in "Learning
Perl on Win32 Systems".
Chapter 5 - Hashes
Exercise 2:
Write a program that reads a series of words with one word per line
until end-of-file, then prints a summary of how many times each word
was seen.
Once again, when my own trials didn't produce the correct results, I
copied straight from the answer page:
chomp(@words = <STDIN>); # read the words, minus newlines
foreach $word (@words) {
$count{word} = $count{$word}++;
}
foreach $word (keys %count) {
print "$word was seen $count{$word} times\n";
}
Now, just so there isn't any confusion (like last time :), when I run
this in the command window:
E:\>perl chap5b.pl
one
two
three
three
(( I hit the ctrl-z *after* I hit Enter after the second "three" and I
get the following output)
two was seen 1 times
one was seen 1 times
word was seen 1 times
*word* was seen 1 times? what happened to the word "three"? I never
entered the word "word" <scratching head>
Doesn't matter whether I enter the threes first, last, or mixed in
between the one(s) and two(s) -- it still ignores them in the output.
If I add a print "\n"; above the second foreach, I get the following
output:
three was seen 2 times
two was seen 1 times
one was seen 1 times
word was seen 1 times
So, now it's getting my threes, but it's still throwing "word" in
there as well. And it's not actually printing a visible blank line
into the console (try it on a win98 system and you'll see what I
mean).
I'm willing to bet that this isn't a problem on NT (just as the
previous one wasn't a problem on NT) --
So now I need to ask a question or two, right?
To whom should I report this behavior?
Microsoft? HA! Like I really believe they'd care enough to do
anything about it :)
ActiveState? (I have seen their bug database, so I suppose that would
be the proper route for reporting this to them)
O'Reilly? (so mention of it can be made in any revisions to the book?
-- well, I know for a fact that at least one of the authors of the
book does read this group, so in a sense I guess I've already reported
it, but should I make an "official" report of it to O'Reilly?)
TIA
Kiera
... still wondering how she got to be the first one to notice this
behavior (and still searching docs to see if anyone else actually has
noticed it before)
------------------------------
Date: Wed, 24 May 2000 17:15:28 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: @anything = <STDIN> has a problem on win98 systems (mine at least)
Message-Id: <Pine.GSO.4.10.10005241712510.14618-100000@user2.teleport.com>
On Wed, 24 May 2000, Kiera wrote:
> Subject: @anything = <STDIN> has a problem on win98 systems (mine at least)
Are you following victim to the bug in Windows console I/O where (I'm
told) the user doesn't get the first line of output after pressing Ctrl-Z?
If that's it, try adding a "throwaway" line of output before your real
output if you're going to have the user's input run to end-of-file.
Good luck with it!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: 24 May 2000 22:22:32 GMT
From: stanley@skyking.OCE.ORST.EDU (John Stanley)
Subject: Re: [LWP] Requesting from the clients' IP, not the server's
Message-Id: <8ghkn8$345$1@news.NERO.NET>
In article <8gh9ni$1stg$1@news4.isdnet.net>,
Charles Henry <charles.henry@engineer2k.com> wrote:
>If geturl.pl was :
>#-- geturl.pl
>print "Location: http://www.url.com\n\n";
>#-- _END_
>
>It would've used the IP of the person who accessed the script, even though
No, in this example, geturl.pl uses no IP address at all. It doesn't use
the address of the client, it doesn't use the address of the server. It
cares not a whit about the IP address, and in fact, it does no IP at
all.
------------------------------
Date: Thu, 25 May 2000 02:00:19 +0200
From: "Charles Henry" <charles.henry@engineer2k.com>
Subject: Re: [LWP] Requesting from the clients' IP, not the server's
Message-Id: <8ghqf9$2aaj$1@news4.isdnet.net>
> >If geturl.pl was :
> >#-- geturl.pl
> >print "Location: http://www.url.com\n\n";
> >#-- _END_
> >
> >It would've used the IP of the person who accessed the script, even
though
>
> No, in this example, geturl.pl uses no IP address at all. It doesn't use
> the address of the client, it doesn't use the address of the server. It
> cares not a whit about the IP address, and in fact, it does no IP at
> all.
Thanks for the incredibly useful answer!
*sigh*
------------------------------
Date: 25 May 2000 00:13:35 GMT
From: stanley@skyking.OCE.ORST.EDU (John Stanley)
Subject: Re: [LWP] Requesting from the clients' IP, not the server's
Message-Id: <8ghr7f$5di$1@news.NERO.NET>
In article <8ghqf9$2aaj$1@news4.isdnet.net>,
Charles Henry <charles.henry@engineer2k.com> wrote:
>> >It would've used the IP of the person who accessed the script, even
>though
>>
>> No, in this example, geturl.pl uses no IP address at all. It doesn't use
>> the address of the client, it doesn't use the address of the server. It
>> cares not a whit about the IP address, and in fact, it does no IP at
>> all.
>
>Thanks for the incredibly useful answer!
Thanks for the incredibly perl-relevant question. Sigh.
I wasn't answering a question just then, I was correcting an erronious
statement you made, BTW. The answer to your question as you asked it is
"you cannot do that, because you would not get any data back from the
GET, and you would have nothing to return to the original client." I'm
sorry you don't find that a useful answer. Ask somewhere else next time.
------------------------------
Date: Thu, 25 May 2000 08:19:55 +0800
From: Tk Soh <r28629@email.sps.mot.com>
Subject: Re: array within array revisited
Message-Id: <392C71AB.E5C530E4@email.sps.mot.com>
Alex Rhomberg wrote:
>
> Tk Soh wrote:
>
> > Spraying a bunch of print statements in the program for debugging
> > purpose is hardly a good programming practice, and that already assumes
> > you remember to clean them up after they did their job.
> >
> > Perl already has a pretty good debugging tool, use it:
> >
> > perldoc perldebug
>
> Don't underestimate the debugging power of a print statement.
> I have encountered enough situations where it was the best tool
> available
I have frequently applied this technique myself too, but only on the
environment/languages where debugging support is poor. With Perl, I find
little or no need for this, except on the yet-to-be-formalized 'perl
-MThread', which has no direct support from perldebug yet, to my
knowledge.
If you really can do nothing but print, then you should look at
Data::Dumper. Unless you are so eager to meet the challenge to 'print'
complex Perl data structures. Using Data::Dumper is one of my debugging
techniques, not 'prints' :-)
One thing I noticed is that a lot of 'programmers', usually the new
ones, pay little attention to debugging tools/facilities/techniques,
hence resort to the excessive use of prints, which appeared to be the
'easiest' thing to do (or learn?) <sigh>
TK
------------------------------
Date: Wed, 24 May 2000 22:59:33 GMT
From: baeron@my-deja.com
Subject: Calling another perl script to run in the background
Message-Id: <8ghmsc$3ic$1@nnrp1.deja.com>
Okay- I've got a problem I'm hoping someone here can help me with.
Hopefully I'll be able to explain it usefully without posting all me
source as it's kind of a convoluted system.
I've got a Perl script that has a very long runtime- it needs about 15-
20 minutes to complete because it has to dial out and retrieve files
via a modem.
The way I'm setting this up is as follows-
1. The user makes a selection from a web page
2. The user's selection is passed (via http POST) to a perl "wrapper"
script which isolated what it needs from the data posted to it.
3. the perl "wrapper" uses the data submitted in step two to start the
main script (the long one that involves the modem dial-out) as a
background process
4. After starting the main script, the wrapper will forward the user to
a status page which is built over time with the output from the main
script. The status page is built to refresh every 5 seconds so the user
can monitor the progress of the main script.
My problem with the process is that I can't get the wrapper script to
successfully transfer to the status page after starting the main
script. It won't transfer to the status page until after the main
script is finished running, and the browser will time out long before
then
print "Content-type: text/html\n\n";
print "<HTML>\n";
print "<meta http-equiv=\"REFRESH\" content=\"3;URL=http://server.brown-
cole.com/new_status.html\">\n";
print "Action submitted: loading status page\n";
print "</html>\n";
exec("/appl/apache/cgi-bin/reconcile/mainscript.cgi $filename &");
This is a sample of what appears directly in the wrapper. I output an
html page which should refresh into the status page after 3 seconds,
and then I run the main script.
If additional details are needed, I'll gladly provide them.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 24 May 2000 23:27:53 GMT
From: clintp@geeksalad.org (Clinton A. Pierce)
Subject: Re: Calling another perl script to run in the background
Message-Id: <ZzZW4.86787$h01.627519@news1.rdc1.mi.home.com>
[Posted and mailed]
In article <8ghmsc$3ic$1@nnrp1.deja.com>,
baeron@my-deja.com writes:
>[long explanation of why deleted...followed by:]
>
> print "Content-type: text/html\n\n";
> print "<HTML>\n";
> print "<meta http-equiv=\"REFRESH\" content=\"3;URL=http://server.brown-
> cole.com/new_status.html\">\n";
> print "Action submitted: loading status page\n";
> print "</html>\n";
>
> exec("/appl/apache/cgi-bin/reconcile/mainscript.cgi $filename &");
>
> This is a sample of what appears directly in the wrapper. I output an
> html page which should refresh into the status page after 3 seconds,
> and then I run the main script.
> If additional details are needed, I'll gladly provide them.
Just because the browser sees a </html> tag doesn't necessarily mean the
page is done loading. At least not any browser I've ever seen. It ain't
over till the socket gets closed.
So you wander off, exec() your new process...which is still connected via
the same socket as your original CGI program. And the browser is sitting
at the other end of the socket waiting for mainscript.cgi to emit
more web-type stuff. Unix works like that, bud. It's a feature.
What you need to do is to disassociate the second process from the
first (closing filehandles, etc..). Read in the FAQ in section 8 under the
question "How do I fork a daemon process?" for starters.
--
Clinton A. Pierce Teach Yourself Perl in 24 Hours!
clintp@geeksalad.org for details see http://www.geeksalad.org
"If you rush a Miracle Man,
you get rotten Miracles." --Miracle Max, The Princess Bride
------------------------------
Date: Thu, 25 May 2000 01:28:55 +0200
From: Zak McGregor <zapcs@icon.co.za>
Subject: Re: Calling another perl script to run in the background
Message-Id: <392C65B7.C6CA5F98@icon.co.za>
baeron@my-deja.com wrote:
[snip]
> My problem with the process is that I can't get the wrapper script to
> successfully transfer to the status page after starting the main
> script. It won't transfer to the status page until after the main
> script is finished running, and the browser will time out long before
> then
>
> print "Content-type: text/html\n\n";
> print "<HTML>\n";
> print "<meta http-equiv=\"REFRESH\" content=\"3;URL=http://server.brown-
> cole.com/new_status.html\">\n";
> print "Action submitted: loading status page\n";
> print "</html>\n";
>
> exec("/appl/apache/cgi-bin/reconcile/mainscript.cgi $filename &");
>
> This is a sample of what appears directly in the wrapper. I output an
> html page which should refresh into the status page after 3 seconds,
> and then I run the main script.
> If additional details are needed, I'll gladly provide them.
I think what will help is if you send a Content-length: header to the
browser.
You may need to make the script an nph script though, but check it out
first.
You may want to consider using print <<"__TAG__";
<HTML>
<META.... etc... etc...
__TAG__
Alternatively, try fork() ing the script, if your OS supports it.
HTH
Cheers
--
====================================================================
Zak McGregor
http://www.zap.co.za/zgas - On-line specifications of over 6700 cars
====================================================================
------------------------------
Date: Wed, 24 May 2000 15:49:32 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Can't Knit Two Files Together
Message-Id: <392C5C7C.2F4554CB@stomp.stomp.tokyo>
Larry Rosler wrote:
> > Elisa Roselli <e.roselli@volusoft.com> says...
> > a_traduire.exp look like:
> > 01ABS02|fr|80|Code client inexistant.||||||
> > 01ABS03|fr|80|Devis client inexistant.||||||
> > 01ABS04|fr|80|Client correspondant à la racine inexistant.|3|C||||
> > And I want that to look like:
> > 01ABS02|en|80|Customer Code does not exist.||||||
> > 01ABS03|en|80|Customer Estimate does not exist.||||||
> > 01ABS04|en|80|Customer corresponding to root does not exist.|3|C||||
> #!/usr/bin/perl -w
> use strict;
> chomp(my $lang_var = <STDIN>); # What's with the studlyCaps?
> open ENGFILE, 'extractEng.txt' or die "Je ne peux pas ouvrir: $!";
> open SAMFILE, 'a_traduire.exp' or die "Je ne peux pas ouvrir: $!";
> open OUT, '>traduit2.txt' or die "Je ne peux pas ouvrir: $!";
> while (<SAMFILE>) {
> my @sam = split /\|/, $_, 5;
> $sam[1] = $lang_var;
> chomp($sam[3] = <ENGFILE>); # This reads one line only.
> print OUT join '|' => @sam;
> }
> Bonne chance!
Have you tested your code to discover
if it works right? I have.
Godzilla!
------------------------------
Date: Wed, 24 May 2000 16:02:06 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Can't Knit Two Files Together
Message-Id: <392C5F6E.5FCCBCBA@stomp.stomp.tokyo>
Larry Rosler wrote:
> Caveats for the unwary:
> Do not consider tests for failure to open files
> to be optional.
Programmers may write any style of error
checking which suits them. There is no
rule nor reason why programmers must
do it your way. You are not Perl God.
> Do not slurp entire files into arrays when line-at-a-time
> processing will suffice.
Really. Some tech articles disagree with this.
Why not Mr. Rosler? You have offered no explanation.
No comparisons.
> Do not chomp the endings off lines if you are only
> going to put them back on immediately.
This destroys the output print. Bad mistake on your part.
You should test code before making a critique, especially
your own code Mr. Rosler. You would be surprised how much
of your code you post, does not work correctly. I test it.
You appear not to test at all or are oblivious to errors
in your code.
Code I post _always_ does what I indicate it will do.
I make it a point to test my code, exhaustively, before
posting lest I post bad code and brag on it, then find
I posted bad code, to my shame and embarrassment. Seems
this recently happened with another "expert" here, who
critiques others for not testing their code and, makes
up lame excuses for his posting untested bad code.
Godzilla!
------------------------------
Date: Wed, 24 May 2000 23:32:58 GMT
From: tjla@guvfybir.qlaqaf.bet (Gwyn Judd)
Subject: Re: Can't Knit Two Files Together
Message-Id: <slrn8ire5b.c6l.tjla@thislove.dyndns.org>
I was shocked! How could Godzilla! <godzilla@stomp.stomp.tokyo>
say such a terrible thing:
>> 01ABS02|fr|80|Code client inexistant.||||||
>> 01ABS03|fr|80|Devis client inexistant.||||||
>> 01ABS04|fr|80|Client correspondant à la racine inexistant.|3|C||||
>
>> And I want that to look like:
>
>> 01ABS02|en|80|Customer Code does not exist.||||||
>> 01ABS03|en|80|Customer Estimate does not exist.||||||
>> 01ABS04|en|80|Customer corresponding to root does not exist.|3|C||||
I took the effort to critique your script here. I hope you don't mind.
>#!/usr/local/bin/perl
Why no "-w" flag here? It seems to me that using that will offer you
some assistance with possible errors?
>print "Content-Type:text/plain\n\n";
I'm not sure why you have this here since I doubt the person is using
this in a CGI script.
>open (FRENCH, "french.txt"); ## optional die
>@Array = <FRENCH>;
>close (FRENCH);
>
>chomp (@Array);
>
>open (ENGLISH, ">english.txt"); ## optional die
I don't think the "die"'s should be optional. Obviously the script will
die anyway when you try to read from the unopened filehandles if it
fails but using die will point you at the line where it is failing.
Also reading in the whole file into an array seems needlessly wasteful
when you can get away with doing it line by line.
Also I think you have opened the wrong files. It should be:
open(ENGFILE, "extractEng.txt") || die "Je ne peux pas ouvrir: $!";
open(SAMFILE,"a_traduire.exp") || die "Je ne peux pas ouvrir: $!";
open(OUT, ">$curDir/traduit2.txt") || die "Je ne peux pas ouvrir: $!";
while (<SAMFILE>)
{
>foreach $line (@Array)
> {
> print "In French: $line\n";
> $line =~ s/\|fr\|/\|en\|/;
Wouldn't it be better to split the line into fields using something
like:
@fields = split(/\|/, $_, 5);
and then substitute?:
$fields[1] = "en";
> $line =~ s/Code client inexistant/Customer Code does not exist/;
> $line =~ s/Devis client inexistant/Customer Estimate does not exist/;
> $line =~ s/Client correspondant à la racine inexistant/Customer
>corresponding to root does not exist/;
I don't think this is according to specification. The OP wanted the
english strings to be read in from the file given above:
chomp($fields[3] = <ENGFILE>);
That above is assuming the english text corresponds with the lines in
the french text. Maybe if there are a limited number of english strings
it would be better to form a hash of french to english strings by
reading the whole english file in at the start.
Something like umm (assuming a tab delimited file with french then
english text):
while (<ENGFILE>)
{
chomp;
@my_val = split /\t/;
$english_text{$my_val[0]} = $my_val[1];
}
Then you could do this to do the translation:
$fields[3] = $english_text{$fields[3]};
> print ENGLISH "$line\n";
> print "In English: $line\n";
> }
>close (ENGLISH);
>
>exit;
finally:
print OUT join '|', @fields;
}
closing the files and exit()'ing should not be necessary.
Here's the completed version I came up with:
#!/usr/bin/perl -w
open(ENGFILE, "extractEng.txt") || die "Je ne peux pas ouvrir: $!";
while (<ENGFILE>)
{
chomp;
@my_val = split /\t/;
$english_text{$my_val[0]} = $my_val[1];
}
close ENGFILE;
open(SAMFILE,"a_traduire.exp") || die "Je ne peux pas ouvrir: $!";
open(OUT, ">traduit2.txt") || die "Je ne peux pas ouvrir: $!";
while (<SAMFILE>)
{
@fields = split(/\|/, $_, 5);
if ($english_text{$fields[3]})
{
$fields[1] = "en";
$fields[3] = $english_text{$fields[3]};
}
else
{
warn "Je ne puis pas traduire \"$fields[3]\"";
}
print OUT join '|', @fields;
}
--
Gwyn Judd (tjla@guvfybir.qlaqaf.bet)
My return address is rot13'ed
BOFH excuse #333:
A plumber is needed, the network drain is clogged
------------------------------
Date: Wed, 24 May 2000 17:11:39 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: Can't Knit Two Files Together
Message-Id: <Pine.GSO.4.10.10005241707430.14618-100000@user2.teleport.com>
On Wed, 24 May 2000, Gwyn Judd wrote:
> I don't think the "die"'s should be optional. Obviously the script will
> die anyway when you try to read from the unopened filehandles
Unless I've misunderstood you, this turns out not to be the case. Reading
from an unopened filehandle will generally cause a warning (if warnings
are turned on), but will not make the program die.
You're right, of course, that a good programmer will always check the
return value of open.
Cheers!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Wed, 24 May 2000 17:36:04 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Can't Knit Two Files Together
Message-Id: <392C7574.DDC8A3FF@stomp.stomp.tokyo>
Tom Phoenix wrote:
> On Wed, 24 May 2000, Gwyn Judd wrote:
> You're right, of course, that a good programmer will
> always check the return value of open.
A great programmer will do more than this,
as I well illustrated recently, in one of
my articles.
Godzilla!
------------------------------
Date: Wed, 24 May 2000 23:38:57 GMT
From: bh447@freenet.carleton.ca (Markus Svilans)
Subject: daemon programming
Message-Id: <392c67ed.3200439@news.ncf.carleton.ca>
Hi,
Where is a good place I can start learning about daemons and how to
program them? (When I use the word 'daemon' I mean a program that runs
in the background, which performs a task at specific intervals; please
correct me if I am using the wrong word for the wrong meaning.)
The reason I ask is because I need some sort of way I can update a
text file that resides on a web server every hour or so,
automatically.
Thanks!
-Markus
--
Rainy days and automatic weapons always get me down.
------------------------------
Date: Wed, 24 May 2000 17:14:34 -0700
From: Makarand Kulkarni <makarand_kulkarni@My-Deja.com>
Subject: Re: daemon programming
Message-Id: <392C706A.CE0A5661@My-Deja.com>
> Where is a good place I can start learning about daemons and how to
> program them? (When I use the word 'daemon' I mean a program that runs
> in the background, which performs a task at specific intervals; please
> correct me if I am using the wrong word for the wrong meaning.)
>
> The reason I ask is because I need some sort of way I can update a
> text file that resides on a web server every hour or so,
> automatically.
use cron.
see man cron
--
------------------------------
Date: Wed, 24 May 2000 17:20:55 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: daemon programming
Message-Id: <Pine.GSO.4.10.10005241716480.14618-100000@user2.teleport.com>
On Wed, 24 May 2000, Markus Svilans wrote:
> The reason I ask is because I need some sort of way I can update a
> text file that resides on a web server every hour or so,
> automatically.
Sounds like a task for cron. See whether your system offers cron or a
similar utility for running a program "every hour or so, automatically".
If so, that's almost certainly the most efficient way to do it.
Cheers!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: 25 May 2000 00:17:00 GMT
From: cjw44@flatline.org.uk (Colin Watson)
Subject: Re: daemon programming
Message-Id: <8ghrds$c9a$1@riva.ucam.org>
Markus Svilans <toastman@mindless.com> wrote:
>Where is a good place I can start learning about daemons and how to
>program them? (When I use the word 'daemon' I mean a program that runs
>in the background, which performs a task at specific intervals; please
>correct me if I am using the wrong word for the wrong meaning.)
Try 'perldoc perlipc'; that should tell you the basics of how to put a
program into the background, and then you can probably just sleep() or
something.
>The reason I ask is because I need some sort of way I can update a
>text file that resides on a web server every hour or so,
>automatically.
Is there anything wrong with cron, or whatever the equivalent is on
Windows (System Agent, is it?)? Or is that not available?
--
Colin Watson [cjw44@flatline.org.uk]
"... a good part of the remainder of my life was going to be
spent in finding errors in my own programs." - Maurice Wilkes
------------------------------
Date: Thu, 25 May 2000 00:11:33 +0200
From: perler@yahoo.com (Patrick Erler)
Subject: debugging perl in win2000
Message-Id: <8F3FBD2Asproklotzfotzel@194.25.2.6>
hi!
could it be possible to utilize the the script debugger delivered with w2k
for perl-debugging? not to have a debugger as i used to have one since
turbo pascal 5 is one of the big show stoppers in perl for me..
PAT
------------------------------
Date: Thu, 25 May 2000 01:15:31 +0200
From: Zak McGregor <zapcs@icon.co.za>
Subject: Re: debugging perl in win2000
Message-Id: <392C6293.90561735@icon.co.za>
Patrick Erler wrote:
>
> hi!
>
> could it be possible to utilize the the script debugger delivered with w2k
> for perl-debugging? not to have a debugger as i used to have one since
> turbo pascal 5 is one of the big show stoppers in perl for me..
"perl -d" does nothing for you, I guess?
Find a Un*x(-like){0,1} box and perldoc perldebug. Alternatively use
$YOUR_FAVOURITE_SEARCH_ENGINE to find "perldebug".
Not sure what the equivalent "perldoc perldebug" syntax would be on the
w2k box...
Ciao
--
====================================================================
Zak McGregor
http://www.zap.co.za/zgas - On-line specifications of over 6700 cars
====================================================================
------------------------------
Date: 24 May 2000 22:42:36 GMT
From: dj3vande@student.math.uwaterloo.ca (Dave Vandervies)
Subject: Re: Finding IP addresses+
Message-Id: <8ghlss$79d$1@watserv3.uwaterloo.ca>
In article <8ghjgl$k4l$1@spinner.corpeast.baynetworks.com>,
Brandon Metcalf <bmetcalf@baynetworks.com> wrote:
>rootbeer@redcat.com writes:
>
> > Does it match 2130706433? I can telnet to that address; can you? :-)
> >
> > I can generally find something interesting at this URL, although some
> > browsers don't work properly with it.
> >
> > http://3427256387/
>
>I tried searching a few places but didn't come up with anything. How
>do these purely numerical addresses translate to the octet addresses?
Write it in hex, and then just put dots between the octets. Converting
the individual octets from hex back to decimal might make it easier to
recognize.
dave
--
Dave Vandervies dj3vande@student.math.uwaterloo.ca
I love that the net is responsible for the propagation of the ILOVEYOU worm,
according to Microsoft. In much the same manner that air is responsible for
the propagation of bullets. -D. Joseph Creighton in the Scary Devil Monastery
------------------------------
Date: Thu, 25 May 2000 00:09:55 +0100
From: ben@scientia.demon.co.uk (Ben Smithurst)
Subject: Re: Finding IP addresses+
Message-Id: <slrn8iooa4.asd.ben@strontium.scientia.demon.co.uk>
Brandon Metcalf wrote:
> I tried searching a few places but didn't come up with anything. How
> do these purely numerical addresses translate to the octet addresses?
An IPv4 address is a 32 bit number. How you represent it is your
business. It's just conventional with IPv4 address to print the four
bytes as decimal numbers separated by dots.
--
Ben Smithurst / ben@scientia.demon.co.uk / PGP: 0x99392F7D
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V9 Issue 3154
**************************************
