Option to print absolute filesystem paths (as in realpath(3)) with "files" command

[mk-fg]

After absolute -> relative path changes, output of "files", even with -0, cannot be relied upon to produce actual working paths.

Example:

% cd
% mkdir -p dir1/dir2
% touch dir1/dir2/myfile
% tmsu tag dir1/dir2/myfile

Problem 1 - symlinks:

% tmsu files -f -0 mytag | xargs -0 ls -d
./dir1/dir2/myfile

% ln -s dir1/dir2 mydir
% cd mydir
% tmsu files -0 mytag | xargs -0 ls -d
ls: cannot access '../dir1/dir2/myfile': No such file or directory

Problem 2 - file lists:

% tmsu files -f -0 mytag > ~/myfiles.list
% cd /
% xargs -0 ls -d < ~/myfiles.list
ls: cannot access './dir1/dir2/myfile': No such file or directory

Would be nice if output was immediately usable without any extra processing in both cases.

Workaround can be to run cd /; tmsu -D "$HOME"/.tmsu/db files -0 ... | sed -z 's:^\.::', but that seem a bit too involved for such a simple operation - why not allow to print reliably-usable paths (as they are now) from tmsu itself instead?

Proposed solution:

Add -r --realpath option to print existing absolute unambiguous non-broken paths. I.e. resolve each path relative to ~/.tmsu/db where they're stored, run realpath() on it (Go should have a wrapper), and return the result, if any. That way, it should be guaranteed to work when piped into e.g. grep, used as playlist, etc, unlike current output.

Note the fact that it'd only output existing paths, as pretty sure there's no reliable path version for non-existing ones anyway (it's just a random string after all).

Thanks!

[oniony]

Weird, I thought it already did this if it was piped, but apparently not. It's a reasonable request.

It would be interesting to see how other tools handle this situation. find, for example, will output absolute paths if passed an absolute path, but that's obviously not going to work here.

[mk-fg]

Oh, right, thinking of how find navigates things made me realize that there'll be another side-effect that I didn't consider - realpath() will resolve all symlinks for output paths, which can be weird, as guess these might look different from originally-tagged ones.

IMO a good effect still, as there's no way to force existing and non-nonsensical paths otherwise, and that's what "realpath" implies with tool or call anyway. Should probably be emphasized in the docs though that it's only exising paths with everything in them resolved to canonical form.