Question about resolving "symlink/.."

[Faré]

On Thu, Dec 29, 2016 at 5:21 PM, Jason Miller <jason at milr.com> wrote:
> Quoting Faré (2016-09-08 05:25:36)
>> 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)
>
> Out of curiousity, why isn't this the default behavior of
> parse-unix-namestring?  It seems to me that the :up is semantically the
> correct mapping for ".." on unix.
>
Because parse-unix-namestring was born out of the needs of ASDF, and
those needs were better met by :back than :up. Also, for security
reasons, :back is usually better behaved than :up. :up is a gross hack
that will get you p0wned.

> Also note that for  #+(and (or unix cygwin) (not (or clozure cmucl sbcl
> scl))) uiop appears to use parse-unix-namestring rather than
> cl:parse-namestring, so e.g. ecl on linux uiop will parse ".." as :back
> rather than :up
>
Yeah well. If you *really* want well-defined portable semantics for
parsing pathnames, you'll have to use iolib. I think of UIOP more as a
jumpstart than as a 100% solution. It's there to get ASDF going and
serve your easy scripting needs until you really need reliability at
which point it helped you load IOLIB.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Reasons for existence are usually provided for things that don't exist;
they would be wasted on things which do. — Saul Gorn