Re: Wrapped application directory oddity
- From: Melissa Schrumpf <m_schrumpf_at_yahoo_com_NOT@xxxxxxxxxxxxx>
- Date: Thu, 28 Jun 2007 20:01:37 -0400
Jeff Godfrey wrote:
I have a TclApp wrapped application running on a remote web server.
I'm trying to programmatically determine the absolute path of the
executable, but the usual suspects are returning odd results in this
case.
Specifically, the real path begins with: D:/WebHosting/...
....
[info nameofexecutable] and "$starkit::topdir" both return
"//?/D:WebHosting/..." The rest of the path is correct, but what's
with the odd leading chars and the missing slash after the drive
letter?
....
Running the same wrapped application on my local server (via command
line or cgi) returns valid results. I only see the strange results on
the remote system, so it seems to be related to the configuration of
that server.
What platforms are the two machines?
"//?/D:WebHosting/..."
To me, that looks like a mix of filesystem conventions, perhaps not
traversing properly between UN*X and Windows.
\\MachineName\resource
Is a standard Windows convention for referring to remote shares,
and is present, though hidden, in many of the ways to which the local
machine may be referred:
\\localhost\resource
\\.\resource
\resource
See the COM port section of [open] for more details. IIRC, you can open
COM1 and COM2, but for, say, COM10, you have to specify \\.\COM10.
Named pipes (yes, WIndows has them, sorta) much in the same way.
"//?/" looks to me like a bad conversion of "\\.\"
As for the missing "/" after D:, that could be a similar poor
translation of filesystem syntax. Keep in mind, for example, that:
\\remotehost\C$
is a standard way to refer to the entire C drive share. Or, perhaps the
"/" just got lost in some bad assumption that there is always a leading
"/" in a filesystem path, so some routine somewhere has the first
instance replaced with "" when concatenating to form the complete path.
Pure conjecture, though.
--
MKS
.
- Follow-Ups:
- Re: Wrapped application directory oddity
- From: Jeff Godfrey
- Re: Wrapped application directory oddity
- References:
- Wrapped application directory oddity
- From: Jeff Godfrey
- Wrapped application directory oddity
- Prev by Date: Re: Expect _AND_ Tcl intro/tutorial needed
- Next by Date: Re: How Tcl speaks for itself and how Tcl is not spoken for...
- Previous by thread: Wrapped application directory oddity
- Next by thread: Re: Wrapped application directory oddity
- Index(es):
Relevant Pages
|
