Possible Future Work?

[grahamc]

There are some things I would like for it to do:

1. better support for bash alias definitions, where currently it
does not handle them at all. Finished in #5
2. better support for programs which call other programs, like
xargs «cmd». This one is not a principled solution, but I think
an investment in to handling common "higher order" programs like
this would pay off well. See #6
3. development of a "strict mode" where the PATH is unset, to improve
the guarantee See #9
4. have a "traced execution" model where executing specially
instrumented "resholved" scripts record any programs executed which
are not in their Nix closure. This indicates a scope leak and
resolution failure. See #9
5. a buildInputs setup hook, which automatically resholves all of the outputs of a Nix build. See #8

what do you think about these things?

[abathur]

1. I'm working on this; shouldn't be too much longer. (Testing pointed out a gap in how resholved implemented the resolution order, which is entailing a rework.)
2. I'm on board with the general point of making a new affordance for "add extra handling for this arbitrary command". I don't know how well/quickly robust handling for xargs can follow from that...
   • The bare minimum xargs <command> wouldn't be too bad as I already have separate handling for builtins that do similar.
   • I'm less sure how tractable it will be to handle the variable syntax and flags that commonly accompany it (i.e., building in enough knowledge of real xargs syntax or at least common call patterns to get very good at identifying which word is the real command).
   • If it's not trivial to get very good at that, I can imagine cheating it by giving resholved a new parameter that tells it to try and resolve a given identifier regardless of where it falls within an xargs command.
3. I'm on board with the concept and I hope a naive version is simple enough. I'll need to play with injecting a leading statement to set PATH="" (it looks like unsetting it entirely causes which to exit 1) at runtime to confirm there's a straightforward way to put it in the right place. There are probably quite a few edge cases where this will break down if scripts set/modify path or do certain kinds of environment sanity-checking...
   • Here's a real-world example. Here's what it does, roughly, with an empty path:

     readonly PATH=""
     function fixpath(){
       local default_path=$(command -p getconf PATH 2>/dev/null)
       [[ $default_path ]] || return 1
     
       local original_path=$PATH
       export PATH=${default_path}${PATH:+:}${PATH}
       [[ :$PATH: == *:/bin:* ]] || PATH=/bin${PATH:+:}$PATH
       [[ :$PATH: == *:/usr/bin:* ]] || PATH=/usr/bin${PATH:+:}$PATH
       if ! type "${_ble_init_posix_command_list[@]}"; then
         PATH=$original_path
       fi
     }
     fixpath
     echo path=$PATH # prints path=/usr/bin:/bin:/usr/sbin:/sbin
     

   • If you think the point of doing this the "strict way" is to shake stuff like this out of the tree and patch it, I guess it could use readonly PATH="". It wouldn't cause hard failures by itself, but it would ensure every attempt to fiddle with PATH is at least exposed.
4. Interested in the general principle but I'm having trouble imagining how this might work. Can you elaborate on how you see this working?
5. If I'm interpreting you correctly, I think it'll be a simple way to use resholved from Nix, and I did dither early on about whether it should be a builder or a hook, but both are probably useful. A few thoughts:
   • It's a natural progression at some point and it'll also be a good stress test of sorts. I'm not terribly confident about tackling it yet and have a few other projects clamoring for sunlight, so I'm inclined to see this as a back-burner thing wrt to my own effort. But, this may be something that is trivial for someone with more perspective to implement.
   • I wonder about how to avoid eagerly resolving things (wrappers, nix-shell scripts, shebangless scripts with a .sh extension? multiple scripts that all symlink to a single file and use $0 to execute differently) that probably shouldn't be resolved or that could waste time without benefit. I guess an alternative is "move fast and break things" but provide a way to explicitly exclude some.
   • Curious what you think about the config API and how automatic vs. explicit you imagine it being for the hook. I know less about what's possible, here. If it's feasible, I prefer if the builder and hook are configured in the same way (even if that means changing the existing one).
   • The command itself and builder already support processing multiple scripts in a single invocation (so my concern here is already a reality in some sense), but I'm not quite sure how I feel about the tension between potentially having to apply the same exemption to many files and semi-indiscriminately applying one set of exemptions/inputs to many files.

[abathur]

Broke these out into separate issues to have a little more room to focus on each. Edited this post down to reflect new locations.