Nikodemus Siivola writes:
> I'm silly in the way I'd _still_ like to use PATHNAME and NAMESTRING to
> deal with unix pathnames. The news is that I think I know how to do one
> more part of this.
I've been running against this a lot recently. I've hacked local SBCL
source trees to support a couple of approaches, and the one I like the
best is to have two hosts: a unix-shell host, and a unix host. The
unix-shell host does (at least) the amount of magical DWIM that SBCL
currently does (eg, special handling of *), in the way that a user
expects in a Unix shell-ish context. The unix host supports posix
namestrings. So, the only non-literal is /, and that character cannot
occur in any pathname component.
I haven't read the appropriate parts of the spec that handle printing
pathname and reading the #p reader macro. I don't know what the
implications are for NAMESTRING. Certainly, it allows for nice use of
PARSE-NAMESTRING, which can default to the unix-shell host, but given
a unix host and a string like "/tmp/foo*" will do the right thing and
produce a pathname object with a name of "foo*". It would be nice if
(namestring (parse-namestring "/tmp/foo*" :unix)) would give you
"/tmp/foo*". A second-place would be to have NAMESTRING and
PARSE-NAMESTRING do the right thing for one host, and have a second
set of functions to do the right thing with the other.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |