[24679] in Perl-Users-Digest
Perl-Users Digest, Issue: 6841 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 6 14:06:13 2004
Date: Fri, 6 Aug 2004 11:05:12 -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 Fri, 6 Aug 2004 Volume: 10 Number: 6841
Today's topics:
Re: [OT] Perl Developers Needed for Open-Source ATC! (Peter Scott)
Re: [OT] Perl Developers Needed for Open-Source ATC! (Aquila Deus)
Re: [OT] Perl Developers Needed for Open-Source ATC! (Randal L. Schwartz)
Re: A-Z listing <bhoughton@ozemail.com.au>
Re: Breakpoint on a builtin? <spam.keith.me.arner.not@marconi.com>
Re: Breakpoint on a builtin? <nobull@mail.com>
combining excel sheets from different excels workbooks (Vumani Dlamini)
Re: delimited data into nested array <usenet@morrow.me.uk>
Re: Failing File Tests? (Jay Sun Ex)
Re: Failing File Tests? <mritty@gmail.com>
Re: Failing File Tests? <dwall@fastmail.fm>
Re: Failing File Tests? <andrewpalmer@email.com>
Re: Failing File Tests? <jgibson@mail.arc.nasa.gov>
File::Glob - can it recurse? (Randall Perry)
Re: File::Glob - can it recurse? <mritty@gmail.com>
Re: File::Glob - can it recurse? <nobull@mail.com>
Re: How do I detect if I have incoming data in <STDIN> <richard@zync.co.uk>
Inline C (PerlNovice)
Input from subprocess called using open() buffered? <"g r a e m e b [at] c a d e n c e [dot] c o m">
Re: Input from subprocess called using open() buffered? <gifford@umich.edu>
Re: Input from subprocess called using open() buffered? <nobull@mail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 06 Aug 2004 14:12:35 GMT
From: peter@PSDT.com (Peter Scott)
Subject: Re: [OT] Perl Developers Needed for Open-Source ATC!
Message-Id: <nlMQc.27828$J06.4111@pd7tw2no>
"Aquila Deus" <aquila_deus@yahoo.co.uk> wrote in message
news:c5cfac8f.0408050653.2cc054f2@posting.google.com...
> Hi all!
>
> The project MrATC (Air Traffic Control) needs more Perl developers.
> We've done some discussion and begin to code and write doc, but there
> are only 2 developers now (and one is a perl noob - me).
>
> WE NEED YOUR HELP TO BUILD THE WORLD'S NEXT GENERATION OF AIR TRAFFIC
> CONTROL SYSTEM IN PERL!
I've been assuming that this is a practical joke. Anyone who thinks
that Perl is a good choice for creating an *operational* air traffic
control system needs their head examined. Now, as a demonstration
coding project, it could be an interesting diversion, although one
does wonder whether that amount of effort wouldn't be better expended
on something that would end up actually being used.
Ironically - and the reason I am interjecting - in "Perl Medic", I
asked for anyone who was building an ATC system in Perl to drop me a
line. This was an aside in a discussion about expertise of
maintenance programmers versus project complexity. I then added
that if they intended their system to be maintained by teenage
programmers, to attach a map of the areas served by said system, and I
would put it to good use.
Books don't generally use smileys. They're unnecessary in most forms
of humor when done right. At least, so I thought...
--
Peter Scott
http://www.perldebugged.com/
*** NEW *** http://www.perlmedic.com/
------------------------------
Date: 6 Aug 2004 09:02:52 -0700
From: aquila_deus@yahoo.co.uk (Aquila Deus)
Subject: Re: [OT] Perl Developers Needed for Open-Source ATC!
Message-Id: <c5cfac8f.0408060802.575f731e@posting.google.com>
Bill <wherrera@lynxview.com> wrote in message news:<Z-KdncKRYeq_io7cRVn-uA@adelphia.com>...
> Aquila Deus wrote:
> > Hi all!
> >
> > The project MrATC (Air Traffic Control) needs more Perl developers.
> > We've done some discussion and begin to code and write doc, but there
> > are only 2 developers now (and one is a perl noob - me).
> >
> > WE NEED YOUR HELP TO BUILD THE WORLD'S NEXT GENERATION OF AIR TRAFFIC
> > CONTROL SYSTEM IN PERL!
> >
> > If you're interested, please visit
> > http://sourceforge.net/projects/mratc/
> >
>
> This is highly domain specific software. You should have a 'real' air
> traffic controller be involved in design and testing for this to 'fly.'
>
> Perhaps you may benefit contacting an FAA spakeman like Karen at the FAA
> here in the US: karen (dot)stewart (at) faa.gov and asking her
> thoughts. Or better still, if there is an air traffic control school
> near where you are living, interview a teacher there.
Thank you! I'll discuss this with project admin :)
------------------------------
Date: 06 Aug 2004 09:43:24 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: [OT] Perl Developers Needed for Open-Source ATC!
Message-Id: <86d6242p5f.fsf@blue.stonehenge.com>
>>>>> "Peter" == Peter Scott <peter@PSDT.com> writes:
Peter> I've been assuming that this is a practical joke. Anyone who thinks
Peter> that Perl is a good choice for creating an *operational* air traffic
Peter> control system needs their head examined.
It's certainly better than the ancient stuff they're using now.
Besides, if adequately tested, there's nothing with Perl for mission
critical projects. I know a lot of people who consider
ticketmaster.com "mission critical"... especially the folks at
Ticketmaster. And that's all mod_perl from top to bottom... all Perl.
So, an ATC system coded in Perl does not scare me in the slightest.
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Fri, 6 Aug 2004 20:35:21 +1000
From: "BernieH" <bhoughton@ozemail.com.au>
Subject: Re: A-Z listing
Message-Id: <M9JQc.44$VJ.4415@nnrp1.ozemail.com.au>
Joe, I've been having a closer look at this, and I'm not too sure how to get
the program reading my input file (i'm a total perl novice)!
I've been starting the program with: "perl program.pl my_file.txt" but this
is reading only the filename, not the contents of the file. Obviously I'm
doing something not right!
TIA
BernieH
> #!/usr/bin/perl
> use strict; use warnings;
>
> my @letters = ('A'..'Z', '0');
> my %fh; # Holds file handles for the 27 files
> open my $index,'>','index.html' or die "Cannot create index.html: $!\n";
> foreach (@letters) {
> open $fh{$_},'>',"$_.html" or die "Cannot create $_.html: $!\n";
> print {$fh{$_}} qq(<html><head>Titles starting with
'$_'</head><body>\n);
> print $index qq(<a href="$_.html">$_</a>\n);
> }
> close $index or warn "Problem in closing index.html: $!\n";
>
> while (<>) { # Input is "number Multi word title # optional data\n"
> my ($number,$title) = /(\S+)\s+(.*)/;
> next unless defined $title;
> next if $number =~ /#/;
> my $rest_of_line = ($title =~ s/\s*(#.*)//) ? $1 : "";
> my $letter = uc substr $title,0,1;
> $letter = '0' unless $letter =~ /[A-Z]/;
> print {$fh{$letter}} qq(<a href="$number">$title</a>
$rest_of_line<br>\n);
> }
>
> foreach (@letters) {
> print {$fh{$_}} qq(</body></html>\n);
> close $fh{$_} or warn "Problem in closing $_.html: !$\n";
> }
>
> -Joe
------------------------------
Date: Fri, 6 Aug 2004 08:53:54 -0400
From: Keith Arner nospam <spam.keith.me.arner.not@marconi.com>
Subject: Re: Breakpoint on a builtin?
Message-Id: <Pine.GSO.4.42.0408060850270.15519-100000@zimbra>
On 5 Aug 2004, Anno Siegel wrote:
> Keith NoSpam Arner <spam.keith.me.arner.not@marconi.com> wrote in comp.lang.perl.misc:
> >
> > Is there a way in the perl debugger to set a breakpoint on a builtin
> > function?
>
> You could override (documented in perlsub) the unlink function and set
> a breakpoint on that. This should do (untested, I'm stalwartly
> ignoring the debugger):
Hhmm... no dice. I can correctly override the builtin (that is, it will
execute the function that I override with), but when I set a breakpoint on
my function, the debugger does not hit it:
[0]karner@bayberry 8:48am:485 > perl -d
Loading DB routines from perl5db.pl version 1.0402
Emacs support available.
Enter h or `h h' for help.
package CORE::GLOBAL;
use subs 'unlink';
sub unlink { print "not unlinking $_[0]\n"};
package main;
print "hello\n";
unlink "foo";
main::(-:5): print "hello\n";
DB<1> b CORE::GLOBAL::unlink
DB<2> c
hello
not unlinking foo
Debugged program terminated. Use q to quit or R to restart,
use O inhibit_exit to avoid stopping after program termination,
h q, h R or h O to get additional info.
DB<2>
--
In questions of science, the authority of a thousand is not worth the
humble reasoning of a single individual.
-Galileo Galilei
------------------------------
Date: Fri, 06 Aug 2004 17:47:27 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: Breakpoint on a builtin?
Message-Id: <cf0cfc$b0$1@sun3.bham.ac.uk>
Ilya Zakharevich wrote:
> [A complimentary Cc of this posting was sent to
> Anno Siegel
> <anno4000@lublin.zrz.tu-berlin.de>], who wrote in article <cespo4$5un$1@mamenchi.zrz.TU-Berlin.DE>:
>
>>Keith NoSpam Arner <spam.keith.me.arner.not@marconi.com> wrote in comp.lang.perl.misc:
>> # double braces indicate an un-indented block
>> {{
>> package CORE::GLOBAL;
>> use subs 'unlink';
>> sub unlink { CORE::unlink( @_) }
>> }}
>
>
> Not enough. One needs to special-case the 0-arguments case. [See
> Fatal for how to auto-implement this.]
I've had a look at Fatal version 1.03 in Perl 5.8.5 and I can't see how
Fatal destinguishes no arguments ( e.g. unlink() ) from an empty list (
unlink( my @empty_list = ()))
What an I missing?
------------------------------
Date: 6 Aug 2004 03:33:58 -0700
From: dvumani@hotmail.com (Vumani Dlamini)
Subject: combining excel sheets from different excels workbooks
Message-Id: <4b35f3c9.0408060233.75acacdb@posting.google.com>
I have several excel workbooks each with 4 sheets named page1,
page2,.., page5. I would like to create 5 new workbooks where each
page is combined into one excel workbook. That is all the "page1"
sheets are combined into one workbook, etc.
I just can't figure out how to do this.
Thanks a lot.
Vumani
------------------------------
Date: Thu, 5 Aug 2004 18:12:44 +0100
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: delimited data into nested array
Message-Id: <cd6au1-1u4.ln1@mauzo.dyndns.org>
Quoth yaweh32@yahoo.com (Yup):
> >while (<INFO>) {
> > chomp;
> > push @A, [ split /\t/ ];
>
> Many thanks everyone for your help. The above code was actually what I
> had been searching for, but I kept being told that Perl didn't
> directly support multi-dimensional arrays.
The key word there is 'directly'...
> If this is the case, what
> is this called, then?
An array of references to arrays; almost always simply referred to as an
array of arrays.
> But now that I can access @A in the same way as a C++ vector, it suits
> me well.
Ben
--
We do not stop playing because we grow old;
we grow old because we stop playing.
ben@morrow.me.uk
------------------------------
Date: 6 Aug 2004 07:55:01 -0700
From: nefarious_6x3@yahoo.co.uk (Jay Sun Ex)
Subject: Re: Failing File Tests?
Message-Id: <135fa1e0.0408060655.3fc42fa9@posting.google.com>
Paul Lalli <mritty@gmail.com> wrote in message news:<20040805194010.X4433@barbara.cs.rpi.edu>...
> Are you doing this as a learning experience? If so, the answer is that
> readdir returns the filename without the path. That is, -d is looking for
> a file named $file within the current working directory, not the directory
> in which it was found.
>
> If you're trying to do this for an actual practical purpose, stop wasting
> effort. It's already been done, in the standard module File::Find.
>
> Paul Lalli
As I am still very much a beginner and doing this for learning
purposes, what should I use since readdir is no longer my friend?
Also, I have zero experience with modules at this point. I am hesitant
to use them for two reasons, I like the challenge of solving problems
with my own code, and second, I want my programs to be able to run on
various systems that may or may not have modules installed. If I use a
module and want my program to run on some other machine, does that
machine need the module installed or does my script just know what to
do?
Thanks for all the help thus far!
-Jason X-
------------------------------
Date: Fri, 6 Aug 2004 11:34:39 -0400
From: Paul Lalli <mritty@gmail.com>
Subject: Re: Failing File Tests?
Message-Id: <20040806112654.O4433@barbara.cs.rpi.edu>
On Fri, 6 Aug 2004, Jay Sun Ex wrote:
> Paul Lalli <mritty@gmail.com> wrote in message news:<20040805194010.X4433@barbara.cs.rpi.edu>...
>
> > Are you doing this as a learning experience? If so, the answer is that
> > readdir returns the filename without the path. That is, -d is looking for
> > a file named $file within the current working directory, not the directory
> > in which it was found.
> >
> > If you're trying to do this for an actual practical purpose, stop wasting
> > effort. It's already been done, in the standard module File::Find.
>
> As I am still very much a beginner and doing this for learning
> purposes, what should I use since readdir is no longer my friend?
readdir is your friend. You're just not using -d correctly. Once you've
gotten the name of the file that exists in a given directory, you can't
just use the filetest on the filename. You have to use it on the whole
path. An example:
openddir $dir, $dirname or die "Cannot open directory $dirname: $!";
while ($filename = readdir ($dir)){
if (-d "$dirname/$filename") {
#whatever you want to do with directories
}
}
> Also, I have zero experience with modules at this point. I am hesitant
> to use them for two reasons, I like the challenge of solving problems
> with my own code,
That's an okay reason - but remember one of the three great virtues of
programming - laziness. That means reusing existing code rather than
reinventing it.
> and second, I want my programs to be able to run on
> various systems that may or may not have modules installed.
That's not, at least in this case.
> If I use a
> module and want my program to run on some other machine, does that
> machine need the module installed or does my script just know what to
> do?
File::Find is a *standard* module. It comes with Perl. If you have Perl,
you have this module.
The other two that Mr. Schwartz mentioned, File::Finder and
File::Find::Rule, are non-standard. A script which uses these modules on
an installation which does not contain these modules will fail, with an
error similar to "Cannot find File/Finder.pm in @INC. @INC
contains....". This is trivial to fix, however. You simply install the
module, by using the ever-handly CPAN module:
perl -MCPAN -e'install File::Finder'
> Thanks for all the help thus far!
For more information on the standard File::Find module, run this in your
shell:
perldoc File::Find
For more information on the other two, visit search.cpan.org, and search
for those two modules' names.
Paul Lalli
------------------------------
Date: Fri, 06 Aug 2004 15:36:46 -0000
From: "David K. Wall" <dwall@fastmail.fm>
Subject: Re: Failing File Tests?
Message-Id: <Xns953D7621A8311dkwwashere@216.168.3.30>
Jay Sun Ex <nefarious_6x3@yahoo.co.uk> wrote in message
<news:135fa1e0.0408060655.3fc42fa9@posting.google.com>:
> Paul Lalli <mritty@gmail.com> wrote in message
> news:<20040805194010.X4433@barbara.cs.rpi.edu>...
>
>> Are you doing this as a learning experience? If so, the answer
>> is that readdir returns the filename without the path. That is,
>> -d is looking for a file named $file within the current working
>> directory, not the directory in which it was found.
>>
>> If you're trying to do this for an actual practical purpose, stop
>> wasting effort. It's already been done, in the standard module
>> File::Find.
>>
>
> As I am still very much a beginner and doing this for learning
> purposes, what should I use since readdir is no longer my friend?
readdir() is still your friend, but you'll have to keep track of the
path yourself.
> Also, I have zero experience with modules at this point. I am
> hesitant to use them for two reasons, I like the challenge of
> solving problems with my own code, and second, I want my programs
> to be able to run on various systems that may or may not have
> modules installed. If I use a module and want my program to run on
> some other machine, does that machine need the module installed or
> does my script just know what to do?
It depends on which modules you use. File::Find is a standard module,
meaning that it comes with every Perl installation. If it's not
there, then the install was screwed up or someone removed it for some
strange reason.
If you're trying to get real work done, modules are a godsend.
Instead of trying to solve every hairy problem yourself, it's often
the case that someone else has already solved it and made reusable
code available. The CPAN (Comprehensive Perl Archive Network) is
sometimes envied by users of other languages who otherwise don't care
for Perl.
------------------------------
Date: Fri, 6 Aug 2004 10:51:11 -0500
From: "Andrew Palmer" <andrewpalmer@email.com>
Subject: Re: Failing File Tests?
Message-Id: <7LNQc.3202$zc1.2165@fe40.usenetserver.com>
"Jay Sun Ex" <nefarious_6x3@yahoo.co.uk> wrote in message
news:135fa1e0.0408060655.3fc42fa9@posting.google.com...
> Paul Lalli <mritty@gmail.com> wrote in message
news:<20040805194010.X4433@barbara.cs.rpi.edu>...
>
> > Are you doing this as a learning experience? If so, the answer is that
> > readdir returns the filename without the path. That is, -d is looking
for
> > a file named $file within the current working directory, not the
directory
> > in which it was found.
> >
> > If you're trying to do this for an actual practical purpose, stop
wasting
> > effort. It's already been done, in the standard module File::Find.
> >
> > Paul Lalli
>
> As I am still very much a beginner and doing this for learning
> purposes, what should I use since readdir is no longer my friend?
>
> Also, I have zero experience with modules at this point. I am hesitant
> to use them for two reasons, I like the challenge of solving problems
> with my own code, and second, I want my programs to be able to run on
> various systems that may or may not have modules installed. If I use a
> module and want my program to run on some other machine, does that
> machine need the module installed or does my script just know what to
> do?
Yes, the module would have to be installed, but so would perl, of course.
File::Find is a standard module. If perl5 is installed, it should already be
there.
Also, installing a module from CPAN is not that big a deal. Most people will
do it if they have to to use a particular script.
>
> Thanks for all the help thus far!
>
> -Jason X-
------------------------------
Date: Fri, 06 Aug 2004 09:50:57 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: Failing File Tests?
Message-Id: <060820040950577497%jgibson@mail.arc.nasa.gov>
In article <135fa1e0.0408051511.5b1abddf@posting.google.com>, Jay Sun
Ex <nefarious_6x3@yahoo.co.uk> wrote:
> I am working on a recursive program that prints out all directories
> and files recursively starting from whatever directory is passed to
> ARGV[0]. This version of my program is meant for use on windows 2000.
> The problem is my program does not capture directories using the if
> (-d $blah... file test. Below is my code. Any and all help would be
> greatly appreciated.
>
> $root = $ARGV[0];
> &recurse($root);
Don't call subroutines with ampersand unless you need to, and you don't
here.
> sub recurse {
> opendir DIR, $_[0];
Add this line here (see below for reason):
my @directories;
> foreach $file (readdir DIR) {
> if (($file eq ".") or ($file eq "..")) {
> #Do nothing
> } elsif (-d $file) {
As Paul pointed out, you need to test "$_[0]/$file" here.
> print "\n$file";
> $folder_path = $_[0] . "\\" . $file;
> push @directories, $folder_path;
> } else {
> print "\n$file is not a directory";
> }
> }
> close DIR;
> foreach $newpath (@directories) {
> shift @directories;
You shouldn't use shift on an array being traversed. The foreach will
iterate over all elements of @directories. Since you have declared 'my
@directories' before the loop, you will get a new, empty instance of
the @directories array with each invocation of the subroutine, so you
don't need to delete elements from @directories as you process them.
> &recurse($newpath);
> }
> }
If you don't declare 'my @directories' in recurse(), @directories
becomes global and you _do_ need to delete processed entries. Here is
one way:
while( @directories ) {
recurse( shift @directories );
}
------------------------------
Date: 6 Aug 2004 08:39:12 -0700
From: rgp@systame.com (Randall Perry)
Subject: File::Glob - can it recurse?
Message-Id: <fac8f6c0.0408060739.537c19bf@posting.google.com>
I'm guessing not from reading the docs.
Here's what I can do with 2 lines using system:
system("chown -R $user.$http_group www/*");
($? eq 0) || die "Couldn't chown $user.$group www/*\n";
I'd like to use the perl chown() command so I tried this:
@filenames = glob "/admin/new_account_page/*";
chown $uid, $gid, @filenames || die;
But it doesn't recurse through subdirectories. Is there a better way
to accomplish this than by using system()?
Randy
------------------------------
Date: Fri, 6 Aug 2004 11:52:08 -0400
From: Paul Lalli <mritty@gmail.com>
Subject: Re: File::Glob - can it recurse?
Message-Id: <20040806114457.G4433@barbara.cs.rpi.edu>
On Fri, 6 Aug 2004, Randall Perry wrote:
> I'm guessing not from reading the docs.
>
> Here's what I can do with 2 lines using system:
> system("chown -R $user.$http_group www/*");
> ($? eq 0) || die "Couldn't chown $user.$group www/*\n";
>
> I'd like to use the perl chown() command so I tried this:
> @filenames = glob "/admin/new_account_page/*";
> chown $uid, $gid, @filenames || die;
>
> But it doesn't recurse through subdirectories. Is there a better way
> to accomplish this than by using system()?
I feel like I'm taking on the job of advocating this module lately.
The standard File::Find module is helpful for recursing through
directories. The non-standard File::Find::Rule and File::Finder provide
alternate syntaxes as well.
(untested)
#!/usr/bin/perl
use strict;
use warnings;
use File::Find
my ($uid, $gid) = @ARGV; #assuming UID and GID are passed in command line.
my @files;
sub wanted{
push @files, $File::Find::name if -f $File::Find::name;
}
find (\&wanted, '/admin/new_account_page/');
chown $uid, $gid, @files or die "Cannot chown: $!";
__END__
------------------------------
Date: Fri, 06 Aug 2004 17:30:33 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: File::Glob - can it recurse?
Message-Id: <cf0bfm$sts$1@sun3.bham.ac.uk>
Randall Perry wrote:
[ of glob() ]
> But it doesn't recurse through subdirectories. Is there a better way
> to accomplish this than by using system()?
File::Find
------------------------------
Date: Fri, 06 Aug 2004 13:05:48 +0100
From: "Richard Gration" <richard@zync.co.uk>
Subject: Re: How do I detect if I have incoming data in <STDIN> when I pipe something to my perl script ?
Message-Id: <cevs6s$jqo$1@news.freedom2surf.net>
In article <cevblc$2ds$1@newstree.wise.edt.ericsson.se>, "Andreas Berg"
<andreas.berg@ericsson.com> wrote:
> Actually, if the first command line parameter is a file, you can read it
> using <STDIN>, or maybe its just <> you can read it with, but if I
> recall correctly, they are the same thing.
Right second time. The <> is some perl magic which treats the command
line arguments as filenames and allows you to read their content via <>.
This has nothing to do with stdin though, <> and <STDIN> are different
beasts.
#!/usr/bin/perl
print 'Do you want to see the contents of <>? (y/n) ';
chomp (my $ans = <STDIN>);
if ($ans =~ /^y/i) {
print for <>;
} else {
print "Bye bye!";
}
HTH
Rich
------------------------------
Date: 6 Aug 2004 08:04:32 -0700
From: tanvi527@hotmail.com (PerlNovice)
Subject: Inline C
Message-Id: <86167d7d.0408060704.4da68fab@posting.google.com>
Below is the message from Tassilo that shows how to work the XS
module. I did exactly what he said and it is not working for me.
When I run: perl Makefile.PL && make; I get an error:
Writing Makefile for Hello::World
make: Error -- rem: The system cannot find the file specified.
make: Error code -1
I have no idea what this means and why it occurs.
I also tried Inline C and I get the following error:
Undefined subroutine &main::hello called at ./test_inline.pl line 4.
Can someone please help!
Tassilo's posting:
Another alternative way is using pure XS. Inline::C/C++ are just
wrappers around XS. They look simpler but they aren't really. XS has
the
advantage that development happens in a more standard way: You work on
the .xs file and use another console to do a 'make'. Errors are thus
appearing on your console and not dumped in files in a hidden
directory
(as Inline does it).
When working with XS, you usually have the overhead of creating a real
module. But that's not really a bad thing. You start with h2xs:
ethan@ethan:~/Projects$ h2xs -c -b 5.5.3 -n Hello::World
Writing Hello/World/ppport.h
Writing Hello/World/World.pm
Writing Hello/World/World.xs
Writing Hello/World/Makefile.PL
Writing Hello/World/README
Writing Hello/World/t/1.t
Writing Hello/World/Changes
Writing Hello/World/MANIFEST
This creates a skeletal module with all required files. The -b switch
adds a compatibility layer to your module so that the newer portions
of
the PerlAPI will be made compatible with at least 5.00503 (for this
case).
After that, you add the functionality to Hello/World/World.xs. Right
now
it only contains:
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include "ppport.h"
MODULE = Hello::World PACKAGE = Hello::World
Adding an XS function that prints its argument as string looks like:
void
hello(string)
SV *string;
PPCODE:
printf("hello, %s\n", SvPV_nolen(string));
You put this below the 'MODULE =' line. Now you go to the other
console
and do a 'perl Makefile.PL && make':
ethan@ethan:~/Projects/Hello/World$ perl Makefile.PL && make
Checking if your kit is complete...
Looks good
Writing Makefile for Hello::World
cp World.pm blib/lib/Hello/World.pm
AutoSplitting blib/lib/Hello/World.pm (blib/lib/auto/Hello/World)
/usr/bin/perl /usr/lib/perl5/5.8.0/ExtUtils/xsubpp -typemap
/usr/lib/perl5/5.8.0/ExtUtils/typemap World.xs > World.xsc && mv
World.xsc World.c
Please specify prototyping behavior for World.xs (see perlxs manual)
cc -c -I. -O3 -march=athlon -fno-strict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\"
-fpic "-I/usr/lib/perl5/5.8.0/i686-linux/CORE" World.c
Running Mkbootstrap for Hello::World ()
chmod 644 World.bs
rm -f blib/arch/auto/Hello/World/World.so
LD_RUN_PATH="" cc -shared -L/usr/local/lib World.o -o
blib/arch/auto/Hello/World/World.so
chmod 755 blib/arch/auto/Hello/World/World.so
cp World.bs blib/arch/auto/Hello/World/World.bs
chmod 644 blib/arch/auto/Hello/World/World.bs
Manifying blib/man3/Hello::World.3
And now, you can already call your function without installing the
module:
ethan@ethan:~/Projects/Hello/World$ perl -Mblib -MHello::World
Hello::World::hello("world");
__END__
hello, world
ethan@ethan:~/Projects/Hello/World$
If you do a 'make install' you have this module properly installed
system-wide.
Since it's a proper module, you have a file Hello/World/World.pm, too.
This is an ordinary Perl module file. If you want your function to be
exported automatically, you do it there:
@EXPORT = qw(hello);
After doing 'make' again (whenever you change something, do a 'make'),
you call it thusly:
ethan@ethan:~/Projects/Hello/World$ perl -Mblib -MHello::World
hello("world");
__END__
hello, world
ethan@ethan:~/Projects/Hello/World$
In the above command-lines, -Mblib tells perl to use the blib/
directory
as location of the module. blib/ holds the compiled but not yet
installed module.
XS does the same conversions as Inline::C, so the function hello()
could
also be written as:
void
hello(string)
char *string;
PPCODE:
printf("hello, %s\n", string);
Returning values from a function isn't hard either:
char *
hello_concat(string)
char *string;
PREINIT:
char *retstring;
int len;
CODE:
len = strlen(string) + 8;
New(0, retstring, len, char);
memcpy(retstring, "hello, ", 7);
memcpy(retstring + 7, string, strlen(string));
retstring[len] = 0;
RETVAL = retstring;
OUTPUT:
RETVAL
Just as you can pass in Perl types and do the conversion yourself, you
can use the Perl stack explicitely to return a SV. That way, you can
return lists of values by XPUSH()ing them and then telling perl how
many
values you pushed with XSRETURN(num_of_values):
void
hello_stack(string)
char *string;
PREINIT:
SV *retval;
PPCODE:
retval = newSVpv("hello, ", 7);
SvGROW(retval, strlen(string));
sv_catpv(retval, (const char*)string);
/* sv_2mortal() makes the SV mortal:
* that is, it will auto-destroy itself when it goes
* out of scope */
XPUSHs(sv_2mortal(retval));
XSRETURN(1);
I can't much comment on SWIG. From the XS/Inline/SWIG trio I'd say it
is
the worst choice since it's not Perl specific. It may make the first
steps of wrapping a library into a Perl module easier, but you have
better control over what happens when using Inline or XS. If you
ignore
the common myths that Inline is much easier than all the rest, XS is
still the best way of accessing C/C++ from Perl.
The manpages you should read are:
perlxstut /* a tutorial, not complete but helpful nonetheless */
perlguts /* explains the concepts behind the Perl internals */
perlxs
perlcall /* if you call Perl code from your XS */
perlapi
perlapio /* the I/O related PerlAPI */
Tassilo
--
------------------------------
Date: Fri, 06 Aug 2004 17:02:28 +0100
From: "g r a e m e b [at] c a d e n c e [dot] c o m" <"g r a e m e b [at] c a d e n c e [dot] c o m">
Subject: Input from subprocess called using open() buffered?
Message-Id: <4113ab97@news.cadence.com>
Hi,
I have a perl wrapper which runs a command (in this case, cvs) and formats the
output. It presently runs the command something like this:
$| = 1;
open(COMMAND, "$cmd 2>&1 |") || die "Couldn't run command";
while (<COMMAND>) {
print;
}
The problem is that the output from the command appears to arrive in chunks (a
bit like watching 'tail' on a file which is constantly updating). It looks as
though it's getting buffered until it exceeds a certain threshold, then all
coming out at once.
If I run it like this, however, the output comes out 'real time', as it does if
I run it on the command-line manually:
system("$cmd 2>&1");
Is there some way I can read from COMMAND and actually get the output when it
appears, rather than when there is a sizable chunk?
Thanks,
Graeme.
------------------------------
Date: 06 Aug 2004 12:46:05 -0400
From: Scott W Gifford <gifford@umich.edu>
Subject: Re: Input from subprocess called using open() buffered?
Message-Id: <qszr7qk43le.fsf@rygar.gpcc.itd.umich.edu>
"g r a e m e b [at] c a d e n c e [dot] c o m" <"g r a e m e b [at] c a d e n c e [dot] c o m"> writes:
[...]
> Is there some way I can read from COMMAND and actually get the output
> when it appears, rather than when there is a sizable chunk?
You can either look for a way to tell COMMAND not to buffer its
output, perhaps with a command-line flag or environment variable
mentioned in its documentation, or else use a pseudo-tty to make it
think it's talking to a terminal. IIRC, the easiest way to use a
pseudo-tty is to use the Expect or Expect::Simple module.
Good luck!
----ScottG.
------------------------------
Date: Fri, 06 Aug 2004 18:27:33 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: Input from subprocess called using open() buffered?
Message-Id: <cf0eqj$1f6$1@sun3.bham.ac.uk>
g r a e m e b [at] c a d e n c e [dot] c o m wrote:
> open(COMMAND, "$cmd 2>&1 |") || die "Couldn't run command";
> while (<COMMAND>) {
> print;
> }
>
> The problem is that the output from the command appears to arrive in
> chunks (a bit like watching 'tail' on a file which is constantly
> updating).
It's not that it's arriving in chunks, it's being sent in chunks.
> It looks as though it's getting buffered until it exceeds a
> certain threshold, then all coming out at once.
That is probably correct. But this is happening in the other process
not Perl.
> If I run it like this, however, the output comes out 'real time', as it
> does if I run it on the command-line manually:
>
> system("$cmd 2>&1");
Actually that's not entirely true. If Perl processes STDOUT was
anything other than a tty device then I would expect the other process
once again to send its output chunked.
> Is there some way I can read from COMMAND and actually get the output
> when it appears, rather than when there is a sizable chunk?
You are reading it when it appears. It's just that it's appearing in
chunks. There may be a way to tell the command in question not to chunk
its output but that is a question about the specific command, not Perl.
Failing that, I Expect (hint, hint) there's something on CPAN you could
use to allow Perl to fool the other process into thinking its output was
going to a terminal.
------------------------------
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 6841
***************************************
