> **Note:** For now, at least, you'll need to reference the manpage to completely understand these examples.

## Controlling nested resolution with lore

Initially, resolution of commands in the arguments to command-executing
commands was limited to one level for a hard-coded list of builtins and
external commands. resholve can now resolve these recursively.

This feature combines information (_lore_) that the resholve Nix API
obtains via binlore ([nixpkgs](../../tools/analysis/binlore), [repo](https://github.com/abathur/resholve)),
with some rules (internal to resholve) for locating sub-executions in
some of the more common commands.

- "execer" lore identifies whether an executable can, cannot,
  or might execute its arguments. Every "can" or "might" verdict requires:
  - an update to the matching rules in [binlore](https://github.com/abathur/binlore)
    if there's absolutely no exec in the executable and binlore just lacks
    rules for understanding this
  - an override in [binlore](https://github.com/abathur/binlore) if there is
    exec but it isn't actually under user control
  - a parser in [resholve](https://github.com/abathur/resholve) capable of
    isolating the exec'd words if the command does have exec under user
    control
  - overriding the execer lore for the executable if manual triage indicates
    that all of the invocations in the current package don't include any
    commands that the executable would exec
  - if manual triage turns up any commands that would be exec'd, use some
    non-resholve tool to patch/substitute/replace them before or after you
    run resholve on them (if before, you may need to also add keep directives
    for these absolute paths)

- "wrapper" lore maps shell exec wrappers to the programs they exec so
  that resholve can substitute an executable's verdict for its wrapper's.

> **Caution:** At least when it comes to common utilities, it's best to treat
> overrides as a stopgap until they can be properly handled in resholve and/or
> binlore. Please report things you have to override and, if possible, help
> get them sorted.

There will be more mechanisms for controlling this process in the future
(and your reports/experiences will play a role in shaping them...) For now,
the main lever is the ability to substitute your own lore. This is how you'd
do it piecemeal:

```nix
{
  # --execer 'cannot:${openssl.bin}/bin/openssl can:${openssl.bin}/bin/c_rehash'
  execer = [
    /*
      This is the same verdict binlore will
      come up with. It's a no-op just to demo
      how to fiddle lore via the Nix API.
    */
    "cannot:${openssl.bin}/bin/openssl"
    # different verdict, but not used
    "can:${openssl.bin}/bin/c_rehash"
  ];

  # --wrapper '${gnugrep}/bin/egrep:${gnugrep}/bin/grep'
  wrapper = [
    /*
      This is the same verdict binlore will
      come up with. It's a no-op just to demo
      how to fiddle lore via the Nix API.
    */
    "${gnugrep}/bin/egrep:${gnugrep}/bin/grep"
  ];
}
```


The format is fairly simple to generate--you can script your own generator if
you need to modify the lore.