Is fd -l safe to parse?

[csswright]

If ls is not safe to parse, is fd -l safe to parse? I'm looking for a performant way to display both filename and their modification time. I found stat with globbing on 20k files to be significantly slower than with ls -lt and fd ls -X ls -lt.

[tavianator]

fd -l just spawns ls so it has the same caveats. Maybe you could do fd -X stat ...?

[tmccombs]

You may be interested in #1866

[BLCCoreStudio]

No, I would not treat fd -l as a machine-readable interface. Since it delegates to ls, the usual filename quoting and embedded-newline caveats still apply.

On GNU/Linux, if the goal is filename + modification time today, a safer option is something like:

fd -X stat --printf='%n\0%Y\0'

and then parse the output as NUL-delimited (filename, mtime) pairs. fd -X passes the matches as command arguments instead of turning filenames into shell text, and NUL is a safe delimiter for Unix pathnames because a filename cannot contain a NUL byte. %Y gives the modification time as seconds since the epoch.

That particular stat format is GNU-specific, so I would not use it unchanged for a portable macOS/BSD script.

PR #1866 also looks like the cleaner long-term fd-native solution: --json would provide structured JSONL output including path and modification metadata. Since that PR is still open, though, I would not make a production script depend on it yet.