[9334] in Perl-Users-Digest
Perl-Users Digest, Issue: 2929 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jun 21 22:07:28 1998
Date: Sun, 21 Jun 98 19:00:24 -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 Sun, 21 Jun 1998 Volume: 8 Number: 2929
Today's topics:
Re: creating files using CGI script <rootbeer@teleport.com>
Re: first language raw@cs.wisc.edu
Re: Flames.... (T. Ames)
Re: Flames.... <tchrist@mox.perl.com>
Re: Flames.... <rootbeer@teleport.com>
Re: Flames.... <rootbeer@teleport.com>
Re: Flames.... <rootbeer@teleport.com>
Help with guestbook PLEASE (Bill)
Re: Help with guestbook PLEASE <dj_adams@earthlink.net>
IPC::Open2 and Comm.pl seem to fail under FreeBSD (Jeff Kletsky)
Re: problems with flock (Brian L. Matthews)
Re: problems with flock (Brian L. Matthews)
Re: problems with flock <tchrist@mox.perl.com>
problems with script <dj_adams@earthlink.net>
Re: problems with script <rootbeer@teleport.com>
Re: Question about perl and sockets -- long abraham@mpi.com
Re: RTF parsing <rootbeer@teleport.com>
Re: sendmail problems <dean@mail.biol.sc.edu>
When is Mortalization Necessary? <rthorne@netscape.com>
Re: Win32 file path separator <mikep@5circles.com>
writing a mud in perl HalloweenJack@my-dejanews.com
Re: writing a mud in perl (Ronald J Kimball)
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 22 Jun 1998 01:48:16 GMT
From: Tom Phoenix <rootbeer@teleport.com>
Subject: Re: creating files using CGI script
Message-Id: <Pine.GSO.3.96.980621184639.6898E-100000@user2.teleport.com>
On Sun, 21 Jun 1998, Daniel J Adams wrote:
> Is it possible to make a CGI script written in Perl for a SunOS (UNIX)
> system create a file in a given directory based upon a defined variable.
Yes. If you need more help with CGI programming, the docs, FAQs, and
newsgroups about CGI programming should be helpful for you. If you're
trying to create a file in Perl, see the entry for 'open' in the perlfunc
manpage. Hope this helps!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Mon, 22 Jun 1998 00:56:55 GMT
From: raw@cs.wisc.edu
Subject: Re: first language
Message-Id: <6mka4n$n1j$1@nnrp1.dejanews.com>
In article <6mf1o8$nc4$1@monet.op.net>,
mjd@op.net (Mark-Jason Dominus) wrote:
>
>
> In article <MPG.ff47c2f250e4d769896ae@nntp.hpl.hp.com>,
> Larry Rosler <lr@hpl.hp.com> wrote:
> >
> >No, that is not the reason at all. Scanf cannot modify argument
> >variables *anywhere* because of C's intractable call-by-value semantics.
> >In order for a C function to modify any of its arguments, the argument
> >must be a pointer to the actual lvalue to be modified. This is
> >independent of the scope of that lvalue.
>
> lvalues do not have scope. Only names have scope.
>
> In any event, it is irrelevant to this discussion. Consider a
> language that supports both call-by-value and call-by-reference
> semantics, say Pascal. You will have to explain to the students why
> one and not the other must be used in a case like this, and the
> explanation will be nearly identical to the explanation of why scanf
> arguments are preceded by & in C. So pedagogically, there is very
> little difference between these two things.
This is wrong.
In Pascal, read and write have the same syntax (except for optional
formatting in write). Call by value and call by reference are
distinguished when defining a function or procedure, not when calling
it. Since C does not have call by reference, it must simulate it
with explicit pointers; and this is relevant for calls of standard
functions like scanf, which look very different from printf.
Pointers should be taught early in C, because they are so fundamental.
--
MJSR
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
------------------------------
Date: Mon, 22 Jun 1998 00:00:49 GMT
From: ames0009@tc.umn.edu (T. Ames)
Subject: Re: Flames....
Message-Id: <358d9bd3.351150@news.tc.umn.edu>
On Sun, 21 Jun 1998 17:00:00 GMT, chip@mail.atlantic.net (Chip
Salzenberg) wrote:
>According to ames0009@tc.umn.edu:
>>Your response also displays the "I'm so smart--you're so stupid"
>>attitude ...
>
>Why should a demand that petitioners exert some effort be interpreted
>as a put-down?
>
>Why should it be too much to expect that a person wanting to learn
>about a *programming*language* know how to grep?!
That's the whole point. Your talking about people who are trying to
learn what "grep" is -- but you are assuming (as many posters do) that
a novice should already know something before they even ask. Why would
they ask if they knew how to get the answer already?
I'll really go out on a limb here and say that there was a time when
you didn't know what "grep" (or any other command) was. If you're
taking the argument that seems to be so popular here ("Well, if you
don't already know x, than you don't deserve to live"), just keep in
mind that everything wasn't always so obvious to you when you were
just beginning.
>>>>>>>>>>>>>>>>>>>
Todd C. Ames
ames0009@tc.umn.edu
University of Minnesota
------------------------------
Date: 22 Jun 1998 00:01:56 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Flames....
Message-Id: <6mk6tk$2em$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc, ames0009@tc.umn.edu writes:
:I'll really go out on a limb here and say that there was a time when
:you didn't know what "grep" (or any other command) was.
I don't believe there was ever a time when you weren't expected
to consult the standard documentation for tool T, for all T,
before whining about your confusion. The problem is that
the $Bill generation has lost the ability to help themselves.
But we knew that. We're just repeating ourselves. When the
moderated group appears, we will have the best possible anti-lamer
mechanism. Until then, the best we can do is social engineering.
--tom
--
Ask Ken. He hates Everything.
------------------------------
Date: Mon, 22 Jun 1998 01:45:46 GMT
From: Tom Phoenix <rootbeer@teleport.com>
Subject: Re: Flames....
Message-Id: <Pine.GSO.3.96.980621184512.6898D-100000@user2.teleport.com>
On Sun, 21 Jun 1998, Brand and Karina Hilton wrote:
> Perhaps the mini-FAQ should be posted rather than mailed.
If someone doesn't read what's already being posted, why would additional
(identical) postings help anyone?
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Mon, 22 Jun 1998 01:51:27 GMT
From: Tom Phoenix <rootbeer@teleport.com>
Subject: Re: Flames....
Message-Id: <Pine.GSO.3.96.980621184842.6898F-100000@user2.teleport.com>
On Sun, 21 Jun 1998 birgitt@my-dejanews.com wrote:
[ 2 1/2 screens of quoted text were here. Please don't quote messages in
there entirety when you could cut down or summarize instead. ]
> 1. Post the
> FAQ! ANSWERS TO YOUR QUESTIONS ! READ FIRST!
> *daily* even *twice daily*. And I would include as many
> detailed pointers as you can.
If someone isn't reading what's already out there, why would additional
postings make a difference?
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Mon, 22 Jun 1998 01:53:24 GMT
From: Tom Phoenix <rootbeer@teleport.com>
Subject: Re: Flames....
Message-Id: <Pine.GSO.3.96.980621185146.6898G-100000@user2.teleport.com>
On 21 Jun 1998, Leslie Mikesell wrote:
> Is there something about a 'misc' newsgroup that excludes questions
> about cgi and non-unix systems?
No, the rule is that a questioner should look in the most appropriate
place for their answer. If it's a question about CGI programming, the
docs, FAQs, and newsgroups about that are going to be more appropriate
than a newsgroup about Perl.
Cheers!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Mon, 22 Jun 1998 01:23:18 GMT
From: jsadek@bayou.uh.edu (Bill)
Subject: Help with guestbook PLEASE
Message-Id: <358dbfb0.68926330@news.insync.net>
Hi, I am trying to make a guestbook perl file work. I keep getting an
error and I narrowed it down to the following lines. This is where
the error occurs. ($guestbookreal is pointed to the right address.)
##start##
# Begin the Editing of the Guestbook File
open (FILE,"$guestbookreal") || die "Can't Open $guestbookreal:
#$#$!\n";
@LINES=<FILE>;
close(FILE);
$SIZE=@LINES;
##end##
The line that the error occurs at is the open statement. The error it
gives me is:
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Please contact the server administrator, webmaster@insync.net and
inform them of the time the error occurred, and anything
you might have done that may have caused the error.
What am I doing wrong? Any help please?
you can reply via email at: jsadek@bayou.uh.edu
------------------------------
Date: Sun, 21 Jun 1998 20:39:08 -0500
From: "Daniel J Adams" <dj_adams@earthlink.net>
Subject: Re: Help with guestbook PLEASE
Message-Id: <6mkcil$kf6$1@argentina.it.earthlink.net>
Shouldn't
open (FILE,"$guestbookreal") || die "Can't Open $guestbookreal:
read
open (FILE, "$guestbookreal") || die "Can't Open $guestbookreal\n";
(note semicolon at end)
I think
Daniel J Adams
a.a atheist #605
email: any name at fearsome.net
atheist webzine: http://fearsome.net;
Bill wrote in message <358dbfb0.68926330@news.insync.net>...
>Hi, I am trying to make a guestbook perl file work. I keep getting an
>error and I narrowed it down to the following lines. This is where
>the error occurs. ($guestbookreal is pointed to the right address.)
>
>##start##
># Begin the Editing of the Guestbook File
>open (FILE,"$guestbookreal") || die "Can't Open $guestbookreal:
>#$#$!\n";
>@LINES=<FILE>;
>close(FILE);
>$SIZE=@LINES;
>##end##
>
>The line that the error occurs at is the open statement. The error it
>gives me is:
>
>Internal Server Error
>
>The server encountered an internal error or misconfiguration and was
>unable to complete your request.
>
>Please contact the server administrator, webmaster@insync.net and
>inform them of the time the error occurred, and anything
>you might have done that may have caused the error.
>
>
>What am I doing wrong? Any help please?
>
>you can reply via email at: jsadek@bayou.uh.edu
------------------------------
Date: Sun, 21 Jun 1998 18:24:24 -0700
From: Jeff/dev/null@Wagsky.com (Jeff Kletsky)
Subject: IPC::Open2 and Comm.pl seem to fail under FreeBSD
Message-Id: <Jeff/dev/null-2106981824240001@mac.pn.wagsky.com>
I'm a bit puzzled by the behavior of IPC::Open and Comm.pl (1.8) with
perl5.004_004 under FreeBSD (STABLE). Neither seems to work "as
advertised" -- and could use some suggestions as where to start to fix
this problem. Rebuilding perl5 and IPC:: have resulted in no changes.
This behavior is present both on this system, as well as one operated by
my ISP. It appears to be FreeBSD-related as the IPC::Open2 script
performs as expected under Linux (one of the few things that *does* work
the first time under Linux ;-)
IPC::Open2 has an example in the Camel book which provides no output back
to from 'bc'
===== Start of script
use IPC::Open2;
use Symbol;
$WTR = gensym(); # get a reference to a typeglob
$RDR = gensym(); # and another one
$pid = open2($RDR, $WTR, 'bc');
while (<STDIN>) { # read commands from user
print $WTR $_; # write a command to bc(1)
$line = <$RDR>; # read the output of bc(1)
print STDOUT "$line"; # send the output to the user
}
===== End of script
Running the test script from Comm.pl (modified to increase debug level)
===== Start of script
#--------------------------- Example /bin/sh expect
-----------------------------
# This is a useful test in addition to the telnet test because having the
# "telnet" process between you and the remote shell can mask terminal modes
# problems.
$Debug = 1;
eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}'
& eval 'exec perl -S $0 $argv:q'
if 0;
require "Comm.pl";
&Comm'init( 1.8 );
#$Debug=1;
$|=1;
( $Proc_pty_handle, $Proc_tty_handle, $pid ) = &open_proc( "/bin/sh" );
die "open_proc failed" unless $Proc_pty_handle;
&stty_sane($Proc_tty_handle); # use $Proc_pty_handle for HP
&stty_raw(STDIN);
print "You are now connected to the shell process, ^C to break out\n";
LOOP: {
( $match, $err ) = &interact( "\003", $Proc_pty_handle );
if ( $err ) { print "Aborting, err($err)\n"; last; }
if ( $match eq "\003" ) { print "Got control-C\n"; last; }
redo LOOP;
}
&stty_sane(STDIN);
print "Disconnected\n";
===== End of script
produces this bit of gobbledegook, prior to requiring me to "stty sane" to
get things back to normal after the script completes (there are many NULs
in the calls to ioctl_syscall which are omitted in this printable
version):
===== 2>&1 tee log
*main'open_port = *Comm'open_port
*main'open_listen = *Comm'open_listen
*main'open_udp_port = *Comm'open_udp_port
*main'open_proc = *Comm'open_proc
*main'send_to = *Comm'send_to
*main'recv_from = *Comm'recv_from
*main'accept_it = *Comm'accept_it
*main'select_it = *Comm'select_it
*main'expect = *Comm'expect
*main'interact = *Comm'interact
*main'close_noshutdown = *Comm'close_noshutdown
*main'close_it = *Comm'close_it
*main'stty_sane = *Comm'stty_sane
*main'stty_raw = *Comm'stty_raw
*main'stty_ioctl = *Comm'stty_ioctl
OS_type=SVR4
OS_name=FreeBSD
getpty: trying pty=/dev/ptyp2, tty=/dev/ttyp2
getpty: returning (/dev/ptyp2,/dev/ttyp2)
open_proc: mypid=1924, $PIDS{proccommutils000001} = 1932
open_proc: mypid=1932, $PIDS{proccommutils000001} = 0
*main'proccommutils000001 = *Comm'proccommutils000001
do_tty_child: ( proccommutils000002, /dev/ttyp2, /bin/sh )
*main'proccommutils000002 = *Comm'proccommutils000002
open_proc returning: (proccommutils000001,proccommutils000002,1932)
get_ioctl_from_stty(proccommutils000002): stty sane </dev/ttyp2 >/dev/ttyp2
ioctl_syscall(proccommutils000002, TCGETA , )
ioctl_syscall: ioctl failed,resorting to syscall
ioctl failed, args=(proccommutils000002 21505 *Comm::ioctl_struct) at
Comm.pl line 1973.
syscall_safe( 54, 4, 21505, at Comm.pl line 1974.
errno=Inappropriate ioctl for device at Comm.pl line 1975.
ioctl_syscall returning
ioctl_syscall(proccommutils000002, TCSETA , )
ioctl_syscall: ioctl failed,resorting to syscall
ioctl failed, args=(proccommutils000002 21506 *Comm::tmp) at Comm.pl line 1973.
syscall_safe( 54, 4, 21506, at Comm.pl line 1974.
errno=Inappropriate ioctl for device at Comm.pl line 1975.
ioctl_syscall returning
Done, stty_ioctl
Done, stty_sane
get_ioctl_from_stty(STDIN): stty raw -echo </dev/tty >/dev/tty
ioctl_syscall(STDIN, TCGETA , )
ioctl_syscall: ioctl failed,resorting to syscall
ioctl failed, args=(STDIN 21505 *Comm::ioctl_struct) at Comm.pl line 1973.
syscall_safe( 54, 0, 21505, at Comm.pl line 1974.
errno=Inappropriate ioctl for device at Comm.pl line 1975.
ioctl_syscall returning
ioctl_syscall(STDIN, TCSETA , )
ioctl_syscall: ioctl failed,resorting to syscall
ioctl failed, args=(STDIN 21506 *Comm::tmp) at Comm.pl line 1973.
syscall_safe( 54, 0, 21506, at Comm.pl line 1974.
errno=Inappropriate ioctl for device at Comm.pl line 1975.
ioctl_syscall returning
Done, stty_ioctl
Done, stty_raw
You are now connected to the shell process, ^C to break out
sh: can't access tty; job control turned off
\u@\h:\w\$ ls
#test# examples test
#test2# foo test.PL
Comm ipc2.PL test.PL~
Comm.pl page.PL test2
Comm.pl-1.8.tar.gz page.PL.log test2~
Comm.pl.debug page.PL~ test~
IPC_Open2 perl.2ed.tar.Z
\u@\h:\w\$ Got control-C
ioctl_syscall(STDIN, TCSETA , )
ioctl_syscall: ioctl failed,resorting to syscall
ioctl failed, args=(STDIN 21506 *Comm::tmp) at Comm.pl line 1973.
syscall_safe( 54, 0, 21506, at Comm.pl line 1974.
errno=Inappropriate ioctl for device at Comm.pl line 1975.
ioctl_syscall returning
Done, stty_ioctl
Done, stty_sane
Disconnected
===== end of log
I have tried
$touch /vmunix
to "fool" Comm.pl to set $OS_type to BSD, but the results are even worse,
with the whole program freezing before a shell prompt is seen. Here's the
log for that:
===== /vmunix log
*main'open_port = *Comm'open_port
*main'open_listen = *Comm'open_listen
*main'open_udp_port = *Comm'open_udp_port
*main'open_proc = *Comm'open_proc
*main'send_to = *Comm'send_to
*main'recv_from = *Comm'recv_from
*main'accept_it = *Comm'accept_it
*main'select_it = *Comm'select_it
*main'expect = *Comm'expect
*main'interact = *Comm'interact
*main'close_noshutdown = *Comm'close_noshutdown
*main'close_it = *Comm'close_it
*main'stty_sane = *Comm'stty_sane
*main'stty_raw = *Comm'stty_raw
*main'stty_ioctl = *Comm'stty_ioctl
OS_type=BSD
OS_name=FreeBSD
getpty: trying pty=/dev/ptyp2, tty=/dev/ttyp2
getpty: returning (/dev/ptyp2,/dev/ttyp2)
open_proc: mypid=1974, $PIDS{proccommutils000001} = 1982
open_proc: mypid=1982, $PIDS{proccommutils000001} = 0
*main'proccommutils000001 = *Comm'proccommutils000001
do_tty_child: ( proccommutils000002, /dev/ttyp2, /bin/sh )
*main'proccommutils000002 = *Comm'proccommutils000002
open_proc returning: (proccommutils000001,proccommutils000002,1982)
get_ioctl_from_stty(proccommutils000002): stty sane </dev/ttyp2 >/dev/ttyp2
ioctl_syscall(proccommutils000002, TIOCGETP TIOCGETP TIOCGETP , )
ioctl_syscall returning
ioctl_syscall(proccommutils000002, TIOCSETP TIOCSETP TIOCSETP ,
)
===== end of log /vmunix
Any suggestions as to where to start would be quite welcome!
Jeff
--
Jeff Kletsky spam > /dev/null, please adjust your
San Francisco, CA destination addresses to the user "Jeff"
------------------------------
Date: 21 Jun 1998 18:08:24 -0700
From: blm@halcyon.com (Brian L. Matthews)
Subject: Re: problems with flock
Message-Id: <6mkaq8$gbo$1@halcyon.com>
In article <MPG.ff6f5a1725b251f9896dc@nntp.hpl.hp.com>,
Larry Rosler <lr@hpl.hp.com> wrote:
|> flock(FILE1, 8);
|> close(FILE1);
|> flock(FILE2,8);
|> close(FILE2);
|But I do know that you should *not* unlock the files.
Why not? Yes, if you're just going to immediately close a file, it's not
*necessary* to unlock the file first, but it doesn't really hurt anything,
other than the few extra microseconds it may take.
Brian
------------------------------
Date: 21 Jun 1998 18:05:48 -0700
From: blm@halcyon.com (Brian L. Matthews)
Subject: Re: problems with flock
Message-Id: <6mkalc$g85$1@halcyon.com>
In article <358D4CFE.E69F2435@email.enst.fr>,
Jaime Pozuelo-Monfort <pozuelo@email.enst.fr> wrote:
|It might be a problem of the redirect function
It's not a problem with the redirect function, it's a problem with the
whole concept of redirection. You seem to think the redirection occurs
when you call redirect. It doesn't, it happens some indeterminate amount
of time in the future, long after your script has finished and any number
of other people could have run the script again.
Instead of writing the HTML to a file, just send it to STDOUT. Check one
of the CGI newsgroups for more information on this.
Brian
------------------------------
Date: 22 Jun 1998 01:32:46 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: problems with flock
Message-Id: <6mkc7u$9m5$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
blm@halcyon.com (Brian L. Matthews) writes:
:Why not? Yes, if you're just going to immediately close a file, it's not
:*necessary* to unlock the file first, but it doesn't really hurt anything,
:other than the few extra microseconds it may take.
Gosh, I know that *I'd* like to make sure my data gets to
the file prior to unlocking it.
--tom
--
"I find this a nice feature but it is not according to the documentation.
Or is it a BUG?"
"Let's call it an accidental feature. :-)" Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
------------------------------
Date: Sun, 21 Jun 1998 18:48:58 -0500
From: "Daniel J Adams" <dj_adams@earthlink.net>
Subject: problems with script
Message-Id: <6mk64f$ncg$1@bolivia.it.earthlink.net>
Hi,
I was hoping that somebody would be able to tell me what is wrong with the
following snippet of code, it doesn't seem to work. It is part of a perl CGI
script for a UNIX server.
open (GETCOUNT,"<$fileserv/numero.dat");
$counter=<GETCOUNT>;
close (GETCOUNT);
$counter++; & nbsp;
print "$counter quotes so far<br>\n";
print "This information has been written to $fileserv/numero.dat<br><br>\n";
open (PUTCOUNT,">$fileserv/numero.dat");
print PUTCOUNT ($counter);
close PUTCOUNT;
Thanks,
--
Daniel J Adams
a.a atheist #605
email: any name at fearsome.net
atheist webzine: http://fearsome.net
------------------------------
Date: Mon, 22 Jun 1998 01:56:29 GMT
From: Tom Phoenix <rootbeer@teleport.com>
Subject: Re: problems with script
Message-Id: <Pine.GSO.3.96.980621185539.6898I-100000@user2.teleport.com>
On Sun, 21 Jun 1998, Daniel J Adams wrote:
> Subject: problems with script
Please check out this helpful information on choosing good subject
lines. It will be a big help to you in making it more likely that your
requests will be answered.
http://www.perl.com/CPAN/authors/Dean_Roehrich/subjects.post
> open (GETCOUNT,"<$fileserv/numero.dat");
Even when your script is "just an example" (and perhaps especially in that
case!) you should _always_ check the return value after opening a file.
Also, I think you could use the methods in Randal's fourth Web Techniques
column, which explains how to use flock() to avoid problems when multiple
processes need to modify one file. Hope this helps!
http://www.stonehenge.com/merlyn/WebTechniques/
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Mon, 22 Jun 1998 00:36:40 GMT
From: abraham@mpi.com
Subject: Re: Question about perl and sockets -- long
Message-Id: <6mk8uo$lis$1@nnrp1.dejanews.com>
Oops -- thanks to Dave Rachlis for pointing out that I needed to pack integers
that I was sending, and to swap the byte order on integers coming back.
Jim Abraham
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
------------------------------
Date: Mon, 22 Jun 1998 01:53:49 GMT
From: Tom Phoenix <rootbeer@teleport.com>
Subject: Re: RTF parsing
Message-Id: <Pine.GSO.3.96.980621185333.6898H-100000@user2.teleport.com>
On 21 Jun 1998, Michele Beltrame wrote:
> I need a Perl module or function to parse RTF (Rich Text Format) or on
> second choice MS WinWord DOC files. Also a RTF->HTML converter would
> be helpful. Any advice?
If there's a module which does what you want, it should be listed in
the module list on CPAN. If you don't find one to your liking, you're
welcome and encouraged to submit one! :-) Hope this helps!
http://www.perl.org/CPAN/
http://www.perl.com/CPAN/
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: 21 Jun 1998 19:05:05 -0400
From: Dean Pentcheff <dean@mail.biol.sc.edu>
Subject: Re: sendmail problems
Message-Id: <m3d8c2e4pq.fsf@mail.biol.sc.edu>
neilb@zetnet.co.uk (Neil Briscoe) writes:
> In article <Pine.GSO.3.96.980620230148.4272D-100000@user2.teleport.com>,
> rootbeer@teleport.com (Tom Phoenix) wrote:
> > On Sun, 21 Jun 1998, Sifu Hall wrote:
> > > The form processes fine but the email message is never sent.
...
> Well, its either that, or use the Net::SMTP module, and you could talk in
> native protocol rather than worrying about program switches.
>
> If you can't get that to work having read the documentation, at least you
> can ask a Perl related question.
I'm continually mystified as to why people suggest using Net::SMTP as
a reasonable way for a Perl program to send an email message. On the
surface of it, it looks like a good idea: "Hey, I could call that
external sendmail program (about which I'd have to read a nasty manual
page), or I can cut to the chase and do the job internally with
Net::SMTP -- much cooler!"
The trouble with that approach, of course, surfaces the first time one
tries to send a message to a mail host that's inaccessible for an hour
or two. Unless one really wants to write a mail spooling routine. Or
tries to send to a mail address handled using an MX record. Right-o.
At which point, sendmail starts becoming much more attactive...
-Dean
--
N. Dean Pentcheff <pentcheff@acm.org>
Biological Sciences, Univ. of South Carolina, Columbia SC 29208 (803-777-7068)
------------------------------
Date: Sun, 21 Jun 1998 17:10:43 -0700
From: Rob Thorne <rthorne@netscape.com>
Subject: When is Mortalization Necessary?
Message-Id: <358DA103.F0C1F48C@netscape.com>
This is a multi-part message in MIME format.
--------------FA61684AC273D0931E4D8F58
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm writing an XSUB that needs to return a set of key/value pairs to
Perl. A reference to a hash seems like the right thing to return.
After going through perlguts more times than I'd like to count, I'm
still not sure when I need to make SV mortal in order to prevent memory
leaks. If my steps are:
1) Get two char * (keyStr, valStr)
2) Create SV * for valStr ==> valSV [?#1: do this need to be mortal?]
3) Create an HV * (myHV), and add valSV to it under key keyStr.
4) Continue adding key/value pairs as above;
5) Create a reference to myHV [with newRV_noinc, yes?], and pass this
back as my RETVAL
then:
1) When do I need to make my SV * mortal?
2) Does hv_store increment the value's ref count when it gets added?
As an additional bonus question: can anyone recommend a strategy for
detecting memory leaks when developing XSUBs for Win32?
Thanks much,
Rob
rthorne@netscape.com
--------------FA61684AC273D0931E4D8F58
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Rob Thorne
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Rob Thorne
n: Thorne;Rob
org: NSCP Client L10n Engineering Lead
email;internet: rthorne@netscape.com
tel;work: 650/937-4102
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
version: 2.1
end: vcard
--------------FA61684AC273D0931E4D8F58--
------------------------------
Date: Sun, 21 Jun 1998 18:10:19 -0700
From: "Mike Pritchard" <mikep@5circles.com>
Subject: Re: Win32 file path separator
Message-Id: <6mkb0b$t3u$1@news6.ispnews.com>
Well, I thought I had enough information from the help people had offered -
backslashing the backslash or using forward slash, and a different match
for the drive letter case. But I'm still getting stuck - so I've
temporarily hard coded the directory path.
Is there a good resource to help explain the differences in file separators
and end of line between UNIX and PC versions of Perl? And options put in to
ActiveState Perl.
Thanks
Mike
------------------------------
Date: Sun, 21 Jun 1998 23:51:42 GMT
From: HalloweenJack@my-dejanews.com
Subject: writing a mud in perl
Message-Id: <6mk6ae$hm6$1@nnrp1.dejanews.com>
I tried to post this yesterday, but it didn't seem to get thru. Apologies if
this is its second appearance.
I'm considering writing a mud in perl (along with a few friends). I'm aware
that on already exists (PerlMUD), but we kind of want to write our own from
scratch.
What I need to know is if anyone can tell me which man/web pages I would need
to look at, in order to figure out how to handle the multiple telnet
connections we would be getting. My perl is not bad, but I'm not terribly
up on sockets, etc.
If it takes off, I'll probably be posting regularly with questions :)
Thanks in Advance
Aidan
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
------------------------------
Date: Sun, 21 Jun 1998 21:09:45 -0400
From: rjk@coos.dartmouth.edu (Ronald J Kimball)
Subject: Re: writing a mud in perl
Message-Id: <1dazrpf.gtozp1122pzqaN@bay1-189.quincy.ziplink.net>
<HalloweenJack@my-dejanews.com> wrote:
> What I need to know is if anyone can tell me which man/web pages I would need
> to look at, in order to figure out how to handle the multiple telnet
> connections we would be getting. My perl is not bad, but I'm not terribly
> up on sockets, etc.
A multi-file search of the standard documentation for the string
'socket' returns 237 matches. You should concentrate on the following
files:
(In alphabetical order)
perlfaq8
perlfunc
perlipc
perlmodlib
You'll also want to check out the IO::Socket and IO::Select modules.
I'm not terribly up on sockets either, but I was able to write a program
which accepts multiple telnet connections fairly easily with the help of
the documentation and the Camel book.
> If it takes off, I'll probably be posting regularly with questions :)
Thanks for the warning! Seriously, though, just be sure to check the
docs and the FAQ before you post a question. Good luck!
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
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 2929
**************************************
