[21810] in Perl-Users-Digest
Perl-Users Digest, Issue: 4014 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Oct 23 09:05:39 2002
Date: Wed, 23 Oct 2002 06:05:13 -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 Wed, 23 Oct 2002 Volume: 10 Number: 4014
Today's topics:
Re: [Q] An associative array of file handles <krahnj@acm.org>
Re: [REPOST] Need advice on a project (wrt to tie'ing t (Sam Holden)
Re: [REPOST] Need advice on a project (wrt to tie'ing t <bart.lateur@pandora.be>
Re: [REPOST] Need advice on a project (wrt to tie'ing t <bart.lateur@pandora.be>
Re: Array List Output <mfg@ee.ed.ac.uk>
Re: Array List Output <bart.lateur@pandora.be>
change font in perl/tk? <jackkon@ms29.url.com.tw>
Re: deleting a file... kill ??? Thanks... (Helgi Briem)
Re: deleting a file... kill ??? Thanks... <nobull@mail.com>
Re: deleting a file... kill ??? Thanks... <bart.lateur@pandora.be>
Re: deleting a file... kill ??? Thanks... <bart.lateur@pandora.be>
Re: deleting a file... kill ??? Thanks... <dantie@gmx.at>
Re: deleting a file... kill ??? Thanks... (Helgi Briem)
Re: deleting a file... kill ??? <bart.lateur@pandora.be>
Re: exclusive execution of a perl script <saketrungta@hotmail.com>
Re: exclusive execution of a perl script <bart.lateur@pandora.be>
Re: format to output <nospam@nospam.org>
get workarea in perl/tk? <jackkon@ms29.url.com.tw>
Re: Hiding password variables in PERL <dantie@gmx.at>
Maintaining compatibility throughout several Perl-versi <tassilo.parseval@post.rwth-aachen.de>
Optmization of the exe generated by perlcc <lcdn@inwind.it>
Re: Passing array in the middle of the parrameter list <krahnj@acm.org>
problems save hash to file with dmopen (Samppa)
Re: Separating stdout and stderr (Anno Siegel)
Re: warnings::register and inheritance (Anno Siegel)
Re: warnings::register and inheritance <nobull@mail.com>
Re: warnings::register, no warnings, and inheritance <nobull@mail.com>
Re: warnings::register, no warnings, and inheritance (Anno Siegel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 23 Oct 2002 09:17:20 GMT
From: "John W. Krahn" <krahnj@acm.org>
Subject: Re: [Q] An associative array of file handles
Message-Id: <3DB66930.AD86CCBF@acm.org>
Morden wrote:
>
> Suppose I want to write snippets to files instead of pooling the text in
> memory ($logtext associative array).
If your data was sorted by store number (your hash key) this would be
possible.
> Is it doable to have an associative
> array of filehandles?
Yes.
> Is it worth the trouble? The size of associative
> array could exceed the number of handles in the OS. Is it handled by
> Perl under the covers?
No. Perl has to get its file handles from the OS.
> #!/usr/bin/perl
#!/usr/bin/perl -w
use strict;
> if($ARG = shift(@ARGV)) {
This won't work if you happen to have a file named "0".
if ( defined( my $ARG = shift ) ) {
> open(STDIN, "$ARG") || die("can't open file $ARG\n");
Why are you using the STDIN filehandle? There is no need to put a
scalar variable in quotes, this isn't a shell script. You should
include the $! variable in the error message so you know why open
failed.
> $ARG .= ".";
> } else {
> # alternatively it could be "stdin."
> $ARG="";
> }
>
> while($_=<>) {
If you are going to use the special null filehandle you should leave the
file names in @ARGV and perl will open the file(s) for you. If you want
to open the file yourself you should use a filehandle other then STDIN.
> ($n1,$n2,$store,$therest) = split(/\t/, $_);
If you only need one field you can use undef as a placeholder for the
fields you don't need.
my(undef,undef,$store) = split /\t/;
Or you can coerce split to return a single field.
my $store = (split /\t/)[2];
> # remove doublequotes around store number
> $store =~ s/"//g;
You could always combine this with the split.
my $store = (split /"?\t"?/)[2];
> if("$store" ne "") {
There is no need to put a scalar variable in quotes, this isn't a shell
script.
> $logtext{$store} .= $_;
If the value of $store is equal to "" then concatenating it won't cause
a problem so the if statement isn't required.
> }
> }
>
> foreach $key (sort keys(%logtext)) {
> #print "$key\n";
> open(OUT, ">$ARG$key") || die("can't open file $ARG$key\n");
> print OUT "$logtext{$key}";
> close(OUT);
> }
You could do it this way without multiple filehandles or a hash:
#!/usr/bin/perl -w
use strict;
die "usage: $0 filename\n" unless @ARGV;
while ( <> ) {
my $store = (split /"?\t"?/)[2];
if ( open OUT, ">> $ARGV.$store" ) {
print OUT;
close OUT;
}
}
__END__
John
--
use Perl;
program
fulfillment
------------------------------
Date: 23 Oct 2002 08:02:37 GMT
From: sholden@flexal.cs.usyd.edu.au (Sam Holden)
Subject: Re: [REPOST] Need advice on a project (wrt to tie'ing to a file and general strategy)
Message-Id: <slrnarclst.k4b.sholden@flexal.cs.usyd.edu.au>
On Wed, 23 Oct 2002 08:29:05 +0200,
Michele Dondi <bik.mido@tiscalinet.it> wrote:
> On Tue, 22 Oct 2002 07:25:06 GMT, Bart Lateur <bart.lateur@pandora.be>
> wrote:
>
>>A tied hash 5berkely style DB) is IMO an excellent choice for this kind
>>of application. See `perldoc AnyDBM_File` for a generic intro. In
>>general, the database itself cannot be moved to another platform,
>>because of binary incompatibilities, but the data is meaningless on
>>another platform anyway. At least the code will be portable.
>
> Sorry, but I'm really ignorant here. I thought that to use the DB_File
> module I had to get a system library and was not sure if it were
> available under non-*nix systems.
>
> Actually I was surprised to find that Mrs Activestate's ppm gently
> provided me with a ready to use dll...
>
> However, I can accept that the database cannot be moved to another
> platform (what else can I do?), but I really can't understand the
> reason why. That is, for example, jpeg is a binary format too, but it
> can be written both on unices and on Windoze and on many other OSes!
The DB library uses platform specifics in the database. Things like
the endianness of the machine, and the size of ints. That means a
database created on one machine isn't necessarily readable on another.
> So, why isn't there a cross-platform db format? Also, what does it
> mean that "data is meaningless on another platform anyway": in my case
> I would have to do with paths, numbers and checksums. Nothing too
> exotic or platform-dependent (directory separator apart, of course,
> but not too much also in this case for what regards perl) IMHO.
One reason *DBM isn't made cross platform is that the performance
trade off (no longer being able to directly copy data from the file
to memory) isn't considered worth the benefit. After all you can
just read the data and write it out in a transport format (text for
example) and create a *DBM database in on the target machine. Well
I think anyway, not being the designer/author I'm just guessing.
--
Sam Holden
------------------------------
Date: Wed, 23 Oct 2002 09:22:41 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: [REPOST] Need advice on a project (wrt to tie'ing to a file and general strategy)
Message-Id: <ulpcrus3sde2n4puqgjog4vhi5umdhsbgt@4ax.com>
Michele Dondi wrote:
>I still have some questions: as you might have read I had thought of
>using a hash whose values are array refences. In any case it seems
>that I can't have a tied hash of arrays, can I?!?
Yes you can. There's a module especially for this, I forgot the name...
something with 5 letters. MLDBM? Yup, that appears to be it.
<http://search.cpan.org/search?query=mldbm&mode=all>
The idea is that the multilevel data, like this array in the hash, is
"serialized", i.e. turned into a plain string. Modules like Storable and
Data::Dumper can be used for that. That way, the result is just a
string, which can be saved in the old, familiar way. In their bare form,
you can use these modules to save complex Perl data structures in an
ordinary file. MLDBM uses one of these behind the scenes, so you don't
have to worry about the details.
Hey, there's a thought: use Storable to save the entire (ordinary) hash
in a binary file! You need enough memory to keep all the data in memory
at once, but that may be feasable. And with the n* methods tostore the
data, thus: nstore(), you can even get portable files.
--
Bart.
------------------------------
Date: Wed, 23 Oct 2002 09:27:02 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: [REPOST] Need advice on a project (wrt to tie'ing to a file and general strategy)
Message-Id: <7kqcru4lq7b1a189sf4pvfvcklvm895c3k@4ax.com>
Sam Holden wrote:
>> However, I can accept that the database cannot be moved to another
>> platform (what else can I do?), but I really can't understand the
>> reason why. That is, for example, jpeg is a binary format too, but it
>> can be written both on unices and on Windoze and on many other OSes!
>
>The DB library uses platform specifics in the database. Things like
>the endianness of the machine, and the size of ints. That means a
>database created on one machine isn't necessarily readable on another.
That's right. You can blame C, which is used to compile the database
engine for that. C tends to use pretty abstract names for its data
types, like int(), which physically are stored in the for the machine
most efficient way, but with no garantees at all about portability. So
all bets on endianness, or number of bits per integer, are off.
It is often possible to compile a database engine to use a portable file
format, but with a bad impact on efficiency. Speed could easily halve.
--
Bart.
------------------------------
Date: Wed, 23 Oct 2002 11:28:46 +0000 (UTC)
From: Michael F Gordon <mfg@ee.ed.ac.uk>
Subject: Re: Array List Output
Message-Id: <ap615e$ja1$1@scotsman.ed.ac.uk>
dennis100@webtv.net (BUCK NAKED1) writes:
>I have the following list in an array.
>@dirs = ("home/", "user/", "demo/", "style/");
>I want to print out the following from the above array.
>home/
>home/user/
>home/user/demo/
>home/user/demo/style/
foreach (0..$#dirs) {
print @dirs[0..$_],"\n";
}
Michael
--
Quidquid latine dictum sit, altum viditur.
------------------------------
Date: Wed, 23 Oct 2002 12:34:04 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: Array List Output
Message-Id: <oo5dru0nnq6sbkmepjp9iiib6qqh843fsb@4ax.com>
BUCK NAKED1 wrote:
>@dirs = ("home/", "user/", "demo/", "style/");
>
>I want to print out the following from the above array.
>
>home/
>home/user/
>home/user/demo/
>home/user/demo/style/
for my $i (0 .. $#dirs) {
print join "", @dirs[0 .. $i], "\n";
}
I've already used a similar approach to iteratively create all necessary
subdirectories for copying a file to a possibly not yet existing
directory:
$dest = '/home/user/demo/style/file.ext';
@dirs = split '/', $dest; pop @dirs;
local $" = '/';
for my $i (1 .. $#dirs) {
mkdir "@dirs[0 .. $i]", 0777;
}
use File::Copy;
copy $src, $dest;
--
Bart.
------------------------------
Date: Wed, 23 Oct 2002 17:12:10 +0800
From: "jackkon" <jackkon@ms29.url.com.tw>
Subject: change font in perl/tk?
Message-Id: <ap5pme$4h4@netnews.hinet.net>
Hi
My OS is Win2000.
How can I modify the font property in parent widget and
the other children widgets follow the parent's font as default?
Thanks
------------------------------
Date: Wed, 23 Oct 2002 11:14:53 GMT
From: helgi@decode.is (Helgi Briem)
Subject: Re: deleting a file... kill ??? Thanks...
Message-Id: <3db6820a.633114911@news.cis.dfn.de>
On Wed, 23 Oct 2002 01:15:22 GMT, "Jürgen Exner"
<jurgenex@hotmail.com> wrote:
>G.Doucet wrote:
>> Wouldn't you think that my book's index would have had an
>> entry on deleting files?
>
>PS: Wouldn't you think that the Perl documentation is a better
>source for information about a specific function than some book?
On this precise subject I tend to agree with G. Doucet, if
only because perldoc -q delete does not return anything
relevant to deleting files.
For that matter, neither do the keywords 'rm', 'remove',
'unlink' nor 'file'.
Only if you already know that unlink is the perl function
for deleting files can you find out how to use it, in which
case you don't need it. I would never in a million years
have guessed that unlink was used to delete files
except that I came across it in a book I was reading
in the "reading room".
Our old production code in this company is littered with
thousands of
system ("/bin/rm -f $file") == 0 or die $?;
because around here nobody knew about unlink and
were unable to guess. Even looking over the functions
in the file category, I would imagine no one guessed
that unlink was for deleting files.
I still don't really understand why someone decided to call
it unlink and not rm or delete or remove or something.
PS.
brian, would it be possible to add a FAQ entry, something
like:
"How do I delete a file?"
Use the unlink function documented in perldoc -f unlink
--
Regards, Helgi Briem
helgi AT decode DOT is
A: Top posting
Q: What is the most irritating thing on Usenet?
- "Gordon" on apihna
------------------------------
Date: 23 Oct 2002 12:50:51 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: deleting a file... kill ??? Thanks...
Message-Id: <u9bs5l9xwk.fsf@wcl-l.bham.ac.uk>
helgi@decode.is (Helgi Briem) writes:
> On Wed, 23 Oct 2002 01:15:22 GMT, "Jürgen Exner"
> <jurgenex@hotmail.com> wrote:
>
> >G.Doucet wrote:
> >> Wouldn't you think that my book's index would have had an
> >> entry on deleting files?
>
> >PS: Wouldn't you think that the Perl documentation is a better
> >source for information about a specific function than some book?
That depends if "Some book" is the Camel Book.
If you look up "deleting files" in this index of the Camel it will, of
course, take you to the unlink() function.
> On this precise subject I tend to agree with G. Doucet, if
> only because perldoc -q delete does not return anything
> relevant to deleting files.
The FAQ is not the primary documentation and cannot answer everything.
If you want to delete a file your first guess may be to look for a
function delete(). You'll find that the delete() fuction has nothing
to do with files.
Your next obvious step would be one of:
1) Look for all occourances of the word 'delete' in the 'perlfunc'
manual. Withing a couple of minuites you'll come upon the
statement "unlink Deletes a list of files".
2) Look systematically through perlfunc. By systematically I mean
start at "Perl Functions by Category". Next realise that the
probable category would be "Functions for filehandles, files, or
directories". Finally read the first sentence of the description
of each function listed therein.
3) A google groups search "group:comp.lang.perl* delete file". I
just tried this and found it wasn't very successful.
4) A google web search for "perl delete file".
These are basic skills in finding information. I don't see that
there's any point writing documentation with an assumption that the
reader lacks such basic skills. To do so will make the documentation
way to cumbersome for the majority.
> I still don't really understand why someone decided to call
> it unlink and not rm or delete or remove or something.
The Perl unlink() is called unlink because that's what it's called in
C because that's what it is called in Unix because that's what it does
in Unix.
In Unix unlink() unlinks a file from the directory structure. In Unix
you cannot explicitly delete a file. Unix will GC the file once there
are no links and no process has it open.
> PS.
> brian, would it be possible to add a FAQ entry, something
> like:
>
> "How do I delete a file?"
> Use the unlink function documented in perldoc -f unlink
IMHO the FAQ should only document things that really are frequently
asked or cannot easily be found by systematic use of the primary
reference manuals. I think this questions falls just short of
qualifying on either count.
What would be really usefull would be a mention in the "perldoc -f
delete" that if you are looking for a function to delete files you
should be looking at unlink().
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Wed, 23 Oct 2002 12:37:39 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: deleting a file... kill ??? Thanks...
Message-Id: <tt5druk34lucn9epbtcc4qnq6ol94ebaml@4ax.com>
G.Doucet wrote:
>I have absolutely no idea where or how I came up with the kill statement.
Because other languages may use this name. I'd think of VB, for example.
--
Bart.
------------------------------
Date: Wed, 23 Oct 2002 12:41:06 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: deleting a file... kill ??? Thanks...
Message-Id: <426druc5p5pc8c8aqes9hlngrnirqd0jpm@4ax.com>
Helgi Briem wrote:
>I still don't really understand why someone decided to call
>it unlink and not rm or delete or remove or something.
Because on Unix, it is not garanteed to delete a file. You can have more
than one hard connections (links) between the name of the file in the
filesystem, and the contents. and unlink deletes *one* such entry. Only
if *all* these name entries are deleted, the file contents itself gets
wiped.
Of course, on Windows, this is an alien concept. There, there is a
one-to-one connection between the file path/name and the contents.
--
Bart.
------------------------------
Date: Wed, 23 Oct 2002 14:42:17 +0200
From: Daniel Tiefnig <dantie@gmx.at>
Subject: Re: deleting a file... kill ??? Thanks...
Message-Id: <3db69a03$0$21188$91cee783@newsreader02.highway.telekom.at>
Helgi Briem wrote:
> because around here nobody knew about unlink and were unable to guess.
I can't believe that.
> Even looking over the functions in the file category, I would imagine
> no one guessed that unlink was for deleting files.
Yer all Windows users, aren't you? :o)
> I still don't really understand why someone decided to call
> it unlink and not rm or delete or remove or something.
1.) Historical - e.g. C has an unlink() too.
2.) Logical - under UNIX environments, "deleting" a file is often
referred to as "unlinking" it, because that's actually what you are
doing. "Deleting" a file (Under Windows or UNIX) doesn't *delete*
anything, it just unlinks the name of the file from the data itself.
Further is there a thing called "hard links" supported by most (all?)
UNIXish Filesystems. A file may have more than one name. If e.g.
there's /foo/bar and /foo/baz, both filenames may refer to the same
file. If you unlink /foo/bar, nothing happens, except the /foo/bar Link
is no longer accessible. (And the link-count of the file is decreased.)
If you delete /foo/baz too, and there's no further Link available for
the file, (Link-count is zero.) the diskspace it used is freed and can
be used again, but still nothing is deleted, actually.
lg,
daniel
--
Top 10 Things to say, when you run out of good arguments:
No 9) Yes, yes, we've all read DJB's RFCs on the subject.
------------------------------
Date: Wed, 23 Oct 2002 12:58:24 GMT
From: helgi@decode.is (Helgi Briem)
Subject: Re: deleting a file... kill ??? Thanks...
Message-Id: <3db69b7b.639627876@news.cis.dfn.de>
On Wed, 23 Oct 2002 12:41:06 GMT, Bart Lateur
<bart.lateur@pandora.be> wrote:
>Helgi Briem wrote:
>
>>I still don't really understand why someone decided to call
>>it unlink and not rm or delete or remove or something.
>
>Because on Unix, it is not garanteed to delete a file.
So what? If I rm 'foo' and 'foo' is a link to 'bar', I have
still deleted foo. The fact that I haven't also deleted bar
is irrelevant.
>You can have more
>than one hard connections (links) between the name of the file in the
>filesystem, and the contents. and unlink deletes *one* such entry. Only
>if *all* these name entries are deleted, the file contents itself gets
>wiped.
Hmm. I thought the Unix 'file delete' command was called
'rm', short for remove. Looking at the man, rm seems to
be a wrapper, with options, around unlink and other things.
>Of course, on Windows, this is an alien concept. There, there is a
>one-to-one connection between the file path/name and the contents.
No. You have links on Windows as well. Just not on
Win95/98/Me is all. I don't count those archaic variants
and have never used them.
--
Regards, Helgi Briem
helgi AT decode DOT is
A: Top posting
Q: What is the most irritating thing on Usenet?
- "Gordon" on apihna
------------------------------
Date: Wed, 23 Oct 2002 09:04:57 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: deleting a file... kill ???
Message-Id: <cqocrucc40g8tebmketuslvl5v3e30gn6i@4ax.com>
G.Doucet wrote:
> if(-e "$obidfil"){kill $obidfil;}
As everybody else is saying, you want unlink(). But I'd like to add that
you don't have to do the file test, just
unlink $obidfil;
will do.
>| KILL
>| Syntax: list operator (process)
>| Arguments: signal, list
>| Return Value: 1 (true) '' (false)
>| This function kills the processes with the pids in the supplied list
>by sending the signal level specified.
>| If the signal level is negative, the process groups are killed.
>
>I just want to make sure that I am using the correct function to delete
>a file.
(you're not)
>Does anyone understand that jargon?
A signal is like an interrupt/message/even. The machine uses that
mechanism to warn the machine/other programs that the hard disk has read
some data, or that the mouse has moved. But this is a bit too low level
to be directly applicable here.
A typical example is pressing ctrl-C when a program is running, which
commonly aborts the running program. Another example: ALRM, which is
sent by a timer after a timeout, typically enabled through the alarm()
function call (which doesn't work on Windows, BTW)
Most other usages are typical for Unix-style OSes. For example, commonly
the "HUP" signal is sent to a daemon program (a program running
permanently in the background, like mail and web servers) to warn it
that it should reread its configuration file.
--
Bart.
------------------------------
Date: Tue, 22 Oct 2002 12:59:48 +0100
From: "Saket Rungta" <saketrungta@hotmail.com>
Subject: Re: exclusive execution of a perl script
Message-Id: <ap5uso$114q$1@sp15at20.hursley.ibm.com>
Thanks Brian and Jason!
------------------------------
Date: Wed, 23 Oct 2002 12:35:51 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: exclusive execution of a perl script
Message-Id: <lq5dru4scuesjmlbkr6ssl76edb8udsdf9@4ax.com>
Saket Rungta wrote:
>If cron runs perl script ocassionally and we need to check whether previous
>run finished, how should it be done (elegantly)?
>
>(without temp files writing usage, without killing all perl on ps etc.)
Use a lockfile that only your program uses. If you can't open and lock
the file, die. (Use a nonblocking flock() for that.)
The advantage is that as soon as the program holding the lock is killed,
the file gets unlocked as well, by the OS.
--
Bart.
------------------------------
Date: Wed, 23 Oct 2002 07:46:15 -0400
From: "Christian Caron" <nospam@nospam.org>
Subject: Re: format to output
Message-Id: <ap6267$3nj6@nrn2.NRCan.gc.ca>
Thanks for the information. I had a look at printf (but not in depth) and
found although you specify %15s, if the string contains more than 15
characters, it will display all of them (maybe I have to use %15c?). I'm
sure there's a solution to it, I'll just read the documentation.
Thanks again!
"Bill Smith" <wksmith@optonline.net> wrote in message
news:Thjt9.5374$Z9.2370@news4.srv.hcvlny.cv.net...
>
> "Christian Caron" <nospam@nospam.org> wrote in message
> news:ap3qie$3nj4@nrn2.NRCan.gc.ca...
> >
> --snip--
> > Ok, your solution involves manual tinkering, but what if there are four
> > lines instead of 3 because arrays are created dynamically? It needs to
be
> > automatic.
>
> If there are only two cases, you could write formats for each and set the
> appropriate format before each write.
>
>
>
> >
> > I found this solution (make variable an array, and loop for each line):
> >
> > #############
> > #!/usr/bin/perl -w
> >
> > use strict;
> >
> > my @array1 = ("array1_one");
> > my @array2 = ("array2_one","array2_two","array2_three");
> > my @array3 = ("array3_one","array3_two");
> >
> > # Find the longest array and assign its length to $v
> > # which I'm sure there's a solution that I'll find later...
> > # For the moment, I know it's @array2
> > my $array2_length = @array2;
> > my $v = $array2_length;
> > my $t;
> >
> > for $t (0 .. $v) {
> > if (! $array1[$t]) {
> > $array1[$t] = " ";
> > }
> > if (! $array2[$t]) {
> > $array2[$t] = " ";
> > }
> > if (! $array3[$t]) {
> > $array3[$t] = " ";
> > }
> > write;
> > }
> >
> > format STDOUT =
> > @<<<<<<<<<<<<<<< @<<<<<<<<<<<<<<< @<<<<<<<<<<<<<<<
> > $array1[$t], $array2[$t], $array3[$t]
> > .
> > #############
> >
> > Prints out:
> >
> > colargol# perl test.pl
> > array1_one array2_one array3_one
> > array2_two array3_two
> > array2_three
> >
>
> You are correct, it does work, at least for some version of perl.
>
> > Why do you recommend not to use format/write?
> >
> >
>
> The write/format command is very convenient for displaying long tables
with
> a fixed format. It automatically places column headers at the start of
> every page. However, it usually takes more work to handle special cases
than
> what you save over using printf. The documentation in perldoc perlform is
> not nearly as complete as we have come to expect from the rest of perl.
> Experiments are often needed to find out exactly what happens with undef
> data, excessive data, null strings, data that overflows its format field,
> word wrap in any column but the last, or whatever.
>
> Good Luck,
> Bill
>
>
------------------------------
Date: Wed, 23 Oct 2002 17:10:55 +0800
From: "jackkon" <jackkon@ms29.url.com.tw>
Subject: get workarea in perl/tk?
Message-Id: <ap5pmd$4h4@netnews.hinet.net>
Hi
My OS is win2000.
How do I get workarea 's width and height in perl/tk and
set the screen to the szie in startup the script.
Thanks........
------------------------------
Date: Wed, 23 Oct 2002 12:52:37 +0200
From: Daniel Tiefnig <dantie@gmx.at>
Subject: Re: Hiding password variables in PERL
Message-Id: <3db68050$0$28150$91cee783@newsreader02.highway.telekom.at>
Marc Pelletier wrote:
> I just want to see if there's anything I can do to hide the password
> variable in main.pl so they can't simply put a print statement on the
> variable before I call Telnet.
Why do you want to do this? You're using _telnet_ so anybody in the
network (Not just the main.pl user) with a simple sniffer can see the
password anyways. It doesn't make sense first trying to hide the
password at all costs, and then giving it out to anybody how'd like to
know it.
If you really manage to hide the pass, it'd me a matter of a few seconds
to sniff it off the interface where it's leaving to the switch. See the
point?
lg,
daniel
PS: When X-posting please set a f'up too. dclpm is german speaking, so
here we go to clpm.
--
Stell Dir vor es ist Krieg und der Fernseher geht nicht.
------------------------------
Date: 23 Oct 2002 08:38:24 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@post.rwth-aachen.de>
Subject: Maintaining compatibility throughout several Perl-versions in XS-extentions
Message-Id: <ap5n60$bm1$1@nets3.rz.RWTH-Aachen.DE>
Hi,
Disclaimer: I wasn't sure whether where to post this (clp.modules and
perl-xs were also options). It has more XS than pure Perl content.
While more or less finishing my XS-module (and basically just adding all
the tests), I also tried the stuff compile it under 5.00503 which went
horribly wrong, at first. Problem seems to be that later revisions of
Perl obviously have introduced a few macros that I use, notably
SvPV_nolen() and newSVuv(). I worked around that by adding two macros:
#ifndef SvPV_nolen
# define SvPV_nolen(sv) SvPVX(sv)
#endif
#ifndef newSVuv
# define newSVuv(i) newSViv(i)
#endif
Especially the first one is crude since SvPVX expects that the SV holds
a pointer type. This only works in my case since this can be guaranteed
for the two cases where I use SvPV_nolen.
I tried to simply copy the macros that came with more recent Perls but
they rely on newly introduced functions (sv_2pv_nolen).
Please note that 5.00503 does not come with perlapi.pod so most of the
time I have to grep myself through the headers to find whether a macro
is already defined.
Also, hv_store seems to have changed slightly. The following innocent line
produces a warning:
hv_store(hv, fields[i], 4,
newSVpv(mp_parse_text(content)->text, 0), 0);
fields is just 'const *char fields[FRAMES] = { ... }'. Perl5.5 expects two
casts here - (char*)fields[i] and (SV*)newSVpv(...) - which looks pretty
insane to me.
So, how can one reasonably maintain compatibility? I could of course
simply use the 5.5 subset of XS, but since there is no documentation
this is hardly feasible.
Tassilo
--
$_=q!",}])(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
------------------------------
Date: Wed, 23 Oct 2002 11:15:03 +0000
From: Giuseppe <lcdn@inwind.it>
Subject: Optmization of the exe generated by perlcc
Message-Id: <ap5pi8$r5tvg$1@ID-154800.news.dfncis.de>
Hi,
is there a way such as gcc -O2 to optimize the
executables generated by perlcc ?
Thanks,
Giuseppe
------------------------------
Date: Wed, 23 Oct 2002 08:27:37 GMT
From: "John W. Krahn" <krahnj@acm.org>
Subject: Re: Passing array in the middle of the parrameter list
Message-Id: <3DB65D8A.F31C06B7@acm.org>
Glodalec wrote:
>
> Is there any way to pass an array as a parametter in the middle of the
> parameter list ?
>
> @A=qw(a b c);
> DoIt("This","is","ok",@A) ;
>
> sub DoIt
> {
> my ($FIRST,$SECOND,$THIRD,@A)=@_ ;
> }
>
> Can I do this way ?
> DoIt("Array",@A, "is","the second") ;
No.
> Probably the only solution is to pass it as a reference (\@A)
Yes.
John
--
use Perl;
program
fulfillment
------------------------------
Date: 23 Oct 2002 02:17:00 -0700
From: sami@xenetic.fi (Samppa)
Subject: problems save hash to file with dmopen
Message-Id: <30586a1d.0210230117.55f2bd37@posting.google.com>
hello,
Can somebody help me what's wrong with the following ?
---------------------------------------------------------------------
### $animals{cat} = 'tom';
$animals{cat}{color} = 'grey';
$db = 'savehash.db';
dbmopen(%hash_save, "$db", 0666) or die("Db open error. $! \n");
%hash_save = %animals;
dbmclose %hash_save;
undef %animals;
dbmopen(%hash_save, "$db", 0666) or die("Db open error. $! \n");
%animals = %hash_save;
dbmclose %hash_save;
foreach (keys(%animals)) {
print "Animals key: '$_' value: '$animals{$_}' Color $animals{cat}{color} \n";
}
---------------------------------------------------------------------
After recovering values of %animals hash the value of color key
can not be found.
If I remove comments from "### $animals{cat} = 'tom';" line
all values can recovered succesfully.
regards, Sami
------------------------------
Date: 23 Oct 2002 12:40:19 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Separating stdout and stderr
Message-Id: <ap65bj$cm5$1@mamenchi.zrz.TU-Berlin.DE>
According to Benjamin Goldberg <goldbb2@earthlink.net>:
> Garry Williams wrote:
> >
> > On 18 Oct 2002 14:59:56 -0700, Vilmos Soti <vilmos@vilmos.org> wrote:
> >
> > > If I open a process with open, then is it possible somehow to access
> > > the process' stdout and stderr separately?
> >
> > This a FAQ.
> >
> > perldoc -q stderr
> > "How can I capture STDERR from an external command?"
> >
> > Also see IPC::Open3, but pay special attention to the "This is very
> > dangerous..." paragraph in that manual page.
>
> I consider this bit of the documentation to be mere FUD -- especially if
> you don't need to feed the program anything on it's stdin.
FUD or no, apparently the sentence can give the impression that the risk
of deadlock is to be blamed on the Open3 module. This is not the case.
The same risk exists whenever you read output from *and* provide input
to the same process. No matter how you access the process, it is always
possible for your program to hang and wait for output from the foreign
process that doesn't come because the other process is waiting for input
from your program, which doesn't come because... .
It's multiway IPC that carries the risk, not the specific module that
facilitates it.
[snippage]
Anno
------------------------------
Date: 23 Oct 2002 09:38:30 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: warnings::register and inheritance
Message-Id: <ap5qmm$3kr$2@mamenchi.zrz.TU-Berlin.DE>
According to Brian McCauley <nobull@mail.com>:
> Da Witch <heather710101@yahoo.com> writes:
>
> > I'm having screwy results using warnings::register and inheritance.
>
> No you are not.
[example snipped]
> When Foo::foo() is called from main.pl it correctly reports that
> warnings are enabled at line 4 in main.pl.
>
> When Foo::foo() is called by Bar::foo() in Bar.pm it correctly reports
> that warnings are disabled at line 5 in Bar.pm.
>
> Arguably there is a case for a varient of warnings::enabled() and
> warnings::warn() that work like carp() and step over entries in the
> call stack that are in packages that are ancesctor/decendant of the
> current package. However it is not currently so.
In my opinion (also expressed in another incarnation of this thread)
the variant you describe is the only one that makes sense. warnings::warn()
already uses Carp to find the place the warning is reported as coming from.
IMO this *must* also be the place the warning is controlled from, everything
else is hopelessly confusing.
Whether Carp (with its rather dwimmish attitude towards error location)
it the right model for warnings.pm is another question, and I think it
isn't. However, the error location reported and the point where a warning
is controlled must be the same, an it isn't in the current implementation.
Anno
------------------------------
Date: 23 Oct 2002 12:15:39 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: warnings::register and inheritance
Message-Id: <u9elah9zj8.fsf@wcl-l.bham.ac.uk>
anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) writes:
> According to Brian McCauley <nobull@mail.com>:
>
> > Arguably there is a case for a varient of warnings::enabled() and
> > warnings::warn() that work like carp() and step over entries in the
> > call stack that are in packages that are ancesctor/decendant of the
> > current package. However it is not currently so.
>
> In my opinion (also expressed in another incarnation of this thread)
> the variant you describe is the only one that makes sense. warnings::warn()
> already uses Carp to find the place the warning is reported as coming from.
> IMO this *must* also be the place the warning is controlled from, everything
> else is hopelessly confusing.
>
> Whether Carp (with its rather dwimmish attitude towards error location)
> it the right model for warnings.pm is another question, and I think it
> isn't. However, the error location reported and the point where a warning
> is controlled must be the same, an it isn't in the current implementation.
I agree 100% with Anno on this matter - I just didn't express it as
eloquently.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 23 Oct 2002 08:50:08 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: warnings::register, no warnings, and inheritance
Message-Id: <u9k7k9a6cm.fsf@wcl-l.bham.ac.uk>
Da Witch <heather710101@yahoo.com> writes:
[ Essentially the same thing she did 7 hours earlier ]
Anyone with anything to say on the matter, please ignore this thread
and join in that one.
Heather, if you want to elaborate on something you've posted within
the last 48h it is better to followup your own post rather than start
another almost identical thread.
If you are having problems with your newsspool then be patient.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 23 Oct 2002 09:16:42 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: warnings::register, no warnings, and inheritance
Message-Id: <ap5pdq$3kr$1@mamenchi.zrz.TU-Berlin.DE>
According to Da Witch <heather710101@yahoo.com>:
>
> I'm having screwy results using warnings::register and inheritance.
>
> For example, consider this
>
> # Foo.pm
> package Foo;
> use warnings;
> use warnings::register;
> sub foo { warn "foo called" if warnings::enabled() }
> 1;
>
> # Bar.pm
> package Bar;
> use warnings;
> use base 'Foo';
> sub foo { $_[0]->SUPER::foo() }
> 1;
>
> # test.pl
> use warnings;
> use Bar;
> no warnings 'Foo'; # doesn't turn off warnings from Bar!
> Bar->foo;
>
> Despite the "no warnings 'Foo'":
>
> % perl test.pl
> foo called at Foo.pm line 5.
>
> Is there any way for test.pl to turn off these warnings? (If not, it
> is certainly a design bug.)
Your observation is quite correct, warnings.pm doesn't play nice with
inheritance at the moment.
In short, by an oversight warnings::enabled (as well as warnings::warn
and warnings::warnif) don't look in the right scope to find if warnings
are enabled for a category. This has to do with the fact that warnings.pm
uses Carp.pm to find this place. At the moment, only the place the
warning is reported as coming from (Foo.pm line 4, in your test case)
is found using Carp. The lexical scope that controls warnings should
be the scope of that call, but (with inheritance in the play) it can
be something else, since it is erroneously found by a different
mechanism.
I have a patch that fixes this for the moment, though I'm not too
happy with my current solution. It cements the coupling of warnings
with Carp, while I would rather separate the two again. This turns
out to be a lot harder and isn't done yet. If you want, you can mail
me for the current fix.
Anno
------------------------------
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.
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 4014
***************************************
