I’ve seen a couple of things on why using std.fs.realpath is generally bad if you want things to be robust and portable. However, I have a use case that I don’t know how to approach without using realpath.
I’d like to be able to take a relative file path and step through it’s parent, grandparent, etc. directories looking for a config file. For example, assume the config file is at /home/user/project/configfile, the current working directory is at /home/user/project/subfolder/, and the user supplies the relative path src/example.zig. I want to first check /home/user/project/subfolder/src/, then /home/user/project/subfolder/, then find the config file in /home/user/project/.
The only way I can think to do this is by stripping away directories from an absolute path, which requires calling realpath on either the user-provided relative path, or . to get the cwd’s absolute path (which I could use to resolve the relative paths myself).
I do see Andrew Kelly mention that the compiler calls realpath in one place, which looks similar to what I’m trying to do here.
I also assume that hardlinks and symlinks are going to complicate this no matter what, but I don’t know by how much.
- Am I overthinking this?
- Do the portability and robustness concerns still apply if I only call realpath once to get the cwd’s absolute path?
- If the concerns do still apply, is there a less problematic alternative?
