Re: .bml files not executing in apache
Hi Randy,
Thanks for your reply. Please excuse my utter newbie status at all this. Ok,
looking at your message and the documentation for mod_perl as well as the LJ
documentation here's what I see.
BML is actually setup up as a perl module Apache::BML
its excuted in a file called modperl.pl In httpd.conf there is a
PerlRequire c:/livejournal/cgi-bin/modperl.pl
but, as you can see if you try to get on my site
(www.thefreemachine.cc/index.bml) it doesn't excute. So whats missing that
would get httpd to call it when it receives a request for a .bml file. Is
there something I'm missing here (this is running on a windows machine), the
code seems fairly straightforward
PerlInitHandler +Apache::LiveJournal
DirectoryIndex index.html index.bml
});
unless ($LJ::SERVER_TOTALLY_DOWN)
{
Apache-httpd_conf(qq{
# BML support:
PerlSetVar BMLDomain lj-$LJ::DOMAIN
PerlModule Apache::BML
Perl
Apache::BML::load_config(lj-$LJ::DOMAIN, $LJ::HOME/cgi-bin/bmlp.cfg);
/Perl
Files ~ \\.bml\$
SetHandler perl-script
PerlHandler Apache::BML
/Files
});
}
any help you could give would be greatfully appreciated.
Randy R
$r-path_info question
Hi All, If i use hte following configuration: apache.conf Location /auto/thumbnails SetHandler perl-script PerlHandler My::Thumbnails /Location Then in my handler sub in Thumbnails.pm do: == my $r = instance Apache::Reuest(shift); print STDERR PathInfo: $r-path_info().\n; Then i go to the url: == http://localhost/auto/thumbnails/images/a.gif In my error log i get == PathInfo: /thumbnails/images/a.gif However: if i create an 'auto' directory in my document root (something that was not there before) i get: PathInfo: /images/a.gif (which i like :-) Is this is feature or a bug, does path_info not check the 'Location' it matced the handler to or is it meant to look at the directory structure? simran.
Terminating an HTTP process
Hi All, We're running Mason 1.04 (Apache/1.3.22 (Solaris) mod_perl/1.26 mod_ssl/2.8.5 OpenSSL/0.9.6b) which connects to a number of Oracle databases, so we are using Apache::DBI for connection pooling. As we understand it, each process has its own connection pool that lasts for the life of that process (i.e. each child collects its own set of DB handles until it dies). Whilst this is normally not an issue, when we experience network problems, the number of available connections on some crucial databases can quickly run out, which many open connections sitting idle in the pool of various clients using other DBs, etc. What we'd like to do is send some kind of quit signal to the process so that it finishes that transaction and dies, instead of waiting until MaxRequestsPerChild. This will ensure that DB handles for this particular DB will not be idly pooled, but instead constantly in use. Is there a command to do this? (e.g. like 'abort', but one that completes the transaction successfully, and kills the child process). (e.g. $r-die() :-) Also, does anyone know how to get the current RequestsPerChild counter (that MaxRequestsPerChild evaluates against)? Thanks! Mark
Re: Terminating an HTTP process
On Tue, 23 Jul 2002 18:58:14 +1000
Mark Ridgway [EMAIL PROTECTED] wrote:
Hi All,
We're running Mason 1.04 (Apache/1.3.22 (Solaris) mod_perl/1.26
mod_ssl/2.8.5 OpenSSL/0.9.6b) which connects to a number of Oracle
databases, so we are using Apache::DBI for connection pooling.
As we understand it, each process has its own connection pool that
lasts for the life of that process (i.e. each child collects its own
set of DB handles until it dies).
Whilst this is normally not an issue, when we experience network
problems, the number of available connections on some crucial databases
can quickly run out, which many open connections sitting idle in the
pool of various clients using other DBs, etc.
What we'd like to do is send some kind of quit signal to the process
so that it finishes that transaction and dies, instead of waiting until
MaxRequestsPerChild. This will ensure that DB handles for this
particular DB will not be idly pooled, but instead constantly in use.
Is there a command to do this? (e.g. like 'abort', but one that
completes the transaction successfully, and kills the child process).
(e.g. $r-die() :-)
Also, does anyone know how to get the current RequestsPerChild
counter (that MaxRequestsPerChild evaluates against)?
Hi Mark,
if you don't need persistent connections for all Oracle DBs
you can try to use some nonpersistent connections by setting
'dbi_connect_method' property to 'connect' in DBI connect
hash options:
my $dbh = DBI-connect('dbi:...',... ,{'dbi_connect_method' = 'connect'});
However I think that the right solution is a connection pool server
like SQLRealy (it work very well with Oracle, MySQL, PostgresSQL, DB2, etc)
Bye
Enrico
=
Enrico Sorcinelli - Gruppo E-Comm - Italia On Line S.p.a.
E-Mail: [EMAIL PROTECTED] - [EMAIL PROTECTED]
=
Re: $r-path_info question
* simran [EMAIL PROTECTED] [2002-07-23 05:11]: However: if i create an 'auto' directory in my document root (something that was not there before) [-- snip --] Is this is feature or a bug, does path_info not check the 'Location' it matced the handler to or is it meant to look at the directory structure? This is how Apache handles path_info: it is the extra stuff after the translation handler has found a directory and filename. It starts at the left, and walks towards the right, until it finds the last component that is a directory, and then the next piece is the file (no existance check is done at this point). The rest of it is path_info. For example: A request for /foo/bar/baz/quux, with a document root of /document/root (assuming no Alias directives, that complicates things slightly), and assuming that /document/root/foo is the last *directory* in the path that exists, Apache does this: 1. look for /document - yep 2. look for /document/root - yep 3. look for /document/root/foo - yep 4. look for /document/root/foo/bar - nope So /document/root/foo/bar is r-filename, and /baz/quux is path_info. To reiterate: this is not a mod_perl thing (bug/whatever) but an Apache one. (darren) -- An operating system is just a name you give the features you left out of your editor. -- Per Abrahamsen in comp.emacs
Change program name of httpd process
Hello, all! I need to change proctitle (called $PROGRAM_NAME or $0 in perl) of httpd process from mod_perl. Simple change of $0 variable works well for standalone perl program, but don't work under mod_perl. I'm not sure if it's possible, but if anyone have an idea how to do this please help. Regards, Oleg Shaikhatarov [EMAIL PROTECTED]
T switch is ignored modperl2.0
Greetings, I have put PerlSwitches -T in my httpd.conf file, yet keep getting the following warning in the server's error_log: [Tue Jul 23 10:43:06 2002] [warn] T switch is ignored, enable with 'PerlSwitches -T' in httpd.conf Any suggestions? Thank you, John Kent Webmaster Naval Research Laboratory Monterey, CA
Re: T switch is ignored modperl2.0
I have put PerlSwitches -T in my httpd.conf file, yet keep getting the following warning in the server's error_log: [Tue Jul 23 10:43:06 2002] [warn] T switch is ignored, enable with 'PerlSwitches -T' in httpd.conf You want the PerlTaintCheck On directive. xoxo, Andy -- 'Andy Lester[EMAIL PROTECTED] Programmer/author petdance.com Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$) [unpack'C*',n2]3%+\34.'%.'^%4+!o.'])
Re: Mail::Sender modperl.
Another chunk of sample code is available in chapter 15 of The
mod_perl Developer's Cookbook. The Cookbook::Mail module uses
MIME::Lite and Email::Valid to send data/attachments around.
Feel free to adapt it to suit your needs:
http://www.modperlcookbook.org/code/ch15/Cookbook/Mail.pm
Regards
On Mon, Jul 22, 2002 at 10:48:52AM -0700, Goehring, Chuck Mr., RCI - San Diego wrote:
Richard,
I also use MIME::Lite (on Win2000) with mod_perl. Found it to be quite reliable and
it supports attachments and receipts like so:
if($aReceipt ne '') { # If return receipt requested.
$msg-add(Disposition-Notification-To= $aApobj-getEmail_Address);
}
Chuck
-Original Message-
From: Richard Clarke [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 20, 2002 6:28 AM
To: [EMAIL PROTECTED]
Subject: Mail::Sender modperl.
List,
Have any of you had any problems using Mail::Sender from within
mod_perl. My script seems to just sit there waiting for $sender-Open to
do anything. I will email the author also but imagined he *might* not be
familiar with mod_perl so won't be able to offer any suggestions.
Anyone? I looked through the archives but saw no reference to a problem
like this. Some people indicated much success with Mail::Sender (not so
for me however!).
Second, the recommended solution for sending mails is to instead put
them on a queue for an external daemon to handle. My question is, is
there a standard implementation people use when doing this. Is the KISS
theory invoked and the outoing mail simply written to some plain text
spool file or do people use something more involved like writing the
to,cc,from,subject,body test to a database and storing any temporary
files (attachment) in a directory for later encoding?
Ric
p.s. here is an excerpt from my apache log indicating precisely what happens
220 mail.likewhoa.com ESMTP Postfix
421 Error: timeout exceeded
ehlo localhost
mail from: [EMAIL PROTECTED]
rcpt to: [EMAIL PROTECTED]
data
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
X-Mailer: Perl script null
using Mail::Sender 0.7.14.1 by Jenda Krynicky
running on localhost (127.0.0.1)
under account root
Date: Sat, 20 Jul 2002 13:18:12 -
Message-ID: [EMAIL PROTECTED]
Subject: msg msg msg
close sender
.
quit
done
The request took 305.710375070572 seconds
--
Paul Lindner[EMAIL PROTECTED] | | | | | | | | | |
mod_perl Developer's Cookbook http://www.modperlcookbook.org/
Human Rights Declaration http://www.unhchr.ch/udhr/
Mod Perl build problem with perl 5.8.0
I am having a problem building mod_perl with the new perl 5.8.0. This does not occur with perl 5.6.1. (All DSO, BTW) I build using the CPAN module, with a .makepl_args.mod_perl file in my $HOME dir. This has worked just fine for years, through multiple versions of perl, mod_perl, Apache, and Solaris. Now, when the make test of mod_perl is run, I see this: internal/http-get.Internal Server Error internal/http-get.dubious Test returned status 29 (wstat 7424, 0x1d00) DIED. FAILED tests 1-16 Failed 16/16 tests, 0.00% okay internal/http-postInternal Server Error internal/http-postdubious Test returned status 29 (wstat 7424, 0x1d00) DIED. FAILED tests 1-7 Failed 7/7 tests, 0.00% okay All other tests pass just fine, And in the error_log, I see these: (besides the 'expected' errors) [Tue Jul 23 10:48:15 2002] [error] Undefined subroutine Apache::exit called at /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/test line 129, fh1b chunk 1. print() on closed filehandle FH at /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/hooks.pl line 15, fh1b line 1. print() on closed filehandle FH at /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/hooks.pl line 26, fh1b line 1. [Tue Jul 23 10:48:16 2002] [error] can't open /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/docs/.htaccess at /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/hooks.pl line 51, fh1b line 1. [Tue Jul 23 10:48:18 2002] [error] END block was not run for /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/test [Tue Jul 23 10:48:20 2002] [error] END block was not run for /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/test This is with perl 5.8.0, mod_perl 1.27, Apache 1.26, and Solaris 8. I build all this from source, (except Solaris!!:), using gcc 2.95. Apache is compiled with these options passed to Configure by the .makepl_args.mod_perl file: ( as well as some site-specific options, like --prefix=, etc) --enable-module=all --enable-shared=max --disable-module=example --disable-module=auth_db --verbose --server-uid=httpd --server-gid=www (the auth_db module will not build with Berkeley DB 4.x, which is what I have to use for other apps on the same machine. Fortunately, I do not use that module, so I don't care. :) perl -V: Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris uname='sunos rapier 5.8 generic_108528-14 sun4u sparc sunw,sun-blade-100 ' config_args='-Dcc=gcc -Ubincompat5005 -Uuselargefiles -Uusemymalloc -Dloclibpth=/opt/BerkeleyDB/lib -Uinstallusrbinperl -Dprefix=/opt/perl5.8.0-mod-perl-Apache-1.3.26 -Dscriptdir=/opt/perl5.8.0-mod-perl-Apache-1.3.26/scripts [EMAIL PROTECTED] -Dldflags=-R/opt/BerkeleyDB/lib:/opt/lib -Dmydomain=.mcgill.ca -Dmyhostname=rapier [EMAIL PROTECTED] -Dlocincpth=/opt/BerkeleyDB/include -Dcf_by=David McCabe -d' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/opt/BerkeleyDB/include', optimize='-O', cppflags='-fno-strict-aliasing -I/opt/BerkeleyDB/include' ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers='solaris2.8' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags ='-R/opt/BerkeleyDB/lib:/opt/lib -L/opt/BerkeleyDB/lib' libpth=/opt/BerkeleyDB/lib /usr/lib /usr/ccs/lib /usr/local/lib libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -R/opt/BerkeleyDB/lib:/opt/lib -L/opt/BerkeleyDB/lib' Characteristics of this binary (from libperl): Compile-time options: Built under solaris Compiled at Jul 22 2002 12:12:58 @INC: /opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/McGill/sun4-solaris /opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/McGill /opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/5.8.0/sun4-solaris /opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/5.8.0 /opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/site_perl/5.8.0/sun4-solaris
possible buget in CGI.pm
Hi All, We are implementing mod_perl here for internal intranet use. We have discovered a possible buglet in CGI.pm. We do not want CGI.pm to return XHTML as it upsets Verity indexing (long story). So in Apache::Registry executed scripts we use: use CGI qw( -no_xhtml ); But on the first invocation it returns normal HTML. On second invocation it ignores this directive and returns XHTML. We started a dev server with -X to confirm this. It would appear CGI resets its globals somewhere. Can someone confirm this? Also is this the right forum for this ? Which bit of the plot have I missed? Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81 Thanks, Greg Cope This message and any attachment has been virus checked by Pfizer Corporate Information Technology, Sandwich.
ANNOUNCE: Mason 1.12
This release has a number of important improvements and it is highly recommended that anyone use Mason 1.10 or 1.11 upgrade immediately in order to fix a nasty memory leak in ApacheHandler. 1.12 is also quite a bit faster than previous 1.1x versions. Those folks still using 1.0x or earlier should upgrade if they want to play with new features, but should not that there are a number of backwards incompatibilities in the newest versions, so if you have working code in production that you don't want to change, don't upgrade! With that said, here are the changes for 1.12: 1.12 [ ENHANCEMENTS ] - Various optimizations have been added to this release in order to address the fact that Mason 1.11 is quite a bit slower than 1.05. One major factor was optimizing Params::Validate and Class::Container, so for that reason this version of Mason requires Params::Validate 0.24 and Class::Container 0.07. With these modules installed, this release shows improvements of up to 50-60% in benchmarks that stress Mason's weaknesses, with other benchmarks showing up to a 100% improvement. - Made subclassing CGIHandler more useful by breaking out its arg processing into a request_args method, just like ApacheHandler. - Added alter_superclass method to Request class, for use by Request subclasses. See the HTML::Mason::Subclassing document for details. [ BUG FIXES ] - Fix HTML generated for error messages so that tags balance out. Unbalanced table tags caused this page to not display properly with Netscape 4.x. - Fix nasty memory leaks in ApacheHandler.
Re: possible buget in CGI.pm
Hi,
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2002-07-23 11:26]:
We are implementing mod_perl here for internal intranet use. We have
discovered a possible buglet in CGI.pm.
We do not want CGI.pm to return XHTML as it upsets Verity indexing
(long story).
So sorry to hear about that.
So in Apache::Registry executed scripts we use:
use CGI qw( -no_xhtml );
But on the first invocation it returns normal HTML. On second
invocation it ignores this directive and returns XHTML. We started a
dev server with -X to confirm this. It would appear CGI resets its
globals somewhere.
Can someone confirm this?
Yes:
From CGI.pm, version 2.81:
35 # Here are some globals that you might want to adjust
36 sub initialize_globals {
37 # Set this to 1 to enable copious autoloader debugging messages
38 $AUTOLOAD_DEBUG = 0;
39
40 # Set this to 1 to generate XTML-compatible output
41 $XHTML = 1;
42
43 # Change this to the preferred DTD to print in start_html()
44 # or use default_dtd('text of DTD to use');
45 $DEFAULT_DTD = [ '-//W3C//DTD HTML 4.01 Transitional//EN',
46 'http://www.w3.org/TR/html4/loose.dtd' ] ;
47
Judging from line 35 you might want to adjust some of those globals.
If you are using CGI in the OO way, you can just subclass CGI:
package My::CGI;
use base qw(CGI);
sub initialize_globals {
CGI::initialize_globals();
$CGI::XHTML = 0;
}
And then:
my $q = My::CGI-new;
Of course, I haven't tested this.
Another option is to call:
CGI-import(-no_xhtml);
at the top of your Registry script, which will be executed every time,
whereas the use CGI qw( -no_xhtml ); is only being called at compile
time.
(darren)
--
You can put a man through school, but you cannot make him think.
-- Ben Harper
mod_perl with a perl built with -Dusethreads, will it work?
I would like to install Sendmail::Milter which needs a perl built with thread support. Last time I tried to use a perl built with thread support (5.6.x), mod_perl didn't like it. Is this still the case with 5.8.0? Is anybody using mod_perl with a perl built with -Dusethreads? Thanks, Brian -- Linux 2.4.18 libc 2.1.3 apache 1.3.26 mod_perl 1.27
RE: possible buget in CGI.pm
-Original Message-
From: darren chamberlain [mailto:[EMAIL PROTECTED]]
Can someone confirm this?
Yes:
Good I'm not mad :-)
From CGI.pm, version 2.81:
35 # Here are some globals that you might want to
adjust
36 sub initialize_globals {
37 # Set this to 1 to enable copious autoloader
debugging messages
38 $AUTOLOAD_DEBUG = 0;
39
40 # Set this to 1 to generate XTML-compatible output
41 $XHTML = 1;
42
43 # Change this to the preferred DTD to print in
start_html()
44 # or use default_dtd('text of DTD to use');
45 $DEFAULT_DTD = [ '-//W3C//DTD HTML 4.01 Transitional//EN',
46
'http://www.w3.org/TR/html4/loose.dtd' ] ;
47
Judging from line 35 you might want to adjust some of those globals.
If you are using CGI in the OO way, you can just subclass CGI:
package My::CGI;
use base qw(CGI);
sub initialize_globals {
CGI::initialize_globals();
$CGI::XHTML = 0;
}
And then:
my $q = My::CGI-new;
Of course, I haven't tested this.
Another option is to call:
CGI-import(-no_xhtml);
at the top of your Registry script, which will be executed every time,
whereas the use CGI qw( -no_xhtml ); is only being called at compile
time.
Lookout has givenup putting the ''s in!. grh
Thanks for those Darren,
With out wishing to be rude, the above are all workarrounds the bug (ie it
should not overide the -no_xhtml pragma), and we've used our own.
The subclssing one was good thou! and I did not know the CGI-import one.
Thanks,
Greg
(darren)
--
You can put a man through school, but you cannot make him think.
-- Ben Harper
This message and any attachment has been virus checked by
Pfizer Corporate Information Technology, Sandwich.
Re: possible buget in CGI.pm
I'm aware of the problem, but I haven't been able to track it down. Any help is welcome. Lincoln On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote: Hi All, We are implementing mod_perl here for internal intranet use. We have discovered a possible buglet in CGI.pm. We do not want CGI.pm to return XHTML as it upsets Verity indexing (long story). So in Apache::Registry executed scripts we use: use CGI qw( -no_xhtml ); But on the first invocation it returns normal HTML. On second invocation it ignores this directive and returns XHTML. We started a dev server with -X to confirm this. It would appear CGI resets its globals somewhere. Can someone confirm this? Also is this the right forum for this ? Which bit of the plot have I missed? Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81 Thanks, Greg Cope This message and any attachment has been virus checked by Pfizer Corporate Information Technology, Sandwich.
Mail programmes using .htpasswd to verify username/password access
Does anyone know of such a programme? -- Member - Liberal International On 11 Sept 2001 the WORLD was violated. This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED] Society MUST be saved! Extremists must dissolve. Beware of defining as intelligent only those who share your opinions
Re: possible buget in CGI.pm
On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote: We do not want CGI.pm to return XHTML ... So in Apache::Registry executed scripts we use: use CGI qw( -no_xhtml ); But on the first invocation it returns normal HTML. On second invocation it ignores this directive and returns XHTML. We started a dev server with -X to confirm this. It would appear CGI resets its globals somewhere. ... Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81 On Tuesday 23 July 2002 12:47 pm, Lincoln Stein wrote: I'm aware of the problem, but I haven't been able to track it down. Any help is welcome. Lincoln, Greg, mod_perl list: The problem appears to be that the -no_xhtml option is only processed in _setup_symbols. This is called only during import() and compile(), and sets $XHTML appropriately. However, $XHTML is reset to 1 in initialize_globals(). _reset_globals() is an alias for this as well. initialize_globals() is called only once in the startup execution (has a comment Make mod_perl happy) of the module. However, _reset_globals is called during new(), and is registered with mod_perl as a cleanup handler. What this means is that after the first execution, the cleanup handler fires and _reset_globals() is called, which calls initialize_globals(), which then sets the global $XHTML to 1. QED. It looks like -nosticky suffers from the same fate as well, and I would venture to guess that all of the variables reset in initialize_globals() are not being set properly according to the values parsed in _setup_symbols(). e.g. $NPH, $NOSTICKY, $DEBUG, $HEADERS_ONCE, etc. I think the 'undef $NPH' in new() was an attempt to address this for that variable. But it still leaves the rest out in the cold. Because _setup_symbols eats the parameters (the options passed in on the 'use' line), there's no way to call it again later in new() since it ran at compile time. One might preserve the options passed in to _setup_symbols() and then have new() call it again with those options to make sure that the new instance retains the options set on the 'use' line. LDS, You might want to separate the option parsing from the autoload magic in _setup_symbols(), and just call the option parsing part with the saved options from the 'use' line in the cleanup handler. Mike808/ -- () Join the ASCII ribbon campaign against HTML email and Microsoft-specific /\ attachments. If I wanted to read HTML, I would have visited your website! Support open standards.
