> I like the idea of a data root directory environment variable. At
> user request I have already implemented this as a non-standard feature
> in GN.
Then what would I do? cern_httpd doesn't have a single document
root, and there is no reason why it should. I would like to see
DOCUMENT_ROOT as a server-specific feature rather than dictated
by the spec.
-- Cheers, Ari --
Hmmm... most of my scripts which manipulate external files store those
files in some known location relative to the script itself (e.g., the
seminar-schedule printer used by several links from
http://www.ai.mit.edu/events/events-list.html
which works off email archives which are stored in the same directory as
the script). These scripts would be perfectly happy with a variable which
contained their own (translated) pathname; they could then find the files
they needed relative to that.
In fact, that script presently begins with the lines...
#! /usr/local/bin/perl
do '/com/doc/web-support/cgi-hacks.pl'; # Perl CGI assist routines...
chdir '/com/doc/web/events/seminars'; # Directory containing this script...
...
(my DOCUMENT_ROOT being /com/doc/web), which is awkward because I'd have to
change this line if I ever wanted to install the script and its support
files as a package somewhere else. If a TRANSLATED_SCRIPT_NAME variable
were available, I could do this instead:
#! /usr/local/bin/perl
do '/com/doc/web-support/cgi-hacks.pl';
($script_dir = $ENV{'TRANSLATED_SCRIPT_NAME'}) =~ s+/[^/]*$++;
chdir $script_dir;
...
(where the gubbish on the second line strips the last path component off of
the TRANSLATED_SCRIPT_NAME to get the enclosing directory); this would work
no matter where the package lived.
This variable would at least have a sensible definition no matter how the
server actually does translations (in particular, whether the notion of a
single DOCUMENT_ROOT makes sense or not). However, some scripts may need
something more flexible. Comments?
rst