[22430] in Perl-Users-Digest
Perl-Users Digest, Issue: 4651 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Mar 2 18:06:07 2003
Date: Sun, 2 Mar 2003 15:05:06 -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 Sun, 2 Mar 2003 Volume: 10 Number: 4651
Today's topics:
Re: Going around in circles with modules? (Anno Siegel)
Re: Going around in circles with modules? <newsfeed2@boog.co.uk>
Re: Going around in circles with modules? <uri@stemsystems.com>
Re: how to read form output in perl procedure <peakpeek@purethought.com>
Re: how to read form output in perl procedure <me@privacy.net>
Re: how to read form output in perl procedure <tore@aursand.no>
Image::Font examples? <us-NOSPAM-enet2@watson-wilson.ca>
Re: Looking for a utility to remove duplicates <me@privacy.net>
Re: Looking for a utility to remove duplicates <tore@aursand.no>
Re: my own "modules" for want of a better name (Tad McClellan)
Re: my own "modules" for want of a better name <jurgenex@hotmail.com>
Re: my own "modules" for want of a better name <newsfeed2@boog.co.uk>
Re: my own "modules" for want of a better name <newsfeed2@boog.co.uk>
Need Newbie Programmers for Freelance Group (Jas)
new Perl feature request: call into shared libs <no.spam@gknw.de>
Re: new Perl feature request: call into shared libs <jurgenex@hotmail.com>
Re: new Perl feature request: call into shared libs <no.spam@gknw.de>
Re: new Perl feature request: call into shared libs <tassilo.parseval@post.rwth-aachen.de>
Re: new Perl feature request: call into shared libs <no.spam@gknw.de>
Re: Problem running Sybperl scripts as root user (Apryl Ferrell)
Re: The perl CD bookshelf (Randal L. Schwartz)
Using a (config) file relative to a module location... <bik.mido@tiscalinet.it>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 2 Mar 2003 16:32:33 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Going around in circles with modules?
Message-Id: <b3tbn1$1ha$1@mamenchi.zrz.TU-Berlin.DE>
Peter Cooper <newsfeed2@boog.co.uk> wrote in comp.lang.perl.misc:
> > Let's say I have a main program.. something.pl
>
> I decided to conduct some research of my own into this. I created the set up as
> I said.. and to my surprise I found that the subroutines module could 'see' the
> stuff from my settings module, even though I didn't actually use 'use' to
> reference it there.
>
> For example ..
>
> print &MySettings::db->{username};
Unless you actually want to override a prototype on MySettings::db, and
call it with the current value of @_, this is better written
print MySettings::db()->{username};
>
> .. worked fine from the MySubroutines module, even though the MySettings module
> is only referenced in the main program 'something.pl'.
>
> Is this because the main app has loaded MySettings into memory, and now
> /anything/ can reference stuff in MySettings directly? My Perl book hints at
> this but doesn't confirm it and tends to stick to the basics.
Whichever way you put it, a sub can be accessed from anywhere once it is
defined, just like package variables. They are global to the entire
program, no matter which file they are defined in. For variables, this
is in direct contrast to lexicals. Lexical subs don't exist (yet), so
subs are always global.
Anno
------------------------------
Date: Sun, 2 Mar 2003 16:46:31 -0000
From: "Peter Cooper" <newsfeed2@boog.co.uk>
Subject: Re: Going around in circles with modules?
Message-Id: <gEq8a.10048$EN3.78274@newsfep4-glfd.server.ntli.net>
Anno Siegel wrote:
> Unless you actually want to override a prototype on MySettings::db, and
> call it with the current value of @_, this is better written
>
> print MySettings::db()->{username};
I see your point, thanks.
> > Is this because the main app has loaded MySettings into memory, and now
> > /anything/ can reference stuff in MySettings directly? My Perl book hints at
> > this but doesn't confirm it and tends to stick to the basics.
>
> Whichever way you put it, a sub can be accessed from anywhere once it is
> defined, just like package variables. They are global to the entire
> program, no matter which file they are defined in. For variables, this
> is in direct contrast to lexicals. Lexical subs don't exist (yet), so
> subs are always global.
That's a great clear-up, thanks again :-)
Pete
------------------------------
Date: Sun, 02 Mar 2003 20:56:11 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Going around in circles with modules?
Message-Id: <x7smu57aj9.fsf@mail.sysarch.com>
>>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
AS> Whichever way you put it, a sub can be accessed from anywhere once it is
AS> defined, just like package variables. They are global to the entire
AS> program, no matter which file they are defined in. For variables, this
AS> is in direct contrast to lexicals. Lexical subs don't exist (yet), so
AS> subs are always global.
if you create a code ref (sub with no name) and assign it to a lexical,
it can't be accessed outside the scope of the lexical. this is good for
dispatch tables and related things. so if you really want a private sub
you can do this (sorta ugly):
my $sub = sub { blah } ;
and call it with
$sub->( args ) ;
p6 will have real lexical subs and methods.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
------------------------------
Date: Sun, 02 Mar 2003 21:32:17 +0000
From: Sharon Grant <peakpeek@purethought.com>
Subject: Re: how to read form output in perl procedure
Message-Id: <7dt46v4k17a9h8m0mrk78gb813retn0sod@4ax.com>
On Sun, 2 Mar 2003 14:39:00 -0000, in comp.lang.perl.misc, "Peter Cooper" <newsfeed2@boog.co.uk> wrote:
>On Sun, 2 Mar 2003 15:12:25 +0100, in comp.lang.perl.misc, "Hans" <qqhnieuwen.1@hccnet.nl> wrote:
>> I thought that with this script, the contents of the buffer ( the
>> information which the user filled in in the form) was put in the file
>> hans.html.
>> Hans.html is generated by the script, but is empty.
>
>Your code definitely won't work if you're using the GET method from your
>HTML form, as it doesn't send the query through to the STDIN. POST does,
>however.
>
>Either way, you shouldn't be doing it like that. Use the CGI module. It
>gives you a quick and easy interface to CGI. A basic intro:
>
>use CGI;
>my $q = new CGI;
>my @names = $q->param;
>print $q->param("$_") for @names;
>>question 2: perl debugger
>>I would like to debug the script above, but when it is started from the
>>html-form (after pushing the right button) I am not able to debug and when
>>started from a dos commandline with "c:> perl -d test.pl" there is no form
>>data.
>>Is it possible to debug a script when the script is started after pushing
>>the right button in a html form?
>On your second question, it sounds like you really need to get something
>like OpenPerl IDE
Not necessary
CGI.pm supports the entry of parameters during command-line debugging.
Parameters can be entered either on the command line, or passed in via
STDIN:
http://stein.cshl.org/WWW/software/CGI/#debugging
--
Sharon
------------------------------
Date: Mon, 3 Mar 2003 08:54:02 +1100
From: "Tintin" <me@privacy.net>
Subject: Re: how to read form output in perl procedure
Message-Id: <b3tuhs$1otpk5$1@ID-172104.news.dfncis.de>
"Hans" <qqhnieuwen.1@hccnet.nl> wrote in message
news:b3t3ds$bbh$1@news.hccnet.nl...
> Hello Newsgroup,
>
> I'm absolutely new to perl , so forgive me this stupid 2 questions.
>
> Question 1 ; Why does read (STDIN...) etc. does not work?
>
> From a html form I start the next script:
> #!/usr/bin/perl
> # Set Variables
> $varnaam = "hans.html";
> # Get the input
> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
> open (HA ,">$varnaam") || die "kan bestand niet openen!\n";;
> print HA $buffer;
> close (HA);
> exit;
Not even close to a correct CGI parser.
Use the standard Perl CGI.pm module.
> question 2: perl debugger
> I downloaded perl for Windows form the activestate website.
> I would like to debug the script above, but when it is started from the
> html-form (after pushing the right button) I am not able to debug and when
> started from a dos commandline with "c:> perl -d test.pl" there is no form
> data.
> Is it possible to debug a script when the script is started after pushing
> the right button in a html form?
Use the standard Perl CGI.pm module and you'll be able to debug from the
command line.
------------------------------
Date: Sun, 02 Mar 2003 23:31:42 +0100
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: how to read form output in perl procedure
Message-Id: <pan.2003.03.02.14.58.12.626348@aursand.no>
On Sun, 02 Mar 2003 15:12:25 +0100, Hans wrote:
> Question 1 ; Why does read (STDIN...) etc. does not work?
> [...]
You really shouldn't worry (in this case), as CGI.pm will do the work for
you. Example:
#!/usr/bin/perl
#
use strict,
use warnings;
use CGI;
my $cgi = CGI->new();
my $username = $cgi->param('username') || '';
my $password = $cgi->param('password') || '';
Install the CGI module and read the documentation;
'perldoc CGI'
> I would like to debug the script above [...]
Perl's debugging features aren't the best, but you _should_ use the
following statements in the beginning of all your scripts;
use strict;
use warnings;
use diagnostics;
The latter one gives you warnings etc. in plain english. :)
--
Tore Aursand - tore@aursand.no - http://www.aursand.no/
------------------------------
Date: Mon, 03 Mar 2003 06:45:59 +0900
From: <us-NOSPAM-enet2@watson-wilson.ca>
Subject: Image::Font examples?
Message-Id: <9fCDdUQ4CHA.341@newsgroup.korea.com>
Can anyone provide an example of how to use Image::Font to create
an image of a true type font string? I've looked at the perldoc
but it seems to be lacking examples.
Thanks.
------------------------------
Date: Mon, 3 Mar 2003 08:51:49 +1100
From: "Tintin" <me@privacy.net>
Subject: Re: Looking for a utility to remove duplicates
Message-Id: <b3tudn$1ogvrk$1@ID-172104.news.dfncis.de>
"Jade V Williams" <2001_jade@msn.com> wrote in message
news:b3t0dp$1qu$1@wisteria.csv.warwick.ac.uk...
> Does Perl have a utility to remove duplicates given certain criteria?
>
> For example, an array contains (fruit, weight):
>
> @fruits:
> [0] Banana: 0.12
> [1] Apple: 0.15
> [2] Pear: 0.16
> [3] Banana: 0.13
>
> I'd like to remove all duplicates in fruit field and when deciding which
one
> to remove, remove the heaviest.
>
> I did try coding this myself but after many, many lines of code it was
> getting increasingly complex
>
> Might it help to sort by weight first? I need to do this anyway, so before
> or after the removal of duplicates would be good.
>
> Thanks for any ideas you may have,
I take it that you have read the FAQ.
perldoc -q duplicate
------------------------------
Date: Sun, 02 Mar 2003 23:31:42 +0100
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: Looking for a utility to remove duplicates
Message-Id: <pan.2003.03.02.14.54.26.310049@aursand.no>
On Sun, 02 Mar 2003 13:21:20 +0000, Jade V Williams wrote:
> For example, an array contains (fruit, weight):
> [...]
Irrelevant in this case, as I see it; What matters here, is how you
_collect_ this data. A hash would also be a better way to store your
data, I guess;
%fruits = (
'Banana' => 0.12,
'Apple' => 0.15,
'Pear' => 0.16,
'Banana' => 0.13,
);
Excactly how you deal with the data depends on how you read it. This
might work for instance;
my %fruits = ();
while ( <DATA> ) {
chomp;
my ($fruit, $weight) = split( /\Q|\E/ );
if ( exists $fruits{$fruit} ) {
if ( $weight > $fruits{$fruit} ) {
$fruits{$fruit} = $weight;
}
}
else {
$fruits{$fruit} = $weight;
}
}
__DATA__
Banana|0.12
Apple|0.15
Pear|0.16
Banana|0.13
And, yes, you can - eventually - simplify the 'if' statement inside the
'while' block above. And, no, I haven't tested the code. :)
--
Tore Aursand - tore@aursand.no - http://www.aursand.no/
------------------------------
Date: Sun, 2 Mar 2003 10:09:03 -0600
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: my own "modules" for want of a better name
Message-Id: <slrnb64b4v.cug.tadmc@magna.augustmail.com>
Peter Cooper <newsfeed2@boog.co.uk> wrote:
> "Tad McClellan" <tadmc@augustmail.com> wrote in message
> news:slrnb642qk.cfe.tadmc@magna.augustmail.com...
>> FindBin.pm finds the directory where your program is.
>> Cwd.pm finds your current working directory.
>>
>> They are completely different concepts, though they may end up
>> resolving to the same directory in some cases.
>
> Fair enough, I've tended to find they're always the same,
If the CGI environment is the only one you use, then you might
get that misconception as most web servers are setup to set
the cwd to the same dir that the program is in before launching
the program.
> but I can think of a
> few situations (not Perl ones) where this might not be the case.
^^^
It is actually more like _most_ situations.
A program that is found via your PATH is not likely in the cwd for instance.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 02 Mar 2003 16:44:31 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: my own "modules" for want of a better name
Message-Id: <Pxq8a.59316$_J5.46471@nwrddc01.gnilink.net>
Peter Cooper wrote:
> "Tad McClellan" <tadmc@augustmail.com> wrote in message
> news:slrnb642qk.cfe.tadmc@magna.augustmail.com...
>> FindBin.pm finds the directory where your program is.
>> Cwd.pm finds your current working directory.
>>
>> They are completely different concepts, though they may end up
>> resolving to the same directory in some cases.
>
> Fair enough, I've tended to find they're always the same, but I can
> think of a few situations (not Perl ones) where this might not be the
> case.
'cuse me? In almost all cases they will be different.
It is actually quite uncommon that you would cd to a directory in $PATH to
run a program there or to run a program that is in your CWD.
The only exception being developers who edit the code and run the program
for immediate testing from the same directory. But even then as soon as the
coding is done you move the program to some production directory and it's no
longer in your CWD.
jue
------------------------------
Date: Sun, 2 Mar 2003 16:48:21 -0000
From: "Peter Cooper" <newsfeed2@boog.co.uk>
Subject: Re: my own "modules" for want of a better name
Message-Id: <hEq8a.10049$EN3.78274@newsfep4-glfd.server.ntli.net>
"Tad McClellan" <tadmc@augustmail.com> wrote:
> If the CGI environment is the only one you use, then you might
> get that misconception as most web servers are setup to set
> the cwd to the same dir that the program is in before launching
> the program.
It's not, but it's the only environment where I've needed to do checks on
directories in that way, so it works out to the same thing I guess :-)
> It is actually more like _most_ situations.
>
> A program that is found via your PATH is not likely in the cwd for instance.
Yeah, I didn't even think of non-CGI instances, to be honest.
Thanks for clearing that up.
Cheers,
Pete
------------------------------
Date: Sun, 2 Mar 2003 17:22:15 -0000
From: "Peter Cooper" <newsfeed2@boog.co.uk>
Subject: Re: my own "modules" for want of a better name
Message-Id: <X4r8a.10085$EN3.78483@newsfep4-glfd.server.ntli.net>
Jurgen Exner wrote:
> The only exception being developers who edit the code and run the program
> for immediate testing from the same directory. But even then as soon as the
> coding is done you move the program to some production directory and it's no
> longer in your CWD.
I work 95% from my own machine (where I'd change to the right directory) or on
CGI stuff over the Web, which is where the confusion set in, I automatically
assumed we were talking about that, and there the cwd is usually the same as the
directory where the script is. I mentioned that in my post, above.
Cheers,
Pete
------------------------------
Date: 2 Mar 2003 13:10:04 -0800
From: JasB19@aol.com (Jas)
Subject: Need Newbie Programmers for Freelance Group
Message-Id: <dca69bf.0303021310.bee42a@posting.google.com>
I am currenty looking for programmers how would like to join a
freelance programming group. I am looking for people who know or are
learning PHP and PERL. But other programmers are wanted. I am looking
for it to be a small group of around 5 people. It will be part time .
Please EMAIL me with all inqueries. As soon as i have a few people
dedicated we will start on our website.
JasB19@aol.com
Thanks
Jas
------------------------------
Date: Sun, 02 Mar 2003 18:08:00 +0100
From: Guenter <no.spam@gknw.de>
Subject: new Perl feature request: call into shared libs
Message-Id: <3E623A70.4000704@gknw.de>
Hi all,
although I dont like VBScript, what I really like from it is the
possibility to directly call into shared libs. This works not only on
Win32 but also on NetWare platform.
I really wish we could have a similar way of calling shared libs from
Perl, that would often simplify things and eliminate writing wrappers in
C, and that would be fine on every platform...
any oppinions??
and does someone know where I can post such a feature request?? Or are
here some core developers hanging around which could forward to the
right list/newsgroup??
thanks, Guenter.
------------------------------
Date: Sun, 02 Mar 2003 17:39:12 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: new Perl feature request: call into shared libs
Message-Id: <4lr8a.59879$_J5.40060@nwrddc01.gnilink.net>
Guenter wrote:
> Hi all,
> although I dont like VBScript, what I really like from it is the
> possibility to directly call into shared libs. This works not only on
> Win32 but also on NetWare platform.
> I really wish we could have a similar way of calling shared libs from
> Perl,
Shared libraries? Are you talking about what is more commonly known as
modules?
jue
------------------------------
Date: Sun, 02 Mar 2003 20:11:49 +0100
From: Guenter <no.spam@gknw.de>
Subject: Re: new Perl feature request: call into shared libs
Message-Id: <3E625775.5000402@gknw.de>
Hi Jürgen,
Jürgen Exner schrieb:
> Guenter wrote:
>
>>Hi all,
>>although I dont like VBScript, what I really like from it is the
>>possibility to directly call into shared libs. This works not only on
>>Win32 but also on NetWare platform.
>>I really wish we could have a similar way of calling shared libs from
>>Perl,
>
>
> Shared libraries? Are you talking about what is more commonly known as
> modules?
no. Shared libs are on Windows *.DLL, on Unix *.so, ...
f.e. you can do from VBScript something like:
declare function ExportedFunction lib "XYZ.DLl" (a as string, b as
string) as integer
and then use this function as if you have it in your call, but you
directly call into a lib from the OS...
Guenter.
------------------------------
Date: 2 Mar 2003 20:55:39 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@post.rwth-aachen.de>
Subject: Re: new Perl feature request: call into shared libs
Message-Id: <b3tr4b$gk4$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Guenter:
> although I dont like VBScript, what I really like from it is the
> possibility to directly call into shared libs. This works not only on
> Win32 but also on NetWare platform.
> I really wish we could have a similar way of calling shared libs from
> Perl, that would often simplify things and eliminate writing wrappers in
> C, and that would be fine on every platform...
>
> any oppinions??
This functionality exists for windows and is provided by Win32::API.
I am not sure about a general solution though. Doesn't accessing
functions from a shared object file (.so) usually require linking as
last step?
Not quite what you are asking for but coming relatively close is
Language::XS that allows to programmatically build XS code with which
you can of course access anything C can access, including
shared-libraries. I never tested it though.
> and does someone know where I can post such a feature request?? Or are
> here some core developers hanging around which could forward to the
> right list/newsgroup??
You can send such things to perl5-porters@perl.org. Conveniently, use
the 'perlbug' program for that that comes with a standard Perl
distribution. It's no just for bugs but also for wishlist items.
And yes, some of the perl5-porters hang around in this group as well.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Sun, 02 Mar 2003 23:49:31 +0100
From: Guenter <no.spam@gknw.de>
Subject: Re: new Perl feature request: call into shared libs
Message-Id: <3E628A7B.5070000@gknw.de>
Hi,
Tassilo v. Parseval schrieb:
> This functionality exists for windows and is provided by Win32::API.
no, not really; there you can only access some functions...
and you cant define others...
> I am not sure about a general solution though. Doesn't accessing
> functions from a shared object file (.so) usually require linking as
> last step?
no, that's only true with static libs; you can import symbols from
dynamic libs at runtime from your c code...
> You can send such things to perl5-porters@perl.org. Conveniently, use
> the 'perlbug' program for that that comes with a standard Perl
> distribution. It's no just for bugs but also for wishlist items.
thanks, will do...
> And yes, some of the perl5-porters hang around in this group as well.
Guenter.
------------------------------
Date: 2 Mar 2003 10:34:33 -0800
From: apryl.banister@cpa.state.tx.us (Apryl Ferrell)
Subject: Re: Problem running Sybperl scripts as root user
Message-Id: <35a88b91.0303021034.34e99f2@posting.google.com>
Hello joachim,
Thank you for your response and suggestions! The reason I used "su
anybody" in my example was to show that while the root user is unable
to run the scripts, an "anybody" user with root's environment runs the
script successfully. This was to be the proof that it doesn't seem to
be a problem with root's environment because root's environment is
used in both instances.
We also have another box which runs these exact scripts with no
problems, and the problem box also used to work fine, which adds to
the mystery (pain? :) ). Then, the question must be "what changed?"
The only thing I know that changed was that Apache was stopped and
restarted on the box, but that doesn't seem like it would be the
cause, since problems occur when running the script by hand as root.
When running an IP trace on the box, to see what's happening when the
root user runs the script, a FIN|ACK is sent to the sybase box
immediately after the request, so the sybase box never has the chance
to return an answer. When running the script as any other user but
root, the normal three-way handshake occures, the request and
appropriate response are given and then the FIN|ACKS and ACKS take
place. This proves that it's not a firewall problem.
I will try doing as you suggest and including the environmental
variables in the script. The only one I have now included is the
$SYBASE variable, but it sure won't hurt to add the others and who
knows! :) Thanks for the suggestion.
Apryl
jring@web.de (Joachim Ring) wrote in message news:<3ae246c1.0303010145.7125212d@posting.google.com>...
> first of all, you shouldn't be using "su newuser" but "su - newuser" -
> always!
> "su newuser" just changes the euid but leaves you in the environment
> of the old user, which is at best incoherent if not outright dangerous
> (we loved to have some silghtly modified versions of popular commands
> which tried to add another root user fairly high in our paths back at
> university and call over the admin to fix something ;-)
>
> and your problem is most probably due to some other environment stuff
> missing when rhe script fails. i'm not a sybase guy but with oracle
> there's a whole bunch of env variables you want to set before anything
> goes, i guess it's similar with sybase. maybe ask in a sybase group.
>
> one more thing, you want to set these values in your cgi-script as the
> cgi's might run under the nobody user but don't get the environment an
> interactive nobody gets...
>
> joachim
------------------------------
Date: Sun, 02 Mar 2003 16:05:26 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
To: "Peter Cooper" <newsfeed2@boog.co.uk>
Subject: Re: The perl CD bookshelf
Message-Id: <1143d3401b32aae46530c6212aa0ea5d@news.teranews.com>
>>>>> "Peter" == Peter Cooper <newsfeed2@boog.co.uk> writes:
Peter> BTW, I was looking on Google for some Perl related stuff earlier, and found what
Peter> I wanted.. then realised I was in an online rip off of the Perl CD Bookshelf.
Peter> It's a Russian site. Not very hard to find, this exercise is left to the reader
Peter> :-)
Please report those when you find them to <infringement@oreilly.com>.
Otherwise, O'Reilly doesn't make their money, and I don't make my
money, and I don't get to write more books.
--
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: Sun, 02 Mar 2003 18:38:06 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Using a (config) file relative to a module location...
Message-Id: <0n046vsgvhb9oodkn8liljt3bpu102b43l@4ax.com>
If I want to "use" (say, open, write, or both) a file (e.g. a config
file) in the same dir as a script (or in a directory identified by a
path relative to that dir), browsing through the docs I found out that
I can use the FindBin module.
But then I thought that I might just stuff the relevant code in a
module assuming implicitly that a relative path would have been
interpreted relative to the module's location. By experimenting I
discovered that it is not the case.
In the end, reading some other docs, I wrote the following code:
# -*- mode: perl -*-
package foo;
use strict;
use warnings;
use File::Basename;
require Exporter;
our @ISA=qw/Exporter/;
our @EXPORT_OK=qw/foo/;
sub foo {
open my($fh), "<", dirname($INC{'foo.pm'}) . "/foo.txt"
or die "Can't open config file 'foo.txt': $!\n";
return <$fh>;
}
1;
__END__
Eventually, it works as intended, but are there any issues with it?
What is the "correct" way to accomplish this task, anyway?
Also, even if use File::Basename to get an OS-independent behaviour
(at an intermediate stage I just used 's|[^/]+$||'), I still use "/"
as a directory separator on the open() line (don't know how to do it
otherwise[*]).
As a side question, not that using a module is a major concern for me,
but both for what regards FindBin and my issue, aren't these matters
so important that a built-in facility should be provided by the
interpreter? (e.g. yet another built-in variable)
[*] OK: I'm aware that I can give a peek into File::Basename itself,
but... isn't this getting a bit too complicated?!?
Michele
--
>It's because the universe was programmed in C++.
No, no, it was programmed in Forth. See Genesis 1:12:
"And the earth brought Forth ..."
- Robert Israel on sci.math, thread "Why numbers?"
------------------------------
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 4651
***************************************
