fp fpweb and environment vars
Fairlight
fairlite at fairlite.com
Sat Nov 4 20:24:22 PST 2006
On Sat, Nov 04, 2006 at 05:44:26PM -0800, Scott Nelson may or may not have
proven themselves an utter git by pronouncing:
> It appears that when using fp5 on windows with apache and fpweb (cgi),
> the system variables can not be read from within a fp process, such as
> with getenv("username"). Anyone know of a work around for this?
Have perl on that box, by chance? Try this [modifying the first line to
point to your perl]:
#!//opal/F/Perl/bin/perl.exe
print("Content-type: text/plain\n\n");
foreach $one (keys(%ENV)) {
print("${one}: ${ENV{${one}}}\n");
}
exit;
#####
When I start up the apache service (I don't keep it running, as it's out
of date and I only use it for testing CGI programs under 'doze when I'm
actively developing) and run this on my other machine, I get the following:
SCRIPT_NAME: /cgi-bin/showenv.pl
SERVER_NAME: opal
SERVER_ADMIN: fairlite at fairlite.com
HTTP_ACCEPT_ENCODING: gzip,deflate
HTTP_CONNECTION: keep-alive
REQUEST_METHOD: GET
SYSTEMROOT: C:\WINNT
HTTP_ACCEPT:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
SCRIPT_FILENAME: c:/program files/apache group/apache/cgi-bin/showenv.pl
COMSPEC: C:\WINNT\system32\cmd.exe
SERVER_SOFTWARE: Apache/1.3.34 (Win32)
HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7
WINDIR: C:\WINNT
QUERY_STRING:
REMOTE_PORT: 1623
HTTP_USER_AGENT: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
SERVER_SIGNATURE: <ADDRESS>Apache/1.3.34 Server at opal Port 80</ADDRESS>
SERVER_PORT: 80
HTTP_CACHE_CONTROL: max-age=0
HTTP_ACCEPT_LANGUAGE: en-us,en;q=0.5
REMOTE_ADDR: 192.168.1.10
HTTP_KEEP_ALIVE: 300
SERVER_PROTOCOL: HTTP/1.1
PATH:
F:\Perl\bin\;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program
Files\ATI Technologies\ATI Control Panel;C:\Program Files\PuTTY;C:\Program
Files\ATI Technologies\ATI.ACE\
REQUEST_URI: /cgi-bin/showenv.pl
GATEWAY_INTERFACE: CGI/1.1
SERVER_ADDR: 192.168.1.40
DOCUMENT_ROOT: c:/program files/apache group/apache/htdocs
HTTP_HOST: 192.168.1.40
Note the distinct lack of USERNAME. Why would there be one in the first
place? It runs as a service, even if nobody's logged in. It makes little
sense for anything to conjure one in that context.
Now, there's a way to force apache to have a variable for it if you need
one. Add the following line to the main config or to the appropriate
<virtualhost> block before restarting the Apache service:
SetEnv USERNAME apache
When I do that, USERNAME shows up right after HTTP_ACCEPT_LANGUAGE in the
above list when I hit refresh.
Tested on Win2000 Professional SP4 with Apache 1.3.34 (obviously).
Of course, if you can alter the server config to hardwire one, why not just
alter the filePro processing to use a hardwired value?
At any rate, while USERNAME is portable across every *nix I can think of
and on which I've ever tested, and apache runs as a specific user in *nix,
it doesn't appear to do so when run as a service in Windows. Programs that
expect this variable likely shouldn't run as expected against an "out of
the box" stock Windows+Apache config.
mark->
More information about the Filepro-list
mailing list