CGI/1.1 draft (Robert S. Thau)
Date: Tue, 1 Mar 1994 22:43:57 --100
Message-id: <9403012141.AA09475@volterra>
Precedence: bulk
From: (Robert S. Thau)
To: Multiple recipients of list <>
Subject: CGI/1.1 draft
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2110
   Date: Tue, 1 Mar 1994 21:55:42 --100
   From: (Ari Luotonen)

   > 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

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/'; # 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/';
  ($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?