On Thu, Dec 29, 2016 at 5:21 PM, Jason Miller <ja...@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