[25574] in Perl-Users-Digest
Perl-Users Digest, Issue: 7818 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 23 09:10:54 2005
Date: Wed, 23 Feb 2005 06:10:43 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 23 Feb 2005 Volume: 10 Number: 7818
Today's topics:
Re: BerkeleyDB locking question <admin@asarian-host.net>
Re: How to handle " use module qw/abc/ " in the module <mark.clements@kcl.ac.uk>
more backup script problems!?! <daninbrum@hotmail.com>
Re: more backup script problems!?! (Anno Siegel)
Perl DBI and Microsoft Access nathaniel_welch@hotmail.com
Re: Perl DBI and Microsoft Access <1usa@llenroc.ude.invalid>
Re: Perl Hash problem (with registry) <wyzelli@yahoo.com>
Solaris 8 and sh Configure (Flemming =?iso-8859-1?q?H=F8jstrup?= Hansen)
Re: standard mode for arrow down <xah@xahlee.org>
Re: unicode: é=>e, á=>a <jurgenex@hotmail.com>
Re: Write-Only Socket [OT] <news@chaos-net.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 23 Feb 2005 12:52:56 +0100
From: "Mark" <admin@asarian-host.net>
Subject: Re: BerkeleyDB locking question
Message-Id: <C86dnXwrBrIK84HfRVnygQ@giganews.com>
"Paul Marquess" <Paul.Marquess@btinternet.com> wrote in message
news:3833e5F5fj92fU1@individual.net...
>> Mark wrote:
>>
>> > I have a small locking question.
>>
>> Yes, you do need locking. You can find the underlying file
>> that the tie is using and use flock to lock it...
>
> If you want to use DB_File, an external lock file is the way to go, but
> for the BerkeleyDB module, you can get better locking semantics by using
> the locking provided by the underlying Berkele DB library.
>
> The simplest form of locking available in Berkeley DB is called
> Concurrent Data Store CDS. It allows single writer, multiple readers.
Just what the doctor ordered! :) Thank you!
> Here is the typical signature that is used when opening a database in
> CDS mode.
>
> or this, if you use the tied interface
>
>
> tie %hash, "BerkeleyDB::Hash",
>
> -Filename => 'test2.db',
>
> -Flags => DB_CREATE,
>
> -Env => $env
>
> or die "cannot open database: $BerkeleyDB::Error\n";
>
>
> Apart from that you don't need to do anything -- Berkeley DB handles the
> locking for you behind the scenes.
That is the impression I got (see my other post). Always a treat to have
the author answer himself. :)
Thanks,
- Mark
------------------------------
Date: Wed, 23 Feb 2005 12:06:41 +0100
From: Mark Clements <mark.clements@kcl.ac.uk>
Subject: Re: How to handle " use module qw/abc/ " in the module ?
Message-Id: <421c63c4$1@news.kcl.ac.uk>
Snail wrote:
>
> But how do you go about making which of these funcs to import
> selectable? As in wanting to just import Func1 or Func2? I've seen code
> that uses something like
>
> use Module qw/somefunc/;
You want to check out @EXPORT_OK and %EXPORT_TAGS.
Mark
------------------------------
Date: 23 Feb 2005 04:32:52 -0800
From: "Dan" <daninbrum@hotmail.com>
Subject: more backup script problems!?!
Message-Id: <1109161972.050690.14570@f14g2000cwb.googlegroups.com>
Group,
I'm having some problems with this colour based backup script (very
version follows message). It seams to cycle through the directory
structure fine, but when its faced with a big directory structure it
often falls over saying
'Is a directory at ./backuptest.pl line 35, <DATA> line 1.'
Any idea why? I am certain that no folder is colour marked red, and it
seams to fall over when its halfway through processing a sub-folder.
Any clues?
Thanks,
Daniel
#! /usr/bin/perl
use File::Find;
use File::Copy;
use Mac::Files;
$varDestination = '/Volumes/BACKUP/backups/';
$varVolume = '/Users/Fred/';
$varColour = "red";
my @colors = qw(*none* gray green purple blue yellow red orange);
find(\&process, $varVolume);
sub process {
$myFile = $File::Find::name;
($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,$atime,$mtime,$ctime,$blksize,$blocks)
= stat($myFile);
my $finfo = FSpGetFInfo($myFile);
if(ref($finfo) eq 'FInfo') {
my $finder_flags = $finfo->fdFlags;
my $color = ($finder_flags & kColor) >> 1;
print "\n" . $type;
$fileColour = $colors[$color];
}
if($fileColour eq $varColour) {
my $file = $File::Find::name;
copy($File::Find::name,$varDestination) or die "Copy failed: $!";
}
}
------------------------------
Date: 23 Feb 2005 13:28:13 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: more backup script problems!?!
Message-Id: <cvi0dd$e9a$2@mamenchi.zrz.TU-Berlin.DE>
Dan <daninbrum@hotmail.com> wrote in comp.lang.perl.misc:
> Group,
>
> I'm having some problems with this colour based backup script (very
> version follows message). It seams to cycle through the directory
> structure fine, but when its faced with a big directory structure it
> often falls over saying
>
> 'Is a directory at ./backuptest.pl line 35, <DATA> line 1.'
>
> Any idea why? I am certain that no folder is colour marked red, and it
> seams to fall over when its halfway through processing a sub-folder.
Well, find out what file (directory) it is complaining about. Change
copy($File::Find::name,$varDestination) or die "Copy failed: $!"
to
copy($File::Find::name,$varDestination) or
die "Copy of '$File::Find::name' to '$varDestination' failed: $!"
and you'll be a little wiser. It could be the destination that is
a directory.
Anno
------------------------------
Date: 23 Feb 2005 05:02:50 -0800
From: nathaniel_welch@hotmail.com
Subject: Perl DBI and Microsoft Access
Message-Id: <1109163770.786742.76130@z14g2000cwz.googlegroups.com>
I have several CGI scripts that interface with several Microsoft Access
databases using DBI. I just purchased space on a remote web server and
uplodaed all my files. It turns out that this server doesn't support
DBI. Can I simply copy the DBI::PurePerl module to a folder on my
server and the code continue to work with Access? I've been trying
this approach but I haven't been able to get it to work.
Thanks,
Nate
------------------------------
Date: Wed, 23 Feb 2005 13:08:33 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Perl DBI and Microsoft Access
Message-Id: <Xns960652D5D96FCasu1cornelledu@127.0.0.1>
nathaniel_welch@hotmail.com wrote in news:1109163770.786742.76130
@z14g2000cwz.googlegroups.com:
> I have several CGI scripts that interface with several Microsoft Access
> databases using DBI. I just purchased space on a remote web server and
> uplodaed all my files. It turns out that this server doesn't support
> DBI.
Well, I am not sure what you mean by they don't support DBI. Do they just
not have the DBI module installed, or is this a *nix system without DBD-
ODBC and an ODBC driver? If it is the latter, have you read the FAQ at
<URL: http://search.cpan.org/~jurl/DBD-ODBC-1.13/ODBC.pm>?
Sinan.
------------------------------
Date: Wed, 23 Feb 2005 11:20:50 GMT
From: "Peter Wyzl" <wyzelli@yahoo.com>
Subject: Re: Perl Hash problem (with registry)
Message-Id: <mGZSd.172438$K7.62550@news-server.bigpond.net.au>
<thomasjbs@yahoo.com> wrote in message
news:1109145747.375288.82950@g14g2000cwa.googlegroups.com...
: Getting strange error message: "Can't coerce array into hash at test.pl
: line 21 with the following code: (line 22 with added comment)
:
: I'm very new at using hashes and Perl on registry. The strange part is
: that it gets through processing about 50 items before the error occurs.
:
: The goal is to simply read the registy and print out a list of
: installed applications. Although there might be simple methods to do
: this, the secondary goal is to learn to use hashes.
:
: Apparently the data is stored as a hash inside a hash.
:
: Anyone know what's going on?
Maybe you have a problem in the registry? It seems to work on my system,
with several caveats:
:
: (run on Windows XP system with Activestate perl).
use warnings;
use strict;
# Will report a few little problems as detailed below.
: use Win32::Registry;
The docs say this is an obsolete module, use Win32::TieRegistry instead...
: my $Register =
: "Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall";
: my ($hkey, @key_list, $key, @klist);
@klist is declared here, but below you use %klist...
: $cnt = 0;
Here you set $cnt, and then never increment it...
: $HKEY_LOCAL_MACHINE->Open($Register,$hkey)|| die $!;
: $hkey->GetKeys(\@key_list);
: print "$Register keys\n";
: foreach $key (@key_list)
: {
: $tmpkey = $Register . "\\" . $key . $DisplayName;
$DisplayName is used without being declared and is a null value
: $HKEY_LOCAL_MACHINE->Open($tmpkey,$q) or next;
What do you expect $q to be at this point?
: $q->GetValues(\%klist);
:
: #print $klist{'Display Name'},"\n";
: while (($k,$d)=each(%klist)) {
: if (lc $k eq "display name") {
: print $tmpkey,"\n";
: print $d,"\n";;
: ### Error is next line ###
: $d = %$d;
: print $k," ",$d,"\n";
: #@e = %$d;
: }
: }
: $q->Close();
: # $cnt++;
:
: print "$key\n";
: }
: print $cnt;
: $hkey->Close();
My head hurts....
P
--
print "Just another Perl Hacker";
------------------------------
Date: 23 Feb 2005 13:38:24 +0100
From: fhh@hsk.dk (Flemming =?iso-8859-1?q?H=F8jstrup?= Hansen)
Subject: Solaris 8 and sh Configure
Message-Id: <y50k6ozcuyn.fsf@hsk.dk>
Newsgroups: comp.lang.perl.misc
Subject: sh Configure rm: ../UU is a directory
--text follows this line--
Machine: Sun Blade 1500
Operating System: Solaris 8
perl version: 5.8.6 (or 5.8.5)
Very quickly after I run:
sh Configure
I get the error message:
Sorry I can't seem to locate the source dir for perl5. Please start
Configure with an explicit path -- i.e. /some/path/Configure.
and the second time:
rm: ./UU is a directory
in front of the same error message.
I have seen the error message in Perl NG before but no explanation. Can
anyone tell me what's wrong?
TIA
Flemming
--
Flemming Højstrup Hansen
Hovedstadens Udviklingsråd
(Greater Copenhagen Authority)
------------------------------
Date: 23 Feb 2005 03:32:55 -0800
From: "Xah Lee" <xah@xahlee.org>
Subject: Re: standard mode for arrow down
Message-Id: <1109158375.609227.41180@o13g2000cwo.googlegroups.com>
Computing Folks of the industry:
please spread the debunking of the truncating line business of the
fucking unix-loving fuckheads, as outlines here:
http://xahlee.org/UnixResource_dir/writ/truncate_line.html
if this myth-debunking is known widely enough, there wouldn't be any
more line truncating business.
emacs community has always been a thinking community as opposed to the
unix criminals. However by historical happenstance, the emacs of GNU's
Not Unix is essentially a program for unixes, so unavoidable it has to
deal with and inherit some of the ill shits of unix, if for nothing but
to be practical.
However, as of today, emacs don't really have reason to have arrow-down
behavior to be dependent on the hard-coded line wraps. I want the next
emacs version's down-arrow behavior to be fixed. (and optionally as
another mode to move by EOL.)
The reason for this change is easy. For those habituated with hard
wrapped lines, this would cause no difference. However, for those who
have lines that return at logical places, this would be an improvement.
(This is the intuitive way, and all non-geek editors behave this way,
even most editors or IDEs designed for programing.)
The need in this change is significant. By the current behavior of
down-arrow by EOL char, it discourages logical line breaking,
encourages hard-coded line breaking, and engenders the huge and
wide-spread problems as a consequence (as partially detailed in the url
given above): Programs posted online are broken, the who-said-what
quoting systems are a mess to process and comprehend, and needless
complex programs that processes and re-process the hard-wrapped
lines... And also it seeds the bad notions by creation of a generation
of imperative languages based on hard-line wraps (such as many
languages's line comment; and cannot be nested), and the mis-directed
habit in IT of sizing software by EOL-counting. (both of these are
hindrances to functional programing.) Further, in programing there's
large chapters and energy spent on what's called "coding style", which
refers to the petty issue of when and how to press a return so the code
looks pretty. This ubiquitous "coding style" activity is helped by the
hard-wrap habit of thinking, which created these EOL-centric language
syntaxes in the first place. (when coding in a programing language, the
programer should never have to enter returns for the sake of
display-formatting. The language's syntax and the editor should be able
to _easily_ format the code on the fly by a simple parsing. 99.9999% of
EOL in codes today are there manually entered by programer so as to
make it "readible". And as a consequence of these EOL-centric languages
is that programing are focused on code by the lines, instead of logical
units. (a example of a language that is not EOL-centric is Mathematica,
which actually does 3D math typesetting on the fly as well as
auto-formatting the code with respect to line-wrap for display. Similar
languages are LISPs, but they did not push this idea further. (That is
to say, in LISP communities, they on occasion still do and talk about
the petty issues of manual return-pressing.)))
I hope the above is some elucidation on the hard-wrap and
line-truncation business. Please spread the info.
Xah
xah@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
------------------------------
Date: Wed, 23 Feb 2005 13:38:34 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: unicode: é=>e, á=>a
Message-Id: <uH%Sd.9326$QQ3.5988@trnddc02>
peter pilsl wrote:
[...]
> terminals. But I think it could be done a bit better by replacing
> common unicodes by their latin "nearbyes" like é=>e, á=>a ...
You may want to look into your terminology:
- letters like 'é' and 'á' are latin characters. Chinese or cyrillic or
arabic are not.
- letters like 'e' and 'a' are Unicode characters. What would be the use of
Unicode if ASCII weren't part of it?
Therefore what you wrote above doesn't make any sense.
> ps: in fact we have the trouble that some IE-apple cannot display
> unicode in dropdowns ...
Then I suggest you fix your apple (or is it a pear or peach?).
I have been working on internationalization of web software for the last 8
years and I can assure you, while IE has many flaws it surely can display
Unicode characters in dropdowns (even those outside of the ASCII range) just
fine provided you have the proper code page installed (which in turn is a
nobrainer for latin characters).
Hint: One frequent cause for trouble are external script files, where the
code pages for the root HTML file and the loaded JS or VB files don't agree,
e.g. the HTML page is encoded in UTF-8 but the JavaScript, that populates
the dropdown defaults to ISO-Latin-1. But this is way off topic in a Perl NG
and you may want to discuss this in a NG dedicated to web programming or IE.
jue
------------------------------
Date: Wed, 23 Feb 2005 13:33:32 +0100
From: Martin Kissner <news@chaos-net.de>
Subject: Re: Write-Only Socket [OT]
Message-Id: <slrnd1ou0s.56b.news@maki.homeunix.net>
Big and Blue wrote :
> Martin Kissner wrote:
>
>> If the socket is r/w the service might be potentially exploitable on the
>> application layer although the server is not supposed to read from the
>> socket.
>
> If it isn't going to read() (or readfrom()) then I'm not sure how you
> think you (or anyone else) could persuade it to do so.
>
This is true but In that case you have to trust that the implementation
is flawless and there are no side effects possible at all.
Security problems can arise because the developer or the user of a
software did not think about possibilities to "persuade" software to do
things it was not supposed to do.
In my opinion it would be better to not open a socket as long as it is
not needed at all.
If it is needed only for sending it would be a good thing to disallow
receives on the lowest possible level (the transport layer).
AFAIK at this point this is possible only for TCP connections, but I am
still learning.
Best Regards
Martin
--
perl -e '$|=1;&p(7.74.117.115.116.32);&s();&p(97.110.111);&p(116.104.101
.114);&s;&p(32.112.101.114.108);&s();&p(32.104.97.99.107.101.114.10);sub
s{sleep 1};sub p(){print "@_"}'
------------------------------
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 7818
***************************************
