[29304] in Perl-Users-Digest
Perl-Users Digest, Issue: 548 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 21 14:10:24 2007
Date: Thu, 21 Jun 2007 11:09:11 -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 Thu, 21 Jun 2007 Volume: 11 Number: 548
Today's topics:
Re: Adding to a perl script automatically xhoster@gmail.com
Re: date parts in one step <noreply@gunnar.cc>
Re: DBD::AnyData hangs when exporting XML xhoster@gmail.com
Re: lightweight access to large data structures? ivowel@gmail.com
Re: package filename mismatches ? <uri@stemsystems.com>
Re: Passing hash to another script via commandline <veatchla@yahoo.com>
Re: Perl Best Practices - Code Formatting. <brian.d.foy@gmail.com>
Re: Perl Best Practices - Code Formatting. <mark.clementsREMOVETHIS@wanadoo.fr>
Re: SSH plus tail -f without key exchange possible? xhoster@gmail.com
Re: The Modernization of Emacs <lew@lewscanon.nospam>
Re: The Modernization of Emacs <notbob@nothome.com>
Re: The Modernization of Emacs <notbob@nothome.com>
Re: The Modernization of Emacs <lew@lewscanon.nospam>
Re: The Modernization of Emacs <notbob@nothome.com>
Re: The Modernization of Emacs (Joel J. Adamson)
Re: The Modernization of Emacs (Joel J. Adamson)
Re: The Modernization of Emacs (Joel J. Adamson)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 21 Jun 2007 15:15:33 GMT
From: xhoster@gmail.com
Subject: Re: Adding to a perl script automatically
Message-Id: <20070621111534.890$6R@newsreader.com>
"MMWJones@googlemail.com" <MMWJones@googlemail.com> wrote:
> Hi,
>
> I have a perl cgi script which defines popup_menu and values in the
> drop down list. More values may be added to this over time. People
> that don't know much about the script might not want to enter the
> script and type in values 'manually'.
I think that this is a spectacularly bad idea. If you want people who
don't know much about Perl to configure aspects of your Perl program, you
should make a non-Perl configuration file (or database) for them to use for
that purpose.
> Is there a way of writing a script that will ask the user for a value
> and be able to access the script and put the value in the correct
> place automatically?
Sure. If you save this to a script named add.pl, when run it will add the
typed in string to itself. You could easily make it work on scripts other
than itself just be changing the string assigned to @ARGV in the "local".
#!/usr/local/bin/perl
use strict;
use warnings;
my @x=(
#MyUniqueMarker,
"a",
"b",
"c",
);
print "Current values is @x\n";
print "What should I add?\n";
my $new = <>;
close STDIN or die $!;
chomp $new;
local ($^I,$/,@ARGV)=('.bak',undef,"add.pl");
$_=<>;
s/#MyUniqueMarker,\n/#MyUniqueMarker,\n"$new",\n/ or warn;
print;
But the fact that it can be done doesn't make a good idea. Somewhat better
than this, but still not as good as having a separate config file, is to
use the __END__ or __DATA__ tokens to separate the program from the data
within one file.
> If so how would i go about doing this? In a .pl script or .sh script?
I certainly wouldn't try in .sh, but then again I don't read or post to
sh scripting newsgroups, so clearly I am biased in that regard.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 21 Jun 2007 18:38:21 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: date parts in one step
Message-Id: <5dvo1aF35v76pU1@mid.individual.net>
Petr Vileta wrote:
> My solution is this:
>
> (localtime)[4,5];
> ($m, $y) = ($$_[0] + 1, $$_[1] + 1900);
C:\home>type test.pl
use warnings;
(localtime)[4,5];
($m, $y) = ($$_[0] + 1, $$_[1] + 1900);
C:\home>test.pl
Useless use of list slice in void context at C:\home\test.pl line 2.
Name "main::y" used only once: possible typo at C:\home\test.pl line 3.
Name "main::m" used only once: possible typo at C:\home\test.pl line 3.
Use of uninitialized value in addition (+) at C:\home\test.pl line 3.
Use of uninitialized value in addition (+) at C:\home\test.pl line 3.
C:\home>
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 21 Jun 2007 15:43:02 GMT
From: xhoster@gmail.com
Subject: Re: DBD::AnyData hangs when exporting XML
Message-Id: <20070621114304.258$Zi@newsreader.com>
KomsBomb@hotmail.com wrote:
> Perl 5.8.0
> Newest DBD::AnyData and AnyData just downloaded from CPAN.
> When export a test database to xml, the script hangs and seems
> it's in a dead loop.
>
> ********My Code start*************
> use strict;
> use warnings;
> use DBI;
>
> my $dbh = DBI->connect('dbi:AnyData(RaiseError=>1):');
> my ($table, $format, $file, $flags) = (
> 'test', 'XML', 'cars.csv', { col_names => 'make,model,year' }
> );
> $dbh->do("CREATE TABLE test (id TEXT,phrase TEXT)");
> $dbh->do("INSERT INTO test VALUES (1,'foonadfjlsdj')");
> $dbh->do("INSERT INTO test VALUES (2,'bar')");
> $dbh->func( $table, $format, $file, 'ad_export'); #hangs here
> ********My Code end*************
>
> By doing more investigation, I found where it hangs,
>
> In package AnyData (note not the DBD::AnyData), line 639, in sub
> adConvert, there is a line
> " @cols = @{ shift @{ $source_data } };"
> When I execute step by step there, the program hangs at that line.
I've run strace on this program. It appears to be opening two handles onto
the file cars.csv, and trying to obtain a exclusive lock on each of those
handles, leading to a self-deadlock. The very last instruction executed is
a flock, so I don't think you've identified the correct line for the
freezing point.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 21 Jun 2007 15:46:18 -0000
From: ivowel@gmail.com
Subject: Re: lightweight access to large data structures?
Message-Id: <1182440778.335062.322080@n15g2000prd.googlegroups.com>
thank you for all the advice. I solved my problem in a pragmatic but
not convenient way. I now have only one hash that combines both keys
into one key, and which points to an index into one long string which
contains all the data. This seems rather memory efficient, even
though it is not convenient and not in the spirit of my problem.
better than an external data base, external C, or other kludges,
however...
/iaw
------------------------------
Date: Thu, 21 Jun 2007 16:05:46 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: package filename mismatches ?
Message-Id: <x7ejk5thr9.fsf@mail.sysarch.com>
>>>>> "BB" == Brad Baxter <baxter.brad@gmail.com> writes:
BB> On Jun 20, 1:50 pm, Uri Guttman <u...@stemsystems.com> wrote:
>>
>> i played with Exporter and it seems that use doesn't even call import if
>> passed an empty list (). so use does have a syntactical trick to skip
>> importing.
BB> perldoc -f use
BB> If you do not want to call the package's "import"
BB> method (for instance, to stop your namespace from
BB> being altered), explicitly supply the empty list:
BB> use Module ();
BB> That is exactly equivalent to
BB> BEGIN { require Module }
both paul and i knew that. i was exploring how he could emulate it with
explicit direct method calls. the only way is to just not call the
import method which is under his control.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Thu, 21 Jun 2007 12:57:15 -0500
From: l v <veatchla@yahoo.com>
Subject: Re: Passing hash to another script via commandline
Message-Id: <137leun72vq6600@news.supernews.com>
Purl Gurl wrote:
> Joe Smith wrote:
>
>> Purl Gurl wrote:
>
>>> Irrelevant. Your comments do not comply with the originating
>>> author's stated parameters.
>
>> You're assuming that the author's stated parameters are the only
>> parameters that he is ever going to use. Bad assumption.
>
>> A competent programmer provides solutions that work in the general
>> case, not just the case with "field1 => 'f1val', field2 => 'f2val'".
>
> Oh look! Another stringless yo-yo childish troll. Hooray!
> We all love idiocy within a technology discussion group!
>
> Inform readers, you troll boy, what are the originating author's
> complete set of possible parameters. Put to good use your fantastic
> internet mind reading skills, read the author's mind then inform
> all of us, precisely and exactly all possible data for which we
> should prepare through code.
>
> * slips on her Johnny Carson swami turban *
>
> Wait! Wait! I have created a socket directly the author's sleeping mind....
>
> I see... I see... OH MY! Sometimes his data will be one-hundred gigabytes
> of pure binary data. OH NO! Sometimes his data will be a letter "E"
> followed
> by ten-million spaces, then a letter "I" followed by twenty-million spaces,
> then the letter "E" followed by one space, then another letter "I" followed
> by ten-million-one-hundred-billion spaces, then the letters "OOOOH"
> followed
> by an exclamation mark!
>
> E I E I OOOOH!
>
> Goodness, the author is dreaming about Old McDonald's Farm.
>
> Listen you blithering babblers, you do not have a single clue
> on this. You are piss poor programmers, piss poor Perl code writers
> and exceptionally piss poor thinkers.
>
> How the Hades could you childish twits have the slightest hint
> of what data to expect beyond what is concisely stated by an
> author? You do not. "Bad assumption" my smelly foot. I have made
> no bad assumption by restricting my code to only those parameters
> stated. No bad assumption here, I am simply dealing with a bunch of
> stringless yo-yo boys who know diddly-squat about programming and
> yet think themselves Gods of Perl.
>
> * SCREAMS *
>
> Such stupidity!
>
> Only bad assumption made is you dumb boys arrogantly assuming all
> readers to be so gullible to fall for your idiocy.
>
> Hey! Take your stupid "what if" troll games and shove those games
> right up there with your heads.
>
Oh look, another mindless, senseless, and ignorant post from the Purl Gurl.
--
Len
------------------------------
Date: Thu, 21 Jun 2007 12:11:58 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <210620071211587710%brian.d.foy@gmail.com>
In article <1182402088.951116@sj-nntpcache-2.cisco.com>, Asim Suter
<asuter@cisco.com> wrote:
> I was reading Perl Best Practices by Respected Damian Conway
> and he rather strongly advices using K&R style of code format as opposed to
> BSD style or GNU style.
> [ In Amazon reviews this advice was not very well received ]
> OTOH in Damian Conway's classic "Object Oriented Perl", he chooses to use
> BSD style in the book.
>
> Change of heart Mr. Conway ?
Don't forget to read the beginning of the preface, where Damian says:
"This book doesn't try to offer *the* one true universal and unequivocal
set of best practices."
and
"What this book offers instead is *a* set of best practices".
That is, Damian is offering one way to do things, but the real goal is
to agree within your team how you want to do things and the be
consistent in applying your decisions.
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Thu, 21 Jun 2007 19:48:46 +0200
From: Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <467ab9fe$0$5085$ba4acef3@news.orange.fr>
Asim Suter wrote:
<snip>
>
>
> I know people feel strongly about code layout/format and "bracing
> technology" - I would like to know
> what folks are using in their scripts and modules.
>
> I am talking about production scripts and modules ( possibly multiple people
> team ) with sufficient complexity.
> ( Several thousand Perl line count at the minimum )
>
> Which style appeals to you more and which one do you use ?
>
> Regards.
> Asim Suter
>
> PS: It does not matter - but I find BSD style more appealing.
Perl::Tidy makes it relatively simple to enforce a consistent style,
whatever that may be.
Mark
------------------------------
Date: 21 Jun 2007 17:27:38 GMT
From: xhoster@gmail.com
Subject: Re: SSH plus tail -f without key exchange possible?
Message-Id: <20070621132739.938$Dw@newsreader.com>
jrpfinch <jrpfinch@gmail.com> wrote:
> I would like to tail -f a file on a remote machine over SSH and
> process output line-by-line as it comes in. I'm pretty sure this can
> be done using Expect and open (FH, "ssh root@remote_machine ... tail -
> f |") if you have exchanged keys.
You don't even need the Expect if you have exchanged keys. Just the piped
open is sufficient. If you do need to provide a password, maybe Expect can
be arranged to handle that, but I haven't done it to prove it can be done.
> ssh will not take a supplied
> username and password on the command line, however.
When I start ssh from a perl script, it will read bypass stdin/stdout and
will ask (and receive) a password directly from the controlling tty. Not
the same thing as the command line, but perhaps good enough.
>
> This leaves Net::SSH::Perl, which does accept user/pass login, but
> AFAIK only lets you issue discrete commands via the '->cmd("ls -ltr")'
> method.
Since you don't *want* to issue a discrete command, then don't
use ->cmd(). Use the advanced methods, maybe either socket or
register_handler.
Once you call login, the $ssh object gets re-blessed into a different
package. If you can't figure out how to use those more advanced features,
then figure out what package that is, and go look at that package's
implementation of cmd to see how cmd itself uses those more advanced
features.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 21 Jun 2007 11:11:32 -0400
From: Lew <lew@lewscanon.nospam>
Subject: Re: The Modernization of Emacs
Message-Id: <o96dnSQlYM25COfbnZ2dnUVZ_hWdnZ2d@comcast.com>
Joel J. Adamson wrote:
> My point is that I'm the sort of person that has a mind set up for
> Emacs. I had none of the difficulties that someone else might have,
> who's used to other kinds of software.
>
> However, I'll also point out that my wife has used Emacs a couple
> times, and she's never done more than point and click with a computer,
> and she's had no frustration whatsoever.
A new user of two hours' experience. A father of a six-year old whose child
hums along happily with emacs. A computer widow who "had no frustration
whatsoever" with it.
To the claim that "emacs is too hard for the beginner" we have a mounting pile
of steaming evidence that refutes. It may still be true that it is too hard
for some beginners, but then again the power cord can be too hard for some
people. (I used to help customers find the Big Red Switch when they first got
a computer. There were many who needed it.)
To the claim that emacs has arcane keystrokes comes the evidence that modern
revs have "normal" keystrokes like right-arrow, F1, Ctrl-End.
To the claim that the help is too hard to use comes the evidence that three
simple keystroke patterns are all one needs to know, and anecdotal evidence of
the help system's utility.
Some will refuse to face the truth. To the open-minded, let the facts speak
for themselves.
I bet Xah Les is all over smiles about how well his controversy bloomed.
--
Lew
------------------------------
Date: Thu, 21 Jun 2007 10:30:03 -0500
From: notbob <notbob@nothome.com>
Subject: Re: The Modernization of Emacs
Message-Id: <2cOdnRv-NoXmBOfbnZ2dnUVZ_t2dnZ2d@comcast.com>
On 2007-06-21, Lew <lew@lewscanon.nospam> wrote:
> To the claim that "emacs is too hard for the beginner" we have a mounting pile
> of steaming evidence that refutes. It may still be true that it is too hard
> for some beginners......
I point them to jed. I, too, was overwhelmed by emacs, initially, but
can't stand vi so I had to do something. jed was my savior. It uses
many standard keys like backspace and the arrows, so newbs aren't so
confused. When I finally became comfortable with the std emacs
keystrokes I got O'Reilly's great book and ventured into emacs. Love
it. But, still a rank newb and still use jed and slrn a lot till I
can learn to configure emacs like I want it.
vi, the heart of evil!
nb
------------------------------
Date: Thu, 21 Jun 2007 10:33:15 -0500
From: notbob <notbob@nothome.com>
Subject: Re: The Modernization of Emacs
Message-Id: <2cOdnRr-NoWmB-fbnZ2dnUVZ_t2dnZ2d@comcast.com>
On 2007-06-21, David Kastrup <dak@gnu.org> wrote:
>
> I should think that version 2.3.1 would not even try ftp. Is that on
> Multics?
Slackware 10.1
nb
------------------------------
Date: Thu, 21 Jun 2007 11:34:33 -0400
From: Lew <lew@lewscanon.nospam>
Subject: Re: The Modernization of Emacs
Message-Id: <24qdnSXDI78UB-fbnZ2dnUVZ_o7inZ2d@comcast.com>
Lew wrote:
>> To the claim that "emacs is too hard for the beginner" we have a mounting pile
>> of steaming evidence that refutes. It may still be true that it is too hard
>> for some beginners......
notbob wrote:
> I point them to jed. I, too, was overwhelmed by emacs, initially, but
> can't stand vi so I had to do something. jed was my savior. It uses
> many standard keys like backspace and the arrows, so newbs aren't so
> confused.
You mean compared to the way emacs also uses the same "standard" keys, like
backspace and the arrows? How are the arrow keys in emacs more confusing than
the arrow keys in jed?
Your comment reads like you've missed most of this thread.
--
Lew
------------------------------
Date: Thu, 21 Jun 2007 10:39:48 -0500
From: notbob <notbob@nothome.com>
Subject: Re: The Modernization of Emacs
Message-Id: <2cOdnRX-NoVZBufbnZ2dnUVZ_t2dnZ2d@comcast.com>
On 2007-06-21, Lew <lew@lewscanon.nospam> wrote:
> Your comment reads like you've missed most of this thread.
This may be due to the fact I've missed most of this thread.
nb
------------------------------
Date: Thu, 21 Jun 2007 13:02:18 -0400
From: jadamson@partners.org (Joel J. Adamson)
Subject: Re: The Modernization of Emacs
Message-Id: <871wg56y1x.fsf@W0053328.mgh.harvard.edu>
David Kastrup <dak@gnu.org> writes:
> You know you can use something like
> C-x C-f /su::/etc/fstab RET
> (or /sudo::/etc/fstab) in order to edit files as root in a normal
> Emacs session?
I did not know that. That will save me huge amounts of time. You're
my hero.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
------------------------------
Date: Thu, 21 Jun 2007 13:12:29 -0400
From: jadamson@partners.org (Joel J. Adamson)
Subject: Re: The Modernization of Emacs
Message-Id: <87wsxx9qpu.fsf@W0053328.mgh.harvard.edu>
Lew <lew@lewscanon.nospam> writes:
> Joel J. Adamson wrote:
>> My point is that I'm the sort of person that has a mind set up for
>> Emacs. I had none of the difficulties that someone else might have,
>> who's used to other kinds of software.
>>
>> However, I'll also point out that my wife has used Emacs a couple
>> times, and she's never done more than point and click with a computer,
>> and she's had no frustration whatsoever.
>
> A new user of two hours' experience. A father of a six-year old whose
> child hums along happily with emacs. A computer widow who "had no
> frustration whatsoever" with it.
>
I'll add that the words "Oh, cool" came out of her mouth during one
Emacs session, as they did when I showed it to a coworker.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
------------------------------
Date: Thu, 21 Jun 2007 13:10:48 -0400
From: jadamson@partners.org (Joel J. Adamson)
Subject: Re: The Modernization of Emacs
Message-Id: <871wg5b5d3.fsf@W0053328.mgh.harvard.edu>
I just tried it: works for me.
Joel
David Kastrup <dak@gnu.org> writes:
> Lew <lew@lewscanon.nospam> writes:
>
>> Bjorn Borud <borud-news@borud.no> writes:
>>>> so if the context was system administration, I'd vote for vi as
>>>> well. if the context was programming I'd vote Emacs.
>>
>> David Kastrup wrote:
>>> You know you can use something like
>>> C-x C-f /su::/etc/fstab RET
>>> (or /sudo::/etc/fstab) in order to edit files as root in a normal
>>> Emacs session?
>>
>> I've been using emacs for something like twenty years and never knew
>> that before.
>
> The package "tramp" will provide that (as well as editing files over
> ssh, scp, rsync, telnet, plink...). It is already preinstalled in
> Emacs 22.1, but can also be installed for earlier versions.
>
> --
> David Kastrup
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
------------------------------
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 V11 Issue 548
**************************************
