[28345] in Perl-Users-Digest
Perl-Users Digest, Issue: 9709 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Sep 10 18:06:00 2006
Date: Sun, 10 Sep 2006 15:05:09 -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 Sun, 10 Sep 2006 Volume: 10 Number: 9709
Today's topics:
Re: converting vba to perl without win32::ole <daveandniki@ntlworld.com>
Re: Different behaviour linux vs Win32 <hjp-usenet2@hjp.at>
Re: Different behaviour linux vs Win32 anno4000@radom.zrz.tu-berlin.de
Re: Different behaviour linux vs Win32 <please@replytogroup.com>
exec command issue <don@mastah.com>
Re: localtime is now wrong after server change anno4000@radom.zrz.tu-berlin.de
Re: localtime is now wrong after server change <hjp-usenet2@hjp.at>
Re: localtime is now wrong after server change <1usa@llenroc.ude.invalid>
Re: localtime is now wrong after server change <tadmc@augustmail.com>
Re: localtime is now wrong after server change <mgarrish@gmail.com>
Perl - serial input and buffering problem <jc_usernet@aanet.com.au>
Re: Perl - serial input and buffering problem <see.sig@rochester.rr.com>
Re: scalar to method name (Randal L. Schwartz)
Re: scalar to method name anno4000@radom.zrz.tu-berlin.de
Re: scalar to method name <hjp-usenet2@hjp.at>
Re: scalar to method name anno4000@radom.zrz.tu-berlin.de
Re: scalar to method name <hjp-usenet2@hjp.at>
Re: Simple OpenGL script to exe failing lul1@gmx.net
Re: Tk::Checkbutton - text does not line up ... <christoph.lamprecht.no.spam@web.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 10 Sep 2006 17:38:12 +0200
From: "Dave" <daveandniki@ntlworld.com>
Subject: Re: converting vba to perl without win32::ole
Message-Id: <4504316a$0$27407$ba4acef3@news.orange.fr>
"matt" <darthmullet67@hotmail.com> wrote in message
news:1157722462.930896.258990@h48g2000cwc.googlegroups.com...
>I am currently trying to convert a vba macro to perl. The vba macros
> are basically find and replaces on txt files. The problem is that there
> are roughly 25000 find and replaces and they are setup to run in a
> sequential order, meaning that they search for a string and if the
> string is found then it will find and replace from that point on until
> EOF. Once it reaches the EOF it will then reset to the start of the txt
> file and continues on to the next find and replace. How can I
> accomplish this type of parsing with perl. I am trying to get the vba
> code out of microsoft word so I do not want to use the win32::ole for
> this conversion. Here is a snippet of the VBA and converted perl code.
> Thanks for any help in advance.
>
> <SNIP>
> VBA code:
>
> Set variable = New variable_Class
> If variable.FindText("<R [,;)]") = True Then
> Selection.Collapse wdCollapseEnd
> If variable.FindText("<R [,;)]") = True Then
> Selection.Collapse wdCollapseEnd
> If variable.FindText("<R [,;)]") = True Then
> Selection.Collapse wdCollapseEnd
> If variable.FindText("[0-9]{1,} [0-9]{1,} [0-9]") =
> True Then
> Selection.HomeKey wdStory
> variable.FindandReplace "(^13+pg,[0-9]{1,}^13)(+l)
> ", " \2\1"
> Call Subroutine
> End If
> End If
> End If
> End If
>
>
> Perl converted code:
>
> if ($_=~/<R [,;)]/){
> #Selection.Collapse wdCollapseEnd <==not sure how to convert
> this to perl
> if ($_=~/<R [,;)]/){
> #Selection.Collapse wdCollapseEnd <==not sure how to convert
> this to perl
> if ($_=~/<R [,;)]/){
> #Selection.Collapse wdCollapseEnd <==not sure how to convert
> this to perl
> if ($_=~/[0-9]{1,} [0-9]{1,} [0-9]/){
> #Selection.HomeKey wdStory <==not sure how to convert this
> to perl
> $_=~s/(\n\+pg,[0-9]{1,}\n)(\+l)/ $2$1/g;
> &Subroutine;
> }
> }
> }
> }
>
OK this code is just covering for the lack of a true Regular Expression
engine in VBA. The Selection.Collapse bit is just saying 'start the next
part of the search from the end of the last succesful one'.
It is equivalent to:
if ($_ =~ /<R [,;)].*<R [,;)].*<R [,;)].*[0-9]+ [0-9]+ [0-9]/) {
$_ =~ s/(\n\+pg,[0-9]+\n)(\+l)/ $2$1/g;
&Subroutine;
}
(untested)
If this is not enough to put you on the right trial post again for more
clarification.
I'm not sure why you refer to win32::ole, if you want to parse the VBA code
using perl to automatically convert it, you can save it as a text file,
(.vbs is just a plain text file).
------------------------------
Date: Sun, 10 Sep 2006 17:11:11 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Different behaviour linux vs Win32
Message-Id: <slrneg8aol.dv7.hjp-usenet2@yoyo.hjp.at>
On 2006-09-10 14:22, Dazza T <please@replytogroup.com> wrote:
> I have some code that is meant to take a 32-bit number [0-0xFFFFFFFF] and
> round it down to the next exact multiple of a given `step'. It uses the %
> modulo operator and assumes we are dealing with unsigned integers (yes, I
> know, but read on). If I run it on a Win32 ActiveState system, it always
> gives me the answer I expect. But when I run it on a linux system with a
> value greater than 0x8000000, it doesn't work.
>
> I think the problem is to do with `signed' vs `unsigned' integers and, OK, I
> can live with that. The % operator advertises different behaviour with
> negative numbers.
>
>===(code 1)===
> #!/usr/local/bin/perl
> use strict
> my ($base, $step);
> $step = 0x7f79;
> $base = 0xE195ED24;
> printf "BASE =%08X\n", $base;
> # Adjust it to be an exact multiple of the step so base mod step == 0
> printf "ADJST=%08X\n", ($base % $step);
> $base -= ($base % $step);
> printf "EXACT=%08X\n", $base;
> # check
> printf "CHECK=%08X\n", ($base % $step);
>===(end code)===
>
> RESULTS:-
>
> 1. Windows 2000 Pro; perl, v5.6.1 built for MSWin32-x86-multi-thread
> BASE =E195ED24
> ADJST=000054E3
> EXACT=E1959841
> CHECK=00000000 (expecting zero)
>
> 2. perl, v5.6.0 built for i386-linux
> BASE =E195ED24
> ADJST=00003711
> EXACT=E195B613
> CHECK=00001DD2 (wrong!)
perl, v5.6.1 built for i386-linux
BASE =E195ED24
ADJST=000054E3
EXACT=E1959841
CHECK=00000000
> 1) What's wrong with the code below and how should it be changed so it will
> work with all 32-bit unsigned integers [0-0xFFFFFFFF] on any operating
> system?
The same result as with perl 5.6.1 under Windows. So it doesn't seem to
be a difference between Linux and Windows, but between perl 5.6.0 and
5.6.1. Probably a bug in 5.6.0 which was corrected in 5.6.1.
BTW, these perl versions are 6 years old. Do yourself a favour and
upgrade to a current version of perl (and to a current version of Linux,
too).
> *BUT* if I put a debugging print statement in the code, it starts working
> correctly again on the Linux system. Such behaviour really worries me.
>
> 2) Why does the intervening print statement change things?
>
>===(code 2)===
> #!/usr/local/bin/perl
> use strict
> my ($base, $step);
> $step = 0x7f79;
> $base = 0xE195ED24;
> printf "BASE =%08X\n", $base;
> # PUT A PRINT STATEMENT INBETWEEN...
> print "$base $step\n", ($base / $step), "\n", ($base % $step), "\n";
> # Adjust it to be an exact multiple of the step so base mod step == 0
> printf "ADJST=%08X\n", ($base % $step);
> $base -= ($base % $step);
> printf "EXACT=%08X\n", $base;
> # check
> printf "CHECK=%08X\n", ($base % $step);
>===(end code)===
>
> 3. perl, v5.6.0 built for i386-linux
> BASE =E195ED24
> 3784699172 32633
> 115977.665921
> 21731
> ADJST=000054E3
> EXACT=E1959841
> CHECK=00000000
>
> Why is this?
Perl scalars can be strings, floating point numbers, integral numbers
and a few other things. Depending on how to use them they can be one or
several of these types at once.
If you use Devel::Peek::Dump to look at $base, you can see that the
print statement changes $base:
| #!/usr/local/bin/perl
| use Devel::Peek;
| use strict;
| my ($base, $step);
| $step = 0x7f79;
| $base = 0xE195ED24;
| printf "BASE =%08X\n", $base;
| Dump ($base);
| print "$base $step\n", ($base / $step), "\n", ($base % $step), "\n";
| Dump ($base);
| # Adjust it to be an exact multiple of the step so base mod step == 0
| printf "ADJST=%08X\n", ($base % $step);
| $base -= ($base % $step);
| printf "EXACT=%08X\n", $base;
| # check
| printf "CHECK=%08X\n", ($base % $step);
| BASE =E195ED24
| SV = IV(0x80f6310) at 0x80f59e8
| REFCNT = 1
| FLAGS = (PADBUSY,PADMY,IOK,pIOK,IsUV)
| UV = 3784699172
Here $base is an unsigned integer (UV).
| 3784699172 32633
| 115977.665921
| 21731
| SV = PVNV(0x80eb470) at 0x80f59e8
| REFCNT = 1
| FLAGS = (PADBUSY,PADMY,IOK,NOK,POK,pIOK,pNOK,pPOK,IsUV)
| UV = 3784699172
| NV = 3784699172
| PV = 0x80ef570 "3784699172"\0
| CUR = 10
| LEN = 11
But now $base is also a floating point number (NV) and a string (PV).
This is because you used it in a floating point division and a string
interpolation. My guess is that perl takes the NV in a % operation if
there is one, so it gets the correct result. If there is no NV, it takes
the UV, but unsigned % seems to be buggy in perl 5.6.0 (it does a signed
% instead).
| ADJST=000054E3
| EXACT=E1959841
| CHECK=00000000
hp
--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd
------------------------------
Date: 10 Sep 2006 15:22:13 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Different behaviour linux vs Win32
Message-Id: <4miot5F6cu52U1@news.dfncis.de>
Dazza T <please@replytogroup.com> wrote in comp.lang.perl.misc:
> I have some code that is meant to take a 32-bit number [0-0xFFFFFFFF] and
> round it down to the next exact multiple of a given `step'. It uses the %
> modulo operator and assumes we are dealing with unsigned integers (yes, I
> know, but read on). If I run it on a Win32 ActiveState system, it always
> gives me the answer I expect. But when I run it on a linux system with a
> value greater than 0x8000000, it doesn't work.
[snippage]
> 1. Windows 2000 Pro; perl, v5.6.1 built for MSWin32-x86-multi-thread
> 2. perl, v5.6.0 built for i386-linux
> 3. perl, v5.6.0 built for i386-linux
> Why is this?
I don't know. You may have found a bug in 5.6.0 or 5.6.1.
These are ancient versions of Perl. Upgrade, and if the error persists,
file a bug report. I can't reproduce it with 5.8.7 or 5.9.4.
Anno
------------------------------
Date: Sun, 10 Sep 2006 18:28:55 +0100
From: "Dazza T" <please@replytogroup.com>
Subject: Re: Different behaviour linux vs Win32
Message-Id: <45044b57$0$1377$da0feed9@news.zen.co.uk>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote in message
news:slrneg8aol.dv7.hjp-usenet2@yoyo.hjp.at...
> On 2006-09-10 14:22, Dazza T <please@replytogroup.com> wrote:
> > I have some code that is meant to take a 32-bit number [0-0xFFFFFFFF]
and
> > round it down to the next exact multiple of a given `step'. It uses the
%
> > modulo operator and assumes we are dealing with unsigned integers (yes,
I
> > know, but read on). If I run it on a Win32 ActiveState system, it always
> > gives me the answer I expect. But when I run it on a linux system with a
> > value greater than 0x8000000, it doesn't work.
> >
> > I think the problem is to do with `signed' vs `unsigned' integers and,
OK, I
> > can live with that. The % operator advertises different behaviour with
> > negative numbers.
> >
[snipped]
> The same result as with perl 5.6.1 under Windows. So it doesn't seem to
> be a difference between Linux and Windows, but between perl 5.6.0 and
> 5.6.1. Probably a bug in 5.6.0 which was corrected in 5.6.1.
>
> BTW, these perl versions are 6 years old. Do yourself a favour and
> upgrade to a current version of perl (and to a current version of Linux,
> too).
>
> > *BUT* if I put a debugging print statement in the code, it starts
working
> > correctly again on the Linux system. Such behaviour really worries me.
> >
> > 2) Why does the intervening print statement change things?
> >
[snipped]
>
> Perl scalars can be strings, floating point numbers, integral numbers
> and a few other things. Depending on how to use them they can be one or
> several of these types at once.
>
> If you use Devel::Peek::Dump to look at $base, you can see that the
> print statement changes $base:
>
[snipped]
>
> But now $base is also a floating point number (NV) and a string (PV).
> This is because you used it in a floating point division and a string
> interpolation. My guess is that perl takes the NV in a % operation if
> there is one, so it gets the correct result. If there is no NV, it takes
> the UV, but unsigned % seems to be buggy in perl 5.6.0 (it does a signed
> % instead).
>
[snipped]
>
> hp
>
>
> --
> _ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
> |_|_) | Sysadmin WSR | > ist?
> | | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
> __/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd
BTW, these perl versions are 6 years old. Do yourself a favour and
upgrade to a current version of perl (and to a current version of Linux,
too).
-- Point taken and I'd love to upgrade but my web site provider gives me
what he gives. That's why I keep the 5.6 version on my Win32 system.
But now $base is also a floating point number (NV) and a string (PV).
This is because you used it in a floating point division and a string
interpolation. My guess is that perl takes the NV in a % operation if
there is one, so it gets the correct result. If there is no NV, it takes
the UV, but unsigned % seems to be buggy in perl 5.6.0 (it does a signed
% instead).
-- This would seem to be consistent. Thanks for the hints about
Devel::Peek::Dump. I can see a good workaround for this now.
Dazza.
------------------------------
Date: Sun, 10 Sep 2006 22:56:56 +0100
From: "Don Corleone" <don@mastah.com>
Subject: exec command issue
Message-Id: <VaOdnWs-KI_9F5nYRVny2w@giganews.com>
Hey All
I got a simple program that reads an file listing using the dos dir command
and then performs another exec on each file name in the list. Problem is
perl doesnt seem to run the second dos command. ?
Any help appreciated.
# Get a list of all the files in the directory
#
print STDOUT "Enter path: ";
$path = <STDIN>;
exec("dir/b /od *.tif $path");
$result = `PROGRAM`;
# Process each file
while (<>) {
chomp;
@Line = split "\t",$_;
exec("bong $_ );
#bong if a dos program for converting tif files to jpg files.
#exec("ocr --pdf 1.tif \n");
#print "Pdf File created: \n";
}
------------------------------
Date: 10 Sep 2006 15:08:43 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: localtime is now wrong after server change
Message-Id: <4mio3rF6bm98U1@news.dfncis.de>
Jason <jwcarlton@gmail.com> wrote in comp.lang.perl.misc:
> Until recently, my site was on a remote-hosted shared server; as of
> today, I've completely upgraded to a dedicated.
What's a shared server and what's dedicated? This newsgroup is
about Perl, not remote hosting.
> I use to use the following to determine the timestamp for my forum:
>
> ($sec, $min, $hour, $day, $mon, $year, $wday) = (localtime(time +
> (60*60)))[0,1,2,3,4,5,6];
^^^^^^
This adds an hour to the time value. You have no idea why you are
doing this, do you?
> $month = $mon + 1;
> $year += 1900;
>
> $today = "$year";
> if ($month < 10) { $today .= "0"; }
> $today .= "$month";
> if ($day < 10) { $today .= "0"; }
> $today .= "$day";
>
> if ($hour < 10) { $hour = "0" . $hour; }
> if ($min < 10) { $min = "0" . $min; }
> if ($sec < 10) { $sec = "0" . $sec; }
>
> $thistimestamp = $year . $month . $day . $hour . $min . $sec; # eg,
> 20060910040541
>
>
> But after my server change, my hour is now an hour greater than it
> should be (if it's 10am, this code states that it's 11am). I can't
> figure out why, though, because through WHM, my server time matches my
> local time.
What's WHM?
If you can't figure out the difference that means you either haven't
bothered to look at your own code or you don't understand it. You
are adding an hour yourself, for whatever reason.
> What's the quickest way to decrease this code by an hour? Currently,
> all posts in my forum are going to have to be corrected by hand (and I
> get, on average, 1 post every 3 minutes), so I'm more concerned with
> modifying the code quickly than anything else.
Get rid of the hour you are adding to the time value.
Your time manipulation routine looks like it's copied from Matt's
script archive, which means it looks like the work of a talented
sixteen-year-old who has just begun learning Perl.
Learn about POSIX::strftime and related functions. Without checking
every detail I'm sure you can generate your time format directly.
Anno
------------------------------
Date: Sun, 10 Sep 2006 17:22:58 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: localtime is now wrong after server change
Message-Id: <slrneg8beo.em6.hjp-usenet2@yoyo.hjp.at>
On 2006-09-10 14:38, Jason <jwcarlton@gmail.com> wrote:
> Until recently, my site was on a remote-hosted shared server; as of
> today, I've completely upgraded to a dedicated.
>
> I use to use the following to determine the timestamp for my forum:
>
> ($sec, $min, $hour, $day, $mon, $year, $wday) = (localtime(time +
> (60*60)))[0,1,2,3,4,5,6];
[...]
> But after my server change, my hour is now an hour greater than it
> should be (if it's 10am, this code states that it's 11am). I can't
> figure out why, though, because through WHM, my server time matches my
> local time.
>
> What's the quickest way to decrease this code by an hour?
How about removing the "+ (60*60)" in the code above? It looks like
previously someone couldn't be bothered to configure the timezone
correctly and just added 60 minutes to the time.
> Currently, all posts in my forum are going to have to be corrected by
> hand (and I get, on average, 1 post every 3 minutes), so I'm more
> concerned with modifying the code quickly than anything else.
This is the attitude that got you in this mess. If something doesn't
work, find out why it doesn't work and fix the cause instead of fiddling
with the symptoms.
hp
--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd
------------------------------
Date: Sun, 10 Sep 2006 15:44:49 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: localtime is now wrong after server change
Message-Id: <Xns983A776F879DBasu1cornelledu@127.0.0.1>
"Jason" <jwcarlton@gmail.com> wrote in news:1157899110.648602.211210
@b28g2000cwb.googlegroups.com:
> Until recently, my site was on a remote-hosted shared server; as of
> today, I've completely upgraded to a dedicated.
>
> I use to use the following to determine the timestamp for my forum:
>
> ($sec, $min, $hour, $day, $mon, $year, $wday) = (localtime(time +
> (60*60)))[0,1,2,3,4,5,6];
Here. you are adding one hour to the current time.
> $month = $mon + 1;
> $year += 1900;
Here it is obvious that you are not using strict.
> $today = "$year";
perldoc -q always
> if ($month < 10) { $today .= "0"; }
> $today .= "$month";
> if ($day < 10) { $today .= "0"; }
> $today .= "$day";
>
> if ($hour < 10) { $hour = "0" . $hour; }
> if ($min < 10) { $min = "0" . $min; }
> if ($sec < 10) { $sec = "0" . $sec; }
All of this is crazy stupid.
#!/usr/bin/perl
use strict;
use warnings;
sub timestamp {
my ($sec, $min, $hour, $mday, $mon, $year) = (localtime)[0 .. 5];
sprintf(
'%4.4d%2.2d%2.2d%2.2d%2.2d%2.2d',
$year + 1900, $mon + 1, $mday, $hour, $min, $sec,
);
}
print timestamp(), "\n";
__END__
Or, just use POSIX::strftime as recommended.
> But after my server change, my hour is now an hour greater than it
> should be (if it's 10am, this code states that it's 11am). I can't
> figure out why,
Because you are adding one hour to the current time. How hard is that to
figure out?
> though, because through WHM
WTF is WHM?
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Sun, 10 Sep 2006 11:44:35 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: localtime is now wrong after server change
Message-Id: <slrneg8g7j.go1.tadmc@magna.augustmail.com>
Jason <jwcarlton@gmail.com> wrote:
> $today = "$year";
perldoc -q vars
What's wrong with always quoting "$vars"?
So make that:
$today = $year;
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 10 Sep 2006 11:20:55 -0700
From: "Matt Garrish" <mgarrish@gmail.com>
Subject: Re: localtime is now wrong after server change
Message-Id: <1157912455.612628.167140@m79g2000cwm.googlegroups.com>
A. Sinan Unur wrote:
> "Jason" <jwcarlton@gmail.com> wrote in news:1157899110.648602.211210
> @b28g2000cwb.googlegroups.com:
>
> > Until recently, my site was on a remote-hosted shared server; as of
> > today, I've completely upgraded to a dedicated.
> >
> > I use to use the following to determine the timestamp for my forum:
> >
> > ($sec, $min, $hour, $day, $mon, $year, $wday) = (localtime(time +
> > (60*60)))[0,1,2,3,4,5,6];
>
>
> > But after my server change, my hour is now an hour greater than it
> > should be (if it's 10am, this code states that it's 11am). I can't
> > figure out why,
>
> Because you are adding one hour to the current time. How hard is that to
> figure out?
>
> > though, because through WHM
>
> WTF is WHM?
>
Wimpering hopeless moron? Oh wait, it wasn't in reference to himself. I
assume he means his web host management console, but one more reason I
hate when people use acronyms...
Matt
------------------------------
Date: 10 Sep 2006 08:24:59 -0700
From: "jc" <jc_usernet@aanet.com.au>
Subject: Perl - serial input and buffering problem
Message-Id: <1157901899.713950.220270@i42g2000cwa.googlegroups.com>
Hello.
I'm inputting from a barcode reader to a serial port (with Active State
PERl 5.6.1 and using W2000). This sends strings similar to;
"abcdefg<cr>"
(ie a string with a carriage return on the end).
My problem is that the string presented in the Perl program is always 1
behind the current string just scanned.
I'm using code similar to;
############################
$/ = "\r"; # Set up the record separator
open( FRED, "+>COM1" ) or die "error message";
my $mystring;
$mystring = <FRED>;
print $mystring;
############################
Regards JC......
------------------------------
Date: Sun, 10 Sep 2006 16:32:31 GMT
From: Bob Walton <see.sig@rochester.rr.com>
Subject: Re: Perl - serial input and buffering problem
Message-Id: <z6XMg.40473$8j3.11415@twister.nyroc.rr.com>
jc wrote:
> Hello.
> I'm inputting from a barcode reader to a serial port (with Active State
> PERl 5.6.1 and using W2000). This sends strings similar to;
> "abcdefg<cr>"
> (ie a string with a carriage return on the end).
>
>
> My problem is that the string presented in the Perl program is always 1
> behind the current string just scanned.
>
> I'm using code similar to;
> ############################
> $/ = "\r"; # Set up the record separator
>
> open( FRED, "+>COM1" ) or die "error message";
> my $mystring;
> $mystring = <FRED>;
> print $mystring;
> ############################
>
> Regards JC......
>
You will probably have better results if you
use Win32::SerialPort;
It seems to deal well with all the foibles of the Windows implementation
of serial ports. HTH.
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
------------------------------
Date: 10 Sep 2006 09:04:48 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
To: anno4000@radom.zrz.tu-berlin.de
Subject: Re: scalar to method name
Message-Id: <867j0bemhr.fsf@blue.stonehenge.com>
>>>>> "anno4000" == anno4000 <anno4000@radom.zrz.tu-berlin.de> writes:
anno4000> That's true, but how is it relevant? The expression contains three
anno4000> variables, each of which could be user-determined and have malicious
anno4000> content. Just how malicious it could get can't be determined
anno4000> without knowing which subs and methods exist in the environment and
anno4000> also which freedom, if any, the user has in determining the
anno4000> variables.
anno4000> Why does $method need special attention?
Because Perl got a black eye because SOAP::Lite permitted an exploit
permitting anyone to run any command they chose if they had implemented *any*
web service with SOAP::Lite. Ouch. And this was the vector.
That's the kind of thing those of us in the core Perl community don't quickly
forget, so if we seem a bit gunshy about a certain construct, it's with
reason.
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
--
Posted via a free Usenet account from http://www.teranews.com
Warning: Do not use Ultimate-Anonymity
They are worthless spammers that are running a scam.
------------------------------
Date: 10 Sep 2006 16:42:59 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: scalar to method name
Message-Id: <4mitkjF6bv32U1@news.dfncis.de>
Randal L. Schwartz <merlyn@stonehenge.com> wrote in comp.lang.perl.misc:
> >>>>> "anno4000" == anno4000 <anno4000@radom.zrz.tu-berlin.de> writes:
>
> anno4000> That's true, but how is it relevant? The expression contains three
> anno4000> variables, each of which could be user-determined and have malicious
> anno4000> content. Just how malicious it could get can't be determined
> anno4000> without knowing which subs and methods exist in the environment and
> anno4000> also which freedom, if any, the user has in determining the
> anno4000> variables.
>
> anno4000> Why does $method need special attention?
>
> Because Perl got a black eye because SOAP::Lite permitted an exploit
> permitting anyone to run any command they chose if they had implemented *any*
> web service with SOAP::Lite. Ouch. And this was the vector.
>
> That's the kind of thing those of us in the core Perl community don't quickly
> forget, so if we seem a bit gunshy about a certain construct, it's with
> reason.
Still it isn't the construct per se that's dangerous. Allowing
insufficiently controlled input to be used in a program is dangerous.
It may be more critical in some constructs than others, but it shouldn't
be the construct but the fact that a variable with uncontrolled content
is used *anywhere* that triggers an alert.
Only the OP knows the origin of the xml(?) file the variable is read
from. It may be as safe as the program source.
Anno
------------------------------
Date: Sun, 10 Sep 2006 20:17:00 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: scalar to method name
Message-Id: <slrneg8ll2.jd4.hjp-usenet2@yoyo.hjp.at>
On 2006-09-10 16:42, anno4000@radom.zrz.tu-berlin.de <anno4000@radom.zrz.tu-berlin.de> wrote:
> Randal L. Schwartz <merlyn@stonehenge.com> wrote in comp.lang.perl.misc:
>> >>>>> "anno4000" == anno4000 <anno4000@radom.zrz.tu-berlin.de> writes:
>> anno4000> Why does $method need special attention?
>>
>> Because Perl got a black eye because SOAP::Lite permitted an exploit
>> permitting anyone to run any command they chose if they had implemented *any*
>> web service with SOAP::Lite. Ouch. And this was the vector.
>>
>> That's the kind of thing those of us in the core Perl community don't quickly
>> forget, so if we seem a bit gunshy about a certain construct, it's with
>> reason.
>
> Still it isn't the construct per se that's dangerous. Allowing
> insufficiently controlled input to be used in a program is dangerous.
> It may be more critical in some constructs than others, but it shouldn't
> be the construct but the fact that a variable with uncontrolled content
> is used *anywhere* that triggers an alert.
You have to use a variable with uncontrolled content *somewhere* if you
want to write useful programs in the real world. Almost any input to a
program is outside of the control of the programmer and very often
outside of the control of the person running the program. Yet the
program has to deal with such data. An alert on any use of such data
would not be useful. Some operations on the data are safe: E.g.,
matching a regexp against it, or writing it to a file. Others are unsafe
(e.g. open or eval).
Taint checking tries to distinguish between safe and unsafe operations.
That said, I wonder why taint checking doesn't catch this (at least with
perl 5.8.8)?
#!/usr/local/bin/perl -T
use warnings;
use strict;
my $x = X->new();
my $m = $ARGV[0];
$x->$m();
package X;
sub new {
my ($class) = @_;
my $self = {};
bless $self, $class;
return $self;
}
sub foo {
print "foo\n";
}
sub bar {
print "bar\n";
}
package Y;
sub gazonk {
print "gazonk\n";
}
hp
--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd
------------------------------
Date: 10 Sep 2006 19:13:27 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: scalar to method name
Message-Id: <4mj6enF6dn5oU1@news.dfncis.de>
Peter J. Holzer <hjp-usenet2@hjp.at> wrote in comp.lang.perl.misc:
> On 2006-09-10 16:42, anno4000@radom.zrz.tu-berlin.de
> <anno4000@radom.zrz.tu-berlin.de> wrote:
> > Randal L. Schwartz <merlyn@stonehenge.com> wrote in comp.lang.perl.misc:
> >> >>>>> "anno4000" == anno4000 <anno4000@radom.zrz.tu-berlin.de> writes:
> >> anno4000> Why does $method need special attention?
> >>
> >> Because Perl got a black eye because SOAP::Lite permitted an exploit
> >> permitting anyone to run any command they chose if they had implemented *any*
> >> web service with SOAP::Lite. Ouch. And this was the vector.
> >>
> >> That's the kind of thing those of us in the core Perl community don't quickly
> >> forget, so if we seem a bit gunshy about a certain construct, it's with
> >> reason.
> >
> > Still it isn't the construct per se that's dangerous. Allowing
> > insufficiently controlled input to be used in a program is dangerous.
> > It may be more critical in some constructs than others, but it shouldn't
> > be the construct but the fact that a variable with uncontrolled content
> > is used *anywhere* that triggers an alert.
>
> You have to use a variable with uncontrolled content *somewhere* if you
> want to write useful programs in the real world. Almost any input to a
> program is outside of the control of the programmer and very often
> outside of the control of the person running the program. Yet the
> program has to deal with such data. An alert on any use of such data
> would not be useful. Some operations on the data are safe: E.g.,
> matching a regexp against it, or writing it to a file. Others are unsafe
> (e.g. open or eval).
>
> Taint checking tries to distinguish between safe and unsafe operations.
Well, there you are. When the program needs taint checking, treat
*every* content that doesn't come from the source as suspect. This
is exactly what taint checking tries to do, though not always perfectly
as your example below (now snipped) shows. Thus the problem can be
reduced to deciding whether a program needs taint checking.
I don't have a pat answer to that, though I think programmers develop
a reliable intuition in that respect. The question can't be decided
by looking at the program alone. Many programs assume to be run
from a shell and unconcernedly open and overwrite files given as
parameters. The user can do any damage within permissions, but
they can do that anyway through the shell. The same program, run
with parameters not from the command line but some, well, "foreign"
source, might need taint checking and other precautions. What exactly
constitutes "foreign" I find hard to define but easy to know when
I see it. Then, I'm nobody's security engineer, I'm not paid
to think about this stuff :)
Anno
------------------------------
Date: Sun, 10 Sep 2006 22:33:14 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: scalar to method name
Message-Id: <slrneg8tkg.lmb.hjp-usenet2@yoyo.hjp.at>
On 2006-09-10 19:13, anno4000@radom.zrz.tu-berlin.de <anno4000@radom.zrz.tu-berlin.de> wrote:
> Peter J. Holzer <hjp-usenet2@hjp.at> wrote in comp.lang.perl.misc:
>> On 2006-09-10 16:42, anno4000@radom.zrz.tu-berlin.de
>> <anno4000@radom.zrz.tu-berlin.de> wrote:
>> > Randal L. Schwartz <merlyn@stonehenge.com> wrote in comp.lang.perl.misc:
>> >> >>>>> "anno4000" == anno4000 <anno4000@radom.zrz.tu-berlin.de> writes:
>> >> anno4000> Why does $method need special attention?
>> >>
>> >> Because Perl got a black eye because SOAP::Lite permitted an exploit
>> >> permitting anyone to run any command they chose if they had implemented *any*
>> >> web service with SOAP::Lite. Ouch. And this was the vector.
>> >
>> > Still it isn't the construct per se that's dangerous. Allowing
>> > insufficiently controlled input to be used in a program is dangerous.
>> > It may be more critical in some constructs than others, but it shouldn't
>> > be the construct but the fact that a variable with uncontrolled content
>> > is used *anywhere* that triggers an alert.
>>
>> You have to use a variable with uncontrolled content *somewhere* if you
>> want to write useful programs in the real world. Almost any input to a
>> program is outside of the control of the programmer and very often
>> outside of the control of the person running the program. Yet the
>> program has to deal with such data. An alert on any use of such data
>> would not be useful. Some operations on the data are safe: E.g.,
>> matching a regexp against it, or writing it to a file. Others are unsafe
>> (e.g. open or eval).
>>
>> Taint checking tries to distinguish between safe and unsafe operations.
>
> Well, there you are. When the program needs taint checking, treat
> *every* content that doesn't come from the source as suspect.
Yes, every content from untrusted sources is suspect, but not every
operation on suspect content is unsafe. I think I (and probably Randal)
misunderstood your question "Why does $method need special attention?"
To recap, the code in question was $obj->$method(@args).
I understood your question as "why does calling a method with a user
supplied name need special attention?" and the reason has been explained
by Randal: You cannot call only methods of $obj's class but arbitrary
objects that way. So if you want to restrict the user to call only
$obj's class you have to check $method before the call.
OTOH, calling a method with unchecked arguments is not inherently
unsafe: The method can (and should) check the arguments.
> This is exactly what taint checking tries to do, though not always
> perfectly as your example below (now snipped) shows. Thus the problem
> can be reduced to deciding whether a program needs taint checking.
I was assuming a context which needs taint checking. Otherwise its
perfectly fine if you can call arbirtrary methods.
> I don't have a pat answer to that, though I think programmers develop
> a reliable intuition in that respect. The question can't be decided
> by looking at the program alone.
Right. The question can be decided by looking at the context in which
the program is executed: If the entity running the program does not
completely trust the entities supplying the input data, the data has to
be checked (that doesn't mean taint checking is needed: Taint checking
is just a tool to help the programmer to find places where he needs to
add checks).
Examples:
* A web server: Everybody can send arbitrary data to it. Clearly it
needs to check its input.
* A script invoked by a user on data which he has written himself: Input
checking should not be necessary, the user presumably trusts himself.
In reality, some input checking is still necessary, because the user
may have violated some assumptions that the programmer made: For
example, the programmer may have foolishly assumed that a filename
doesn't contain spaces. If he did that, he'd better check it, because
users will create filenames with spaces if they can.
* A script invoked by a user on data which he obtained from an untrusted
source (e.g., downloaded from a website, or received via email): Input
checking is necessary.
Which checks are necessary also depends on context. For simple
hp
--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd
------------------------------
Date: 10 Sep 2006 08:53:35 -0700
From: lul1@gmx.net
Subject: Re: Simple OpenGL script to exe failing
Message-Id: <1157903615.647270.8240@h48g2000cwc.googlegroups.com>
Already fixed.
An OpenGL.pm in my root-folder was conflicting. Removing it helped.
------------------------------
Date: Sun, 10 Sep 2006 17:28:32 +0200
From: Ch Lamprecht <christoph.lamprecht.no.spam@web.de>
Subject: Re: Tk::Checkbutton - text does not line up ...
Message-Id: <ee1av0$tej$1@online.de>
Dave wrote:
> "MoshiachNow" <lev.weissman@creo.com> wrote in message
> news:1157876721.088230.130660@m79g2000cwm.googlegroups.com...
>
>>HI,
>>
>>Using a function on Windows,I define a $test variable as following:
>>
>>$text=sprintf("%-35s %-13s",$_,'(directory)');
>>
>>Then define the checkbutton:
>>The text in $text DOES NOT get lined up !
>
>
> By default the text is 'center' anchored; you probably don't want this so
> try setting the -anchor option, e.g. anchor => 'w', as appropriate.
>
>
>
In addition you might consider using a fixed-width font to have the second part
of your label aligned vertically as well:
use strict;
use warnings;
use Tk;
my $mw = tkinit();
my @text =
map {sprintf("%-35s %-13s",$_,'(directory)')
} qw(test something_else);
my @buttons =
map {$mw->Checkbutton(-text => $text[$_],
-font=>[courier => 9]
)->pack(-anchor=>'w')
} (0,1);
MainLoop();
Christoph
--
perl -e "print scalar reverse q/ed.enilno@ergn.l.hc/"
------------------------------
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 9709
***************************************
