yes, my change made things fail more aggressively on MacOS. I still
think it's the right change, because it makes the test less dependent on
the environment. I also think that we need to add even more similar
tests, which would currently fail reliably on both Linux and MacOS.
After more testing:
Quoting Far? (fahree@...):
> Your "fix" might work on Linux, but it breaks on MacOS X, because
> realpath is broken on said platform. :-/
realpath does not work on Linux either -- not in the way SBCL needs it
to work, at least -- and not if we want to support use of files in /dev.
Conceptually, realpath does the right thing: Among other things, it
resolves symlinks. In reality, that is not the right thing to do,
because there are symlinks in /dev which the kernel can open even though
their target is not a file name.
On the SBCL side, the big issue is that OPEN does not call open(2).
Instead it non-atomically probes around in the file system. Let's for
the moment assume that the CL spec requires such scary behaviour...
Among other things, it uses PROBE-FILE, which tries to return a
truename. PROBE-FILE calls realpath and fails with NIL, even though
open(2) would have succeeded. Consequently, OPEN errors out -- rather
pointlessly, since it had already used stat() to confirm that the file
: david@...:~; cp /etc/hostname /dev/stdout | tee /dev/null
: david@...:~; realpath /dev/stdout | tee /dev/null
/dev/stdout: No such file or directory
: david@...:~; ls -l /dev/stdout | tee /dev/null
lrwxrwxrwx 1 root root 15 Aug 29 17:19 /dev/stdout -> /proc/self/fd/1
: david@...:~; ls -l /proc/self/fd/1 | tee /dev/null
l-wx------ 1 david david 64 Sep 3 12:29 /proc/self/fd/1 -> pipe:
> What about we disable the test on MacOS X or mark it as expected to fail?
I will do that before the next release if I haven't pushed a real fix
> What's the right way to do that?
Nothing in the area of PROBE-FILE or OPEN seems even remotely like the
right thing to do :-).
I think it is worth supporting files in /dev even if kernels implement
them in a weird way. Clearly, PROBE-FILE needs to return true for those
file names. But it might not be essential for the returned value to be
I'll work on a patch to combine results from readpath(3) and stat(2).
If the former fails, but the latter succeeds, we would simply return the