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.da...@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.da...@gmail.com> > 11410 Windermere Meadows > Austin, TX 78759 > http://www.cs.utexas.edu/users/jared/ >
