[26480] in Perl-Users-Digest
Perl-Users Digest, Issue: 8642 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Nov 8 00:05:40 2005
Date: Mon, 7 Nov 2005 21:05:04 -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 Mon, 7 Nov 2005 Volume: 10 Number: 8642
Today's topics:
Re: Cannot get exec syntax correct <usenet739_yahoo_com_au>
Re: Cannot get exec syntax correct <1usa@llenroc.ude.invalid>
Re: FAQ 3.19 How can I make my CGI script more efficien nospam@geniegate.com
why the perl documents is hard to understand? <xli6@gmu.edu>
Re: why the perl documents is hard to understand? <emschwar@pobox.com>
Re: why the perl documents is hard to understand? <xli6@gmu.edu>
Re: why the perl documents is hard to understand? <1usa@llenroc.ude.invalid>
Re: why the perl documents is hard to understand? <emschwar@pobox.com>
Re: why the perl documents is hard to understand? <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 8 Nov 2005 11:03:25 +1100
From: "Scott Bass" <usenet739_yahoo_com_au>
Subject: Re: Cannot get exec syntax correct
Message-Id: <436feb4f$0$14220$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
"A. Sinan Unur" <1usa@llenroc.ude.invalid> wrote in message
news:Xns97076BAD81C98asu1cornelledu@127.0.0.1...
> "Scott Bass" <usenet739_yahoo_com_au> wrote in
> news:436f437f$0$14227$5a62ac22@per-qv1-newsreader-01.iinet.net.au:
>
>> I'm trying to write a simple script that will glob all files with a
>> particular extension, then run a system command against each file. I
>> want the script to fork off a process for each invocation, and not
>> wait for the system command to finish.
>
> Since you are running on Windows, why not use start?
Doh! Thanks...
>
>> Here is what I have so far:
...
>> # process each file
>> my ($dirname, $basename);
>> while (@files) {
>> $_ = shift @files;
>> $basename = basename($_);
>> $dirname = dirname($_);
>>
>> my @cmd = ( "$SAS $args $basename" );
>>
>> if (! $debug) {
>> chdir($dirname);
>> exec { $cmd[0] } @cmd;
>
> You are not really passing a list of arguments to exec, but a single
> string. This is really messed up. Do read perldoc -f system.
I was trying to follow the advice in perldoc -f exec, but obviously I didn't
fully understand it. See the part about indirect objects and the example:
@args = ( "echo surprise" );
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use File::Spec::Functions qw(canonpath catfile);
>
> my %defaults = (
> dir => '.',
> ext => 'sas',
> );
>
> my %args = (
> %defaults,
> @ARGV,
> );
>
> opendir my $dir, canonpath($args{dir})
> or die "Cannot open directory: $args{dir}: $!";
>
> FILE:
> while(my $file = readdir $dir) {
> next FILE unless $file =~ m{ \.$args{ext} \z }x;
> run_sas($file);
> }
>
> closedir $dir
> or die "Cannot close directory: $args{dir}: $!";
>
> my @SAS = (
> q{C:/Program Files/SAS Institute/SAS/V8/sas.exe},
> q{-CONFIG "C:/Program Files/SAS Institute/SAS/V8/SASV8.CFG"},
> qw(-rsasuser -icon -nosplash -batch -noterminal -no$syntaxcheck
> -initstmt "%include '../init.sas';" -sysin),
> );
>
> sub run_sas {
> my ($sas_file) = @_;
>
> system('start', @SAS, $sas_file);
> }
>
> __END__
>
> I cannot test this as I do not have any SAS files that I wouldn't mind
> risking at this point.
>
> Sinan
> --
> A. Sinan Unur <1usa@llenroc.ude.invalid>
> (reverse each component and remove .invalid for email address)
>
> comp.lang.perl.misc guidelines on the WWW:
> http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
>
Thanks heaps Sinan. It's working now.
I wanted to keep the file globbing code, since our directory structure and
file naming convention is such that typical invocations would be:
runsaspgms sys/?_*.sas pgms/?_*.sas
Many of the .sas programs in a directory would be macros and should not be
submitted directly. The desired programs are named ?_*.sas, and could be in
either of those sub-directories.
I had to add an additional '' to the system command. I'm not sure why this
works; I came across it by accident. Without it, I get an error dialogue:
Cannot find the file '-CONFIG' ... Not sure if it is a system or SAS error
dialogue.
Here is the final code:
#!perl
# set pragmas
use strict;
use warnings;
# include desired modules
use Getopt::Long;
use File::Basename;
# process command line options
my $debug = '0';
GetOptions ('debug!' => \$debug);
# define SAS command string - comment out the version you're not using
my @SAS;
# SAS 8
@SAS = (
q{C:/Program Files/SAS Institute/SAS/V8/sas.exe },
q{-CONFIG "C:/Program Files/SAS Institute/SAS/V8/SASV8.CFG" },
q{-rsasuser -icon -nosplash -batch -noterminal -no$syntaxcheck -initstmt
"%include '../init.sas';" -sysin },
);
# SAS 9
@SAS = (
q{C:/Program Files/SAS/SAS 9.1/sas.exe },
q{-CONFIG "C:/Program Files/SAS/SAS 9.1/nls/en/SASV9.CFG" },
q{-rsasuser -icon -nosplash -batch -noterminal -no$syntaxcheck -initstmt
"%include '../init.sas';" -sysin },
);
sub run_sas {
my ($sas_file) = @_;
system('start', '', @SAS, $sas_file); # the '' is required, do not
remove
}
# glob files specified on the command line
my @files;
while (@ARGV) {
push @files, glob(shift @ARGV);
}
# process each file
my ($dirname, $basename);
while (@files) {
$_ = shift @files;
$basename = basename($_);
$dirname = dirname($_);
if (! $debug) {
chdir($dirname);
run_sas($basename);
}
else {
print "cd $dirname\n";
print @SAS,$basename,"\n";
}
}
__END__
------------------------------
Date: Tue, 08 Nov 2005 00:20:18 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Cannot get exec syntax correct
Message-Id: <Xns9707C4BA22AA3asu1cornelledu@127.0.0.1>
"Scott Bass" <usenet739_yahoo_com_au> wrote in
news:436feb4f$0$14220$5a62ac22@per-qv1-newsreader-01.iinet.net.au:
> "A. Sinan Unur" <1usa@llenroc.ude.invalid> wrote in message
> news:Xns97076BAD81C98asu1cornelledu@127.0.0.1...
>> "Scott Bass" <usenet739_yahoo_com_au> wrote in
>> news:436f437f$0$14227$5a62ac22@per-qv1-newsreader-01.iinet.net.au:
>>
>>> I'm trying to write a simple script that will glob all files with a
>>> particular extension, then run a system command against each file.
>>> I want the script to fork off a process for each invocation, and not
>>> wait for the system command to finish.
>>
>> Since you are running on Windows, why not use start?
>
> Doh! Thanks...
You are welcome.
> I wanted to keep the file globbing code, since our directory structure
> and file naming convention is such that typical invocations would be:
>
> runsaspgms sys/?_*.sas pgms/?_*.sas
OK. I have an irrational fear of glob based on the fact that I always
have to look up its semantics.
> I had to add an additional '' to the system command. I'm not sure why
> this works; I came across it by accident.
Ah! I forgot:
D:\Home\asu1\UseNet\clpmisc> start /?
Starts a separate window to run a specified program or command.
START ["title"] [/Dpath] [/I] [/MIN] [/MAX] [/SEPARATE | /SHARED]
[/LOW | /NORMAL | /HIGH | /REALTIME | /ABOVENORMAL | /BELOWNORMAL]
[/WAIT] [/B] [command/program]
[parameters]
...
So, the first argument to start is the title of the window used to run
the program. You don't need to specify this argument if you are doing
something like:
start picture.jpg
which invokes the associated program.
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Tue, 08 Nov 2005 02:41:54 GMT
From: nospam@geniegate.com
Subject: Re: FAQ 3.19 How can I make my CGI script more efficient?
Message-Id: <Lucy1131414577198810xcdafb4@air.tunestar.net>
In: <3t78jtFrfc2vU1@individual.net>, Brian Wakem <no@email.com> wrote:
>From a personal point of view, CPU load dropped significantly when we moved
>from mod_cgi to mod_perl, and out maximum throughput moved up from a few
>dozen mod_cgi pages per second to just over 3000 mod_perl pages per second.
Based on what I've seen, your analysis pretty much matches my own
observations.
mod_perl is good when you've got access to it AND it's something that
is used frequently. It's easy to make mistakes with it though. (memory
leaks can be such an issue they give the appearance of a performance
decrease)
mod_perl is bad and can slow things down for cgi scripts that aren't
used all that often simply because they take up valuable memory. mod_perl
might not be a good choice for a control panel or something that gets used
maybe once a week. Of course mod_perl is worthless if you need setuid
stuff.
The tricks I've personally used to 'speed up' cgi scripts are delayed loading
and fewer modules. Split things up into several files and try to arrange for
only required subroutines to be loaded in on each request. AUTOLOAD can come
in handy, but you really want the loaded file to contain support subroutines
you know you'll need as well (to thwart off overhead for future AUTOLOAD
invocations.)
This leads to sloppy programming, (particularly the AUTOLOAD + support
routines) the exact opposite of mod_perl, but it works when mod_perl isn't an
option (or for things that aren't used much) A real bugger when working
with OO-Perl and @ISA.
Unfortunately, it's rather hard to optimize for both cases, since you want
preloading with mod_perl (and IMO, you want to do away with any Registry stuff,
going for the straight API)
Overall, mod_perl is (IMO) better when it's available. It's a lot easier
to optimize for, *much* faster in it's proper place. I feel mod_perl code
tends to be a lot "cleaner" (has to be!) Maybe not such a good choice
for dead simple scripts or occasional use.
When using the mod_perl API, it's a lot easier to write test cases too, just
implement the required portions of the API as a "dummy request".
I just wish perl would "come back" to where it used to be, I miss it. Mod_perl
is great but it's useless in the shared hosting environments everyone seems
so fond of (despite the availability of inexpensive VPS packages)
For this reason I wish there were an apache module with a perl binary that
could load (potentially pre-compiled) perl code and then unload it after
the request. At least that would get rid of the fork() problem, it'd still
be slower than mod_perl though.
Jamie
--
http://www.geniegate.com Custom web programming
guhzo_42@lnubb.pbz (rot13) User Management Solutions
------------------------------
Date: Mon, 07 Nov 2005 19:21:55 +0000
From: Xiaoshen Li <xli6@gmu.edu>
Subject: why the perl documents is hard to understand?
Message-Id: <dkommm$a3h5$1@osf1.gmu.edu>
Hi,
I am learning Perl now. I have computer science background. One
important tool for learning a language is to learn how to read its help
manual. For example, JAVA has all the functions document pages online.
So any time, if I don't understand a function or need a function for
doing something, I can check out the document pages. But I found Perl's
document pages are so hard to read.
http://search.cpan.org/dist/perl/pod/perlfunc.pod
I have tried to read the descriptions of some functions. I am so totally
lost. The wording, the phrases are so hard to follow. I feel I am
reading an acient scripture.
Unix/Linux 's man pages are also badly written. But I feel Perl's is
even worse.
------------------------------
Date: Mon, 07 Nov 2005 16:51:01 -0700
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: why the perl documents is hard to understand?
Message-Id: <etozmog2f16.fsf@wilson.emschwar>
Xiaoshen Li <xli6@gmu.edu> writes:
> So any time, if I don't understand a function or need a function for
> doing something, I can check out the document pages. But I found Perl's
> document pages are so hard to read.
>
> http://search.cpan.org/dist/perl/pod/perlfunc.pod
You can also get the documentation for a specific function by typing
'perldoc -f <funcname>' at the command line; this makes it a good deal
easier to read only the documentation for the function you're
considering.
> I have tried to read the descriptions of some functions. I am so totally
> lost. The wording, the phrases are so hard to follow. I feel I am
> reading an acient scripture.
Please give us an example of a function whose documentation you feel
is inadequate. We are always trying to improve the state of Perl
documentation, but if all you tell us is, "It's bad", then we have no
information that we can actually use to improve things. Instead, what
we need is, "This documentation is bad, because the way it is written,
I don't understand if I can do this or that. I think it would be
easier to understand if you said it this way." Only please be more
specific than that. :)
> Unix/Linux 's man pages are also badly written. But I feel Perl's is
> even worse.
Many of us don't agree, but I think also that even people who feel the
docs are fine for them would agree that for other people, they can be
improved. So tell us how they can be made better, and we'll do what
we can. Sometimes we may simply disagree, but if you read this
newsgroup for very long, you'll notice that FAQs are posted frequently
here, and for very many of them, we will have discussions about how to
improve them which are frequently concluded with a patch.
So please give us specific examples of what is not good, why you don't
think it's good, and if possible, how you think we might improve
what's there. Some discussion will result, and either you will say,
"Oh, I didn't realize that, you're right, that is the best way to
explain it," or perhaps we will say, "That is a confusing way to put
it. How about this way?". Sometimes, we will have to agree to
disagree. But if you don't give us specific examples, all we can say
is, "We're sorry you don't like it," and leave it at that.
-=Eric
------------------------------
Date: Mon, 07 Nov 2005 21:31:50 +0000
From: Xiaoshen Li <xli6@gmu.edu>
Subject: Re: why the perl documents is hard to understand?
Message-Id: <dkoua9$adjj$1@osf1.gmu.edu>
Thank you very much for the replies. Yes, a coin has two sides, I agree.
Anyway, I was taught that there is a trick to learn unix/linux. That is
to learn how to read man page. Because the man page is always there to
help you, anytime, anywhere.
This similar trick clearly cannot work in Perl, unless I am at a
prefessional level already. (If a person is at that level, I think those
document pages may not be very useful already, at least its usefulness
has been dramatically decreased.) I wish the wording, discriptions of
each function are writen for general people, not for professionals or
the writer himself to read.
(By the way, the comment "Unfortunately, Linux/Unix man pages are badly
writen." is not from me, is from the book "Think Unix" by Jon Lasser and
I assume & believe a lot of people feel same way.)
Generally, I wish computer science people could improve their expression
skills dramatically.
Now I recall one of the greatest poet in China Tang Dynasty, BaiJuYi.
After finishing a poem, he always read to some old aged general people.
If they don't understand, he always tore it away and restart to write.
It is not easy to explain something.
Xiaoshen Li wrote:
> Hi,
>
> I am learning Perl now. I have computer science background. One
> important tool for learning a language is to learn how to read its help
> manual. For example, JAVA has all the functions document pages online.
> So any time, if I don't understand a function or need a function for
> doing something, I can check out the document pages. But I found Perl's
> document pages are so hard to read.
>
> http://search.cpan.org/dist/perl/pod/perlfunc.pod
>
> I have tried to read the descriptions of some functions. I am so totally
> lost. The wording, the phrases are so hard to follow. I feel I am
> reading an acient scripture.
>
> Unix/Linux 's man pages are also badly written. But I feel Perl's is
> even worse.
>
------------------------------
Date: Tue, 08 Nov 2005 01:24:23 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: why the perl documents is hard to understand?
Message-Id: <Xns9707CF978BE95asu1cornelledu@127.0.0.1>
Xiaoshen Li <xli6@gmu.edu> wrote in news:dkoua9$adjj$1@osf1.gmu.edu:
> Now I recall one of the greatest poet in China Tang Dynasty, BaiJuYi.
> After finishing a poem, he always read to some old aged general
> people. If they don't understand, he always tore it away and restart
> to write. It is not easy to explain something.
I am confused as to why you think this analogy is appropriate here? Do
you expect all Perl programmers the world over to delete all Perl
documentation on our hard drives and start writing it from scratch?
You haven't given examples of specific documents that you have
difficulty with. You haven't pointed out how things can be made better.
Eric patiently explained why you should do that. You have ignored his
advice, and trashed your opportunity to actually make things better.
Instead, we get this drivel about how Unix and Perl docs suck. Tell me,
what good is that? What purpose does does your complaining serve?
On second thought, please don't.
*PLONK*
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Mon, 07 Nov 2005 18:24:14 -0700
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: why the perl documents is hard to understand?
Message-Id: <etooe4w2apt.fsf@wilson.emschwar>
Xiaoshen Li <xli6@gmu.edu> writes:
> Thank you very much for the replies. Yes, a coin has two sides, I agree.
> Anyway, I was taught that there is a trick to learn unix/linux. That is
> to learn how to read man page. Because the man page is always there to
> help you, anytime, anywhere.
I think man pages are useful to remind you how to do something, but
quite often, unless you already know, and want to remind yourself,
more documentation is needed.
> This similar trick clearly cannot work in Perl, unless I am at a
> prefessional level already.
I do not agree; most of how I have learned to program in Perl has been
reading the online documentation.
> (If a person is at that level, I think those
> document pages may not be very useful already, at least its usefulness
> has been dramatically decreased.) I wish the wording, discriptions of
> each function are writen for general people, not for professionals or
> the writer himself to read.
Please tell us what, specifically, you have a problem with. All you
are saying now is, "I find Perl documentation hard to read". But if
you do not tell us WHY it is hard for you, and HOW it might be
improved, we cannot change anything. Let us pretend that I believe
that the wording and descriptions of each function is already written
for general people. (That is not the case, but let us pretend it is.)
Now, you must convince me that I am wrong, and you are right. Please
give me one specific function whose documentation you believe is not
written for general people. Tell me why you believe that function's
documentation is not written for general people, and if you can, tell
us how you would change it to be more easily understood. Do not tell
us, "Oh, they're so confusing and difficult to understand", tell me
WHAT is confusing, and WHY it is difficult to understand.
> (By the way, the comment "Unfortunately, Linux/Unix man pages are badly
> writen." is not from me, is from the book "Think Unix" by Jon Lasser and
> I assume & believe a lot of people feel same way.)
Nobody here really cares one way or the other.
> Generally, I wish computer science people could improve their expression
> skills dramatically.
That's probably true. But it doesn't help us here. We are practical
people-- if someone comes to us and says, "Perl documentation is
hard", we cannot change anything. If that person continues to say the
same thing, then we will eventually decide that person does not want
to make things better, but only complains, and we will stop listening,
and nothing will change.
If, however, someone says, "This document is confusing, because I
don't understand what this means. Please explain it." and then writes
a better explanation, then we are happy to help, and the documents
will improve for everyone.
> Now I recall one of the greatest poet in China Tang Dynasty, BaiJuYi.
> After finishing a poem, he always read to some old aged general people.
> If they don't understand, he always tore it away and restart to write.
> It is not easy to explain something.
No it is not. Will you help us explain things better, or will you
only complain and not try to improve Perl documentation?
-=Eric
------------------------------
Date: Tue, 08 Nov 2005 04:25:03 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: why the perl documents is hard to understand?
Message-Id: <zMVbf.3851$vC6.2170@trnddc05>
Xiaoshen Li wrote:
> Hi,
>
> I am learning Perl now. I have computer science background. One
> important tool for learning a language is to learn how to read its
> help manual. For example, JAVA has all the functions document pages
> online.
How awkward! Do you really have to dial up your ISP, start your favourite
browser, ... just to find out how a Java function works?
> So any time, if I don't understand a function or need a
> function for doing something, I can check out the document pages.
Well, then that is one point where Perl is vastly superior.
All the Perl documentation is installed as part of Perl on your local system
and you can easily access it using "perldoc".
No large browser to start, not dialup to your ISP, just simple, easy, and
straightforward.
> But
> I found Perl's document pages are so hard to read.
>
> http://search.cpan.org/dist/perl/pod/perlfunc.pod
Never went there once in some 10+ years of on-and-off Perl programming.
> I have tried to read the descriptions of some functions. I am so
> totally lost. The wording, the phrases are so hard to follow. I feel
> I am reading an acient scripture.
Do you have some concrete example?
> Unix/Linux 's man pages are also badly written. But I feel Perl's is
> even worse.
Well, no. They are terse and to the point for experienced people to check
out details about how a function (command, operator, ...) works. They are
definitely not meant as tutorial.
jue
------------------------------
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 8642
***************************************
