CL distinguishes :up and :back in directory components of pathnames. How ".." is parsed by uiop:parse-native-namestring is implementation-dependent, relying on the implementation's underlying native-namestring support (if any, falling back to cl:parse-namestring).
If you insist on reading it as :up, you could use (uiop:parse-unix-namestring string :dot-dot :up)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Microphones, liberating singers from having to be loud to be heard, gave back to each language a music that matches its own prosody.
On Thu, Sep 8, 2016 at 7:07 AM, Jared C. Davis jared.c.davis@gmail.com wrote:
Hi,
I have set up the following directory hierarchy:
lstest-dir | +---+------------------+ | | subdir1 subdir3 ---symlink---+ | | +-+---------+ | | | | xxxdir subdir2 <----------------------+ | | xxx.txt yyydir | yyy.txt
On my linux system, shell commands like "ls" seem to resolve paths such as "lstest-dir/subdir3/.." to "lstest-dir/subdir1". For instance:
$ ls lstest-dir/subdir3/../xxxdir xxx.txt
In other words, when a path goes through "<symlink>/..", it seems to be resolved by first following the symlink, then finding the parent directory of the symlink's target.
However, it appears that uiop:ensure-directory-pathname resolves ".." in a different way. For instance, on CCL on Linux, when I run:
(uiop:ensure-directory-pathname (uiop:parse-native-namestring "lstest-dir/subdir3/.."))
I get #P"lstest-dir/" instead of #P"lstest-dir/subdir1".
Is there a way to configure ensure-directory-pathname to use a more shell-like behavior, or some other alternative that I might run to preprocess the path to resolve these obscure cases like the shell does?
Thanks, Jared
-- Jared C. Davis jared.c.davis@gmail.com 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/