Am 17.10.2005 um 03:54 schrieb Stephen Deasey:
Are you sure Ns_NormalizePath() is broken? I haven't examined it, but
it's worth pointing out that it's most important use is normalizing
the *URL path*, called early at the start of conn processing in
request.c.
The comment for Ns_NormalizePath() says "Assumes an absolute path",
which seems reasonable when thinking about just URL paths.
We need to figure out whether Ns_NormalizePath() really is broken and
fix it, or otherwise resolve the confusion.
Also, will [file normalize $path] do the right thing to a URL when
used on Windows?
The main point is:
ns_normalizepath
is used to normalize *what* paths?
The filesystem paths or URL paths?
If former, than it is broken since normalizing
a/b
should not yield /a/b.
If latter, than it is merely a point of definition as in URL-space
there is nothing like the "current directory" concept.
The fact that ns_noramlizepath lived in tclfile.c leads me to conclude
that it is ment to be used on filesystem paths. What you're saying is
that it is primarily used to normalize URL paths. Well, we both may be
right or wrong, but this is a very good example of a poorly defined API.
Now, I would not like to leave "ns_normalizepath" as-is. It can very
easily
make people think it can be used for filesystem paths (which it can't).
OTOH, replacing it with [file normalize] would hit anybody doing URL
path
operations (I did't think of that possibility, unfortunately).
So what are our options?
Add ns_normalizeurlpath and declare ns_normalizepath obsolete?
Add -file | -url options to ns_normalizepath?
Cheers
Zoran
