[ My apologies for not replying directly to Nikodemus and Kevin directly
in the relevant threads, but my regular mailhost is down, and I couldn't
reply to both of them anyway. ]
Attached is my version of their respective changes, complete except for
moving the new interface from SB!INT into SB!EXT.
* define pathname host-specific PARSE-NATIVE and UNPARSE-NATIVE methods.
* define NATIVE-PATHNAME, NATIVE-NAMESTRING and PARSE-NATIVE-NAMESTRING in
a direct analogy with PATHNAME, NAMESTRING and PARSE-NAMESTRING. (NB: no
extra keyword argument here for parsing as a directory).
* use NATIVE-PATHNAME both on what POSIX-GETCWD/ returns and on files the
user has asked us to load at the command line. (Fixes bug #296 and
*DEFAULT-PATHNAME-DEFAULTS* being wrong when a component of the current
directory contains a pathname metacharacter in "[*?\\").
* don't create a string from --load (and --disable-debugger) that just gets
read again; instead allow process-eval-options to deal with non-strings
* tease *physical-host* (the default physical host on the platform) and
*unix-host* apart ever so slightly, with obvious knock-on benefits for
ports to non-Unixoid platforms.
* sb-posix no longer needs its own implementation of NATIVE-FILENAME.
* delete unused UNIX-MAYBE-PREPEND-DIRECTORY.
I'd like this version, but I'm willing to listen to howls of outrage
Christophe Rhodes <mas01cr@...> writes:
> I'd like this version, but I'm willing to listen to howls of outrage
> from people.
I'm still willing to listen to howls of outrage, but in the meantime I
merged what I had (which advanced ever so slightly from the patch in
yesterday's mail) so that we could fix #296 and expose the patch to a
little more testing.
In particular, there were some little howlettes about the treatment of
"." and ".." without postpended slashes. It's possible that there is
a better parse (in both PATHNAME and NATIVE-PATHNAME) for these cases;
this is largely orthogonal to the issues that I was trying to solve
with this patch. (I note also that there is a current bug in this
department, in that a pathname with ".." (rather than :up) in its
directory component will be incorrectly printed; again, I leave this
for future work.