In Allegro Common Lisp and Lispworks,
(pathname-directory (parse-namestring "../"))
=> (:relative :back)
In CMUCL,
(pathname-directory (parse-namestring "../"))
=> (:relative :up)
According to the Hyperspec :up means "up the directory tree
semantically"; :back means "up syntactically." A further note says
``Syntactic'' means that the action of :back depends only on the
pathname and not on the contents of the file system.
``Semantic'' means that the action of :up depends on the contents of the
file system; to resolve a pathname containing :up to a pathname whose
directory component contains only :absolute and strings requires probing
the file system.
Although the issue is still pretty murky after reading this stuff, I
believe CMUCL's interpretation is more accurate. Because nothing occurs
before the ".." in "../", there is no pathname for the :back to work on.
So the semantic interpretation would seem to win by default.
Can anyone provide an argument in favor of Allegro and Lispworks's
interpretation? Or an argument why it doesn't matter?
-- Drew McDermott
Drew McDermott <··················@at.yale.dot.edu> writes:
> In Allegro Common Lisp and Lispworks,
>
> (pathname-directory (parse-namestring "../"))
> => (:relative :back)
>
> In CMUCL,
>
> (pathname-directory (parse-namestring "../"))
> => (:relative :up)
>
> According to the Hyperspec :up means "up the directory tree
> semantically"; :back means "up syntactically." A further note says
>
>
> ``Syntactic'' means that the action of :back depends only on the
> pathname and not on the contents of the file system.
>
>
> ``Semantic'' means that the action of :up depends on the contents of
> the file system; to resolve a pathname containing :up to a pathname
> whose directory component contains only :absolute and strings requires
> probing the file system.
>
>
> Although the issue is still pretty murky after reading this stuff, I
> believe CMUCL's interpretation is more accurate. Because nothing
> occurs before the ".." in "../", there is no pathname for the :back
> to work on. So the semantic interpretation would seem to win by
> default.
Hmmm. You lost me there. It seems to me that if there's nothing before
the ".." then this is a free floating name with no connection to the
actual filesystem.[1] In that case it seems that it would be
impossible to interpret the string semantically as that would require
probing the filesystem and there's no way to know where to probe.
Nothing left to do but treat the string syntactically.
-Peter
[1] Well, I guess PARSE-NAMESTRING could connect it to the actual
filesystem via the *default-pathname-defaults* but since all the
implementations are returning :relative directories nobody seems to
think that's a good idea.
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Drew McDermott <··················@at.yale.dot.edu> wrote:
> ``Syntactic'' means that the action of :back depends only on the
> pathname and not on the contents of the file system.
> ``Semantic'' means that the action of :up depends on the contents of the
> file system; to resolve a pathname containing :up to a pathname whose
> directory component contains only :absolute and strings requires probing
> the file system.
If /foo/bar is a symlink to /foobar, then:
* Back from /foo/bar/quux goes to /foo/bar
* Up from /foo/bar/quux goes to /foobar
Or am I totally of the track here? I fear I'm being blinded by
*nix-filesysten... so is the real issue about something else?
Cheers,
-- Nikodemus
* Nikodemus Siivola wrote:
> If /foo/bar is a symlink to /foobar, then:
> * Back from /foo/bar/quux goes to /foo/bar
> * Up from /foo/bar/quux goes to /foobar
> Or am I totally of the track here? I fear I'm being blinded by
> *nix-filesysten... so is the real issue about something else?
No, that is the real issue. And .. is ambiguous between these
interpretations
--tim
* Drew McDermott wrote:
> Can anyone provide an argument in favor of Allegro and Lispworks's
> interpretation? Or an argument why it doesn't matter?
It does matter, and the answer is that different Unix programs
interpret this different ways: Unix filesystem semantics are (at least
empirically) ambiguous here.
(You can see this: try
mkdir -p /tmp/foo/bar
ln -s /tmp/foo/bar /tmp/bar
now in bash:
cd /tmp/bar
cd ..
pwd
Result should be /tmp.
the same in sh (assuming you have a real Bourne shell, not bash in
disguise like some systems do) will result in /tmp/foo. So bash is
taking the :BACK interpretation, while sh is taking the :UP
interpretation. There is equivalent variation elsewhere.)
I don't think your argument for taking :UP rather than :BACK is good.
For instance one thing you might want to do is:
(merge-pathnames path (pathname "../foo/"))
So if PATH, as a Unix namestring (and assuming the `trailing slash
means directory convention'), was "/tmp/bar/zug", this is surely
equivalent to "/tmp/bar/../zug", and should this be :BACK or :UP? Who
knows?
This is why a structured representation of pathnames is some use, of
course: you get to distinguish between things that are ambiguous as
strings.
--tim
Drew McDermott <··················@at.yale.dot.edu> writes:
> In Allegro Common Lisp and Lispworks,
>
> (pathname-directory (parse-namestring "../"))
> => (:relative :back)
>
> In CMUCL,
>
> (pathname-directory (parse-namestring "../"))
> => (:relative :up)
>
In Lispworks for Linux I get:
CL-USER 2 > (pathname-directory (parse-namestring "../"))
(:RELATIVE :UP)
I assume you used Lispworks for Windows?
-Robert
--
Robert Folland
······@folland.org