AW: CGI-BIN Help/Advise - editing a file - HOW ?
[email protected] (Thomas Bätzler) Mon, 15 Mar 2010 09:25:18 +0100
| Newsgroups | perl.beginners.cgi,perl.beginners |
|---|---|
| Message-ID | <[email protected]> |
newbie01 perl <[email protected]> asked: > At the moment, I have some sort of INI/config file that I edit = manually > via vi. These config files are "simple" delimited file that are used = by > some of the scripts running on the server. >=20 > I want to be able to the same thing via cgi-bin, can anyone advise = where > to start. Basically, I want to be able to display the contents of the > INI/config file in some kind of FORM or web page and then allow the = user > to be able to edit and save it at the same time. >=20 > Any advise on where to start will be very much appreciated. Am not = sure > if I should be using PHP instead of CGI-BIN but I thought the latter > would be simpler to do. >=20 > Being able to prompt for a username/password prior to editing the file > would be a plus ... :-) If I may start with the last question: user authorization is usually = easiest handled as part of the web server configuration. If you're using = Apache, look at the <Location> directive. Also, there's no programming language called CGI-BIN. CGI is a calling = convention that defines how the web server invokes external programs to = handle calls to certain URLs. Since CGI usually involves starting a new = process for the external program it's less effective for either Perl or = PHP than using a built-in interpreter in the web server. In PHP the = latter is often called using "SAPI" while Perl people talk about using = mod_perl. Solving your problem is possible in either language. Since this is a = Perl list, we'll stick to using Perl here, though. At this point you'll probably want to look at the CGI module for all of = your page rendering and argument parsing needs. Your code flow will likely look something like this: 1) Read config file into memory 2) Apply changes submitted by the user to the in-memory representation 3) Render the in-memory representation to a form where the user can edit = values 4) Write out the config file data if it was changed Things to keep in mind are - You might want to do implement some kind of locking to prevent two = people from editing your file ant once, since this may lead to "lost = updates" (where changes from one user overwrite the changes previously = submitted by another user) or worse (a trashed output file). - Pressing the "stop" button in the browser can cause your program to = abort in mid-execution. You'll want to make sure that this doesn't = happen while handling the update of the output file. HTH, Thomas