but my ISP won't let me install modules.

Do yourself a favour. Get a new ISP. Writing and debugging Perl/CGI scripts without the ability to install modules +/- access the error logs is a nightmare. If you check out the banner ads along the top of the screen you will find suitable ISPs. You want shell access.

All of the Perl XML parsers are built on top of C code libraries which HAVE TO BE INSTALLED to work. The only exception is XML::SAX::PurePerl which as the author notes is dog slow and somewhat immature. You could use the functionality of this module simply by cutting and pasting the code to the end of your script. This works for most pure perl modules but is not recommended.

As for your task updating and parsing are two different issues. Before you even start you need to logically organise your thoughts on what you want to achieve. Having broken down the problem into smaller parts you should then try to code a solution. If (when) it does not work as you expect you will find the Perlmonks most helpful to those who are trying to help themselves and post coding proving same. New Monks, CGI Help Guide, and A Guide to Installing Modules would be reasonable places to start.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

In addition to the references and comments provided by others above, I would recommend your looking for a Perl Mongers group in your local area - The Australian and New Zealand Perl Monger groups are listed at http://www.pm.org/groups/oceania.html. These perl-user and advocacy groups can provide an invaluable resource for your learning of Perl with fairly regular meetings, presentations and social get-togethers. Furthermore, these groups can help you obtain a more frontline view of the use of Perl in the industry and how to best develop your Perl knowledge.

While I cannot vouch for the Brisbane or Perth groups, the Melbourne and Sydney Perl Monger groups are quite active. The Canberra group is fairly new but is starting to gain momentum.

perl -le 'print+unpack("N",pack("B32","00000000000000000000000111111111"))'

what you wish for can be done, it's just not easy to do nor to explain. the basic idea goes like this.

• build on a development machine. you need to match architecture and OS.
• build the needed libraries. static is best unless you want real pain.
• build the perl module so that it uses the static library and installs in it's own directory.
• copy your directory of perl modules up to your web space and use them from your scripts.

sounds easy, and sometimes it is.

$ cd /tmp/libfoo-0.0.1
$ ./configure --prefix=/tmp/support
$ make
$ make install
$ ls /tmp/support/lib
libfoo.a  libfoo.so  libfoo.so.1
$ rm /tmp/support/libfoo.so*
$ cd /tmp/Foo-0.0.1
$ perl Makefile.PL PREFIX=/tmp/support
$ make
$ make test
$ make install
$ scp -r /tmp/support/lib/perl5 me@provider:public_html/
$ cat >/tmp/test.pl
#!/path/to/providers/perl
use lib '/path/to/me/public_html/perl5';
use Foo;
print "Content-type: text/plain\r\n\r\nWoot!";
^D
$ chmod ugo+rx /tmp/test.pl
$ scp /tmp/test.pl me@provider:cgi-bin/
[download]

cross fingers and try it out. be warned, it can be much harder than this would suggest and it's better to try it local first to make sure it works. be prepared for pain.

As a matter of fact IE 5.5 rightly configured will also be able to perform XSLT-transformations. What you like to have however, are server-side transformations.

I have been able to pull this off on an Apache Web-server with AxKit-modules and Sablotron as the transformation engine. More info: Axkit and Sablotron.

Ask your ISP nicely to install this additional functionality. He might be able to charge his customers something extra for the added functionality!

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

At least he listened to the sage advice - filled in the blanks on his own and everything! Quite savvy for a 13 year old :)