Should(/can?) resholve do anything about paths in `test`/`[ ]` ?

[abathur]

This section in mons is giving resholve a little trouble:

lib='%LIBDIR%/liblist.sh'
[ ! -r "$lib" ] && { "$lib: library not found."; exit 1; }
. "$lib"

The ~intended approach for cases like this is to use a fix directive to replace $lib with the $out-relative path (lib/libshlist/liblist.sh) and then let resholve handle resolving them to absolute paths whenever it makes sense to do so--but in this case the result is roughly:

lib='/nix/store/arzpg3i5zh14yj1s7d20086a9rjmlfvx-mons-20200320/lib/libshlist/liblist.sh'
[ ! -r "lib/libshlist/liblist.sh" ] && { echo "lib/libshlist/liblist.sh: library not found."; exit 1; }
. "/nix/store/4pby883d4wypprmvkzz92c0c62iz4cxs-resholved-mons-20200320/lib/libshlist/liblist.sh"

Then the check fails at runtime.

I'm not certain, but I imagine it's common enough to be worth handling if we can. That said, we definitely can't resolve every test -f or test -r etc., so the question is more about how we'd narrow the scope to ensure we're only resolving them when it makes sense.

I guess the two main candidate approaches would be:

• Treat test with file/dir flags as its own thing that resholve cares about (i.e., require every one of them to either resolve to a known file at resolve-time, or require a directive exempting the path).
• Automatically resolve paths matching some heuristics (like actually resolved during this invocation, present in inputs/scripts, present in $out?) and ignore the rest

Maybe it's worth plumbing andy's real-world shell collection to see what all cases of the various test file/dir flags you can find and how these approaches stack up against them.

[abathur]

The effort to resholve airgeddon hinges on this as well. https://github.com/v1s1t0r1sh3r3/airgeddon/blob/c58bb8f086ab47cf918399f019bd502dbd430b76/airgeddon.sh#L383 for example will fail into trying to download the strings.