Yuck!

Sorry, had to get that out of the way first. :P Here is what i would do: use a database! All you need to store is a unique identifier for the user and the contents of the page itself. Then, your CGI script accepts the user id as a parameter, fetches the page for that uid, and then displays it in a text area that uses HTMLArea to turn the text area box into a ... yes it really works ... WYSIWYG HTML editor. Now your client doesn't even have to know how to "code" HTML. :)

I suppose you could achieve the same effects by opening the index file, reading the contents into the text area and re-writing the index file upon submit ... and if you really only need to do this for one user then the only two hard parts you have will be:

1. setting the permissions so you can overwrite the file
2. getting HTMLArea up and running and configuring it

Oh, and by the way, your system usage looks wrong. Try passing a list instead:

system (
   'perl',
   '-pi.bak',
   '-e',
   's/Old Spotlight/Product Spotlight/',
   '/var/www/html/acs/new/index.html',
);
[download]

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

AT a quick glance, HTMLArea will give them too much power to potentially screw up the page and it appears to run on Window$ only.
No Good.

My system call does work on my production server though I haven't tried it on the actual host. I will give your sample a try.

So then, is it better to use FILEHANDLE to open the file and make the substitutions needed for the product number and category in the link tags and the desrciption or make them using the inplace-editing mode using system?

Thanks Again for all the help and suggestions
Joe

"...HTMLArea will give them too much power to potentially screw up the page..."

Well, don't let them change the ENTIRE PAGE! :) Just the smallest amount necessary. Now then, if they need to able to change, say, some text that is located inside a table, well, first off the WYSIWYG editor will allow them to add rows and so forth, but secondly, maybe you should determine all the fields that your user can change and provide a standard form so they can only change the values, not the presentation.

And yes, HTMLArea really only works well on Windows boxes, but 99% of the users "out there" have Windows. The latest versions of Firebird and Mozilla will render HTMLArea V3.0, but i have had intermittent results with those browsers on Linux boxes - some work and some don't. But remember that you don't have to run IIS or anything like that to get HTMLArea to work. It is a client side technology, and surely your user has a Windows box available. (I actually had a client that only used Macs, and thus i had to provide a file upload alternative).

As for the last question ... i would rather read in the file, display it for the user somehow, and then write the entire file back out instead of using in-place editting. Having to fork and exec another shell to the Perl interpreter should be avoided when it can.

Best of luck to you! :)

UPDATE:
Here is a quicky script that might help you out. As long as you can set the permissions for the store file (i named it CONTENT with no extension for no real reason) you should be good to go. I used CGI.pm, mainly because it is readily available and it handles HTML entity escaping for you.

#!/usr/bin/perl -T

use strict;
use warnings;
use CGI qw(:standard);

print header,start_html('mini cms');

if (param('content')) {
   open FILE,'>','CONTENT' or error("Can't write content file: $!");
   print FILE param('content');
   close FILE;
}

open FILE,'<','CONTENT' or error("Can't read content file: $!");
my $content = do{local $/; <FILE>};
close FILE;

print start_form,
   textarea(content => $content, 10,50),br,
   submit,
   end_form,
   div({id=>'content'},$content),
;

sub error {
   print pre(shift),end_html;
   exit;
}
[download]

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)