Ah, that does look a lot simpler. I'll try that out. I'll also add a test for a broken symlink.

That breaks a lot of tests…

I tried to use the filepath.EvalSymlinks API but that ends up breaking other tests. If the simplification is wanted, I think it needs a separate PR to also consider the behavior change(s) covered by other tests expecting specific errors.

I tried to use the filepath.EvalSymlinks API but that ends up breaking other tests. If the simplification is wanted, I think it needs a separate PR to also consider the behavior change(s) covered by other tests expecting specific errors.

I would prefer to use filepath.EvalSymlinks if possible as following symlinks properly is non trivial so I'd rather get the standard library to do it for us.

I think that loses error reporting fidelity as most of the configfile test failure modes start reporting different error codes. But if that is acceptable, I can push harder on that API call.

@mathstuf start pulling on that thread and see what unravels - we can review after.

I don't think it's going to work out. I believe the issue is that if the file doesn't exist, we get no information about any intermediate path resolution in the meantime. We would have to evalSymlinks on each path component until we get a non-no-exist error and then paste back the path components stripped on the way there to get the absolute path where the configuration file would exist if the intermediate directory components existed (as normal directories) and the file config file name (as a normal file). I don't think it would be any simpler than the existing logic and almost certainly more expensive (due to repeated EvalSymlinks calls each starting from scratch rather than chasing from what we know we have and stopping when things fall apart).