$ ls -l /usr/bin/{bash,python}
lr----x--t 0 root 1 Jan 1970 /usr/bin/bash -> /nix/store/j37555sj2w3xsql3f8qrwbaim7pv67hg-bash-interactive-4.4-p23/bin/bash
lr----x--t 0 root 1 Jan 1970 /usr/bin/python -> /home/joerg/.nix-profile/bin/python
now results in:
ls: cannot access '/usr/bin/bash': No such file or directory
ls: cannot access '/usr/bin/python': No such file or directory
because envfs only responds lookups from execve syscalls.
On a related note - what is the reason to only respond to execve lookups? I guess it's to minimize the filesystem polution. I now work with a project that not only has shebangs pointing to /usr/bin, but also checks for interpreter presence in /usr/bin before running the scripts. Having envfs responding to all lookups as before would help me a lot in this case. What about responding all lookups if some variable (e.g. ENVFS_LOOKUP_ALL) is set in the requesting process environment? I may try to send a PR if you're not against.
This command from the README:
now results in:
because envfs only responds lookups from execve syscalls.
On a related note - what is the reason to only respond to execve lookups? I guess it's to minimize the filesystem polution. I now work with a project that not only has shebangs pointing to
/usr/bin
, but also checks for interpreter presence in/usr/bin
before running the scripts. Having envfs responding to all lookups as before would help me a lot in this case. What about responding all lookups if some variable (e.g.ENVFS_LOOKUP_ALL
) is set in the requesting process environment? I may try to send a PR if you're not against.