Should %run be the built-in way binaries are run?

[jpco]

es has a hook function called %run for fork/exec-ing a binary with the given arguments as its argv. This is cool, but the function isn't actually used by es itself without some hackery to %pathsearch

fn %pathsearch name {
  result %run <={access -n $prog -1e -xf $path} $prog
}

and then potentially doing something to deal with the fact that %whatis bin now returns the ugly

%run /path/to/bin bin

and then feeling sad about the fact that if a user passes in an absolute path, %run just won't be called.

It seems more es-ish to just replace the forkexec() calls in eval() with calls to %run (or maybe fall back to $&run, if %run isn't set). Outside of $&run, eval() is the only place where forkexec() gets called, so this would be a complete implementation of the hook function.

A concrete possibility this enables is the setting of a bash- or zsh-like $_ for any invoked binary (from man bash, this: "the full pathname used to invoke each command executed and placed in the environment exported to that command"), like this:

let (r = $fn-%run)
fn %run cmd args {
  local (_ = $cmd) $r $cmd $args
}

[memreflect]

I like the idea of replacing the forkexec() calls in eval() with %run invocations.

If the result is non-zero from $&run, a custom %run hook might throw an exception, differentiating a nonzero exit code from the richer results made possible by functions in es, which results two nice side effects:

• result anything could evaluate as "true" like result 0 currently does, while result () could evaluate as "false", finally fixing the weird backwards logic es currently has that makes (), 0 and '' evaluate as "true".
• -e would be unnecessary as an uncaught exception would lead to abnormal shell termination anyway.

Of course, how such changes interact with if, %background/wait, fork, and %pipe requires investigation, unlike your proposed change that will "just work".

[jpco]

Hmm, those are interesting ideas -- I'd never thought about the idea that with enough runtime support, it could be possible to change the shell's idea of true/false. I'm not sure I'd want to use that shell, but it's certainly interesting to consider :)

Questions of design aside... Unfortunately, exceptions coming from %run don't work with subshells, as you suspect. You might be able to do some hackery to make it work, but I'm not sure it would end up any simpler than the built-in eval_exitonfalse mechanism. I'd be happy to be proven false, though: I have no great love for evalflags/runflags.

The basic challenge is that %run is called exactly in the context the binary is run -- redirections, subshells, and all. It's a highly chaotic set of conditions, and what's worse is that with all the behaviors the binaries themselves can have, it's hard for %run to do much of anything that's robust and known to be independent of the binary's output. %run is useful for interacting with the invoked binary, but nearly impossible to use robustly for interacting with the parent shell.