Question about resolving "symlink/.."

[Faré]

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