On Mac, lib.std.Dir.realpath resolves firmlinks but /bin/realpath does not

[hippietrail]

Zig Version

0.14.0-dev.15+d4bc64038

Steps to Reproduce and Observed Behavior

const std = @import("std");

pub fn main() !void {
    const p: []const u8 = std.mem.span(std.os.argv[1]);
    std.debug.print("< '{s}'\n", .{p});

    var buf: [std.posix.PATH_MAX]u8 = undefined;

    std.debug.print("> '{s}'\n", .{try std.fs.cwd().realpath(p, &buf)});
}

% sudo zig build run -- /System/Volumes/Data/Library
< '/System/Volumes/Data/Library'
> '/Library'
% realpath /System/Volumes/Data/Library             
/System/Volumes/Data/Library

Now firmlinks are already considered a real problem, but not matching default OS behaviour may or may not also be considered a problem.

Back when I reported that issue I also reported the issue on Rust. The Rust maintainer of the dir walking APIs roundly rejected considering it a bug, which indicates there may be various opinions so we should at least make an official decision.

All mac unix commandline tools I have tried (such as find) don't take firmlinks into account. But code written in Swift does.

lib.std.Dir.realpath on Mac is implemented using posix.system.fcntl with posix.F.GETPATH and does not call a realpath API, in fact I don't think macOS provides one?

We could:

1. include an option that defaults to treating firmlinks like symlinks
2. include an option that defaults to treating firmlinks like the standard Mac commandline tools do
3. keep it as it is and always treat firmlinks like symlinks but now make it an officially considered decision

Note that the std.fs.IterableDir.Walker issue is not solved yet so it does not match the behaviour of lib.std.Dir.realpath, which could cause confusion.

Expected Behavior

% sudo zig build run -- /System/Volumes/Data/Library
< '/System/Volumes/Data/Library'
> '/System/Volumes/Data/Library'
% realpath /System/Volumes/Data/Library             
/System/Volumes/Data/Library

[alexrp]

(I don't work on any of this code, so take my opinion with a bucket of salt.)

At first glance, it seems like if Rust and Swift both follow firmlinks, the least surprising behavior would be for Zig to do the same. Swift is particularly noteworthy, what with it being an Apple language. I don't know that the behavior of command-line tools should necessarily have any bearing on this.

[hippietrail]

(I don't work on any of this code, so take my opinion with a bucket of salt.)

At first glance, it seems like if Rust and Swift both follow firmlinks, the least surprising behavior would be for Zig to do the same. Swift is particularly noteworthy, what with it being an Apple language. I don't know that the behavior of command-line tools should necessarily have any bearing on this.

No sorry I may have been unclear. Swift skips firmlinks. Rust follows firmlinks.
(I haven't tried objective C to find out whether this is something new in the Swift runtime since firmlinks are themselves new.)

[alexrp]

Ah, ok. In that case, I would personally consider Swift's behavior to have more 'weight' than Rust's.

[hippietrail]

Ah, ok. In that case, I would personally consider Swift's behavior to have more 'weight' than Rust's.

I just linked to my Rust bug report in case you want to read all the thoughts in that thread. It seems in the rust case that it's not part of the standard library but in a separate crate, which may also be a relevant difference?