Re: Wrapped application directory oddity

At Sat, 30 Jun 2007 01:46:55 GMT "Jeff Godfrey" <jeff_godfrey@xxxxxxxxx> wrote:



"Robert Heller" <heller@xxxxxxxxxxxx> wrote in message
news:2e114$4685afda$404a99a1$18636@xxxxxxxxxxxxxxxxxxxxxxxx
At Fri, 29 Jun 2007 21:48:19 GMT "Jeff Godfrey"
<jeff_godfrey@xxxxxxxxx> wrote:

Perhaps I should be filing a bug report?

Doesn't the CGI standard define environment variables for this?

Robert,

Good point. Looking at the reference I have, I don't see a
"DOCUMENT_ROOT" listed as a common CGI variable. That said, I *do*
see a PATH_TRANSLATED variable listed that it supposed to contain the
absolute pathname to the location of the CGI program on server's file
system. That's exactly what I need. I'll see if that's availabe to
me.

Actually, I've already written code to correct the malformed paths
(just a few calls to [string map]), so I'm really beyond the problem
anyway, but I could maybe remove that kludge with the above.. ;^)

I guess I'm more concerned with the odd return results in this case.
It seems to indicate some possible Tcl problem at level lower than my
script. In reality, I get 3 different results...

[info nameofexecutable] returns "//?/D:/WebHostings/...", which is
correct except for the leading 4 chars
[info script] returns "//?/D:WebHosting/...", which has the same
leading 4 chars *and* a missing slash after the drive name.
[pwd] returns "D:/WebHosting/..., which is just right...

I just find that odd, and wonder if its not a bug?

I'm thinking not *a Tcl* bug. I don't notice any sort of weirdness
under Linux. Some thoughts:

[pwd] almost certainly directly calls a system service call that returns
whatever the system believes the current working directly is, however
that was set (i.e. most recent use of 'cd' or something). This is
(obviously) working just fine.

[info nameofexecutable] is most likely returning what ever was passed as
argv[0] from the 'shell' (or whatever). There is not any reason to
believe there is any relation to reality here, just the *presumption*
that argv[0] contains the proper pathname of the executable. It really
can contain any random nonsense, although well behaved UNIX shells (and
other programs/functions that call fork()+exec<mumble>()) will pass the
path of the program as argv[0]. Oh, there is no certainty that the path
will be a fully qualified absolute path.

[info script] is just returning whatever was passed to the current
Tcl_EvalFile() call, if any.

It *appears* (to me) that whatever process is starting up your script
(IIS? Apache under MS-Windows?) is putting something odd in argv[0] --
I.e. it is calling exec<mumble>() (or whatever passes for
exec<mumble>() under MS-Windows) with a screwy value for argv[0]. The
StarPack code is just prepending the directory spec from argv[0] onto
its virtual file system -- that is it is doing a UNIX-style mount of the
virtual file system onto the executable path. Then it is sourcing
(Tcl_EvalFile()) the Tcl StarPack startup code.


Thanks,

Jeff




--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
heller@xxxxxxxxxxxx -- Contract Programming: C/C++, Tcl/Tk

.

Relevant Pages

  • Re: CGI bug
    ... There is a beginners-cgi list that deals with Perl and CGI issues: ... And if you are reporting a bug in CGI: ... Address bug reports and comments to: ...
    (perl.beginners)
  • Re: apache 1.3.28-4 on unstable
    ... Index pages, whether html, shtml, or cgi are no longer ... > installation of nagios-mysql. ... Well, it is a known bug in the apache package, you should have checked. ...
    (Debian-User)
  • Re: apache 1.3.28-4 on unstable
    ... Index pages, whether html, shtml, or cgi are no longer ... >Well, it is a known bug in the apache package, you should have checked. ... Luckily, the fix was easy. ...
    (Debian-User)
  • Re: apache 1.3.28-4 on unstable
    ... Index pages, whether html, shtml, or cgi are no longer ... >Well, it is a known bug in the apache package, you should have checked. ...
    (Debian-User)