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 having eval() go through $&run would make it the only way binaries are invoked.

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.

[jpco]

#241 is an alternative/addition to #90, which does an even better job of making binary invocation something the shell can do, rather than something built into the shell:

1. Rewrite the $&whatis-duplicating logic in eval.c to: look for a function, and if there isn't one, call %whatis
2. Rewrite %whatis so that for either an absolute binary or a %pathsearched one, it returns %run $path $name
3. Remove $&whatis as it is now redundant
4. Move the forkexec()/failexec() logic to prim-sys.c where it belongs (like in Use the %run hook function for running binaries. #90).

With that change, it would become the case that the core shell can run either (1) special syntactic forms (including primitives) or (2) functions, and anything else has to be converted into a function by %whatis. I think that's a very straightforward story.

Doing things that way would take all the special logic about invoking binaries out of the "core" of the shell and put it into initial.es and primitives, which supports the librarified-es goal (if anybody other than me still has that as a goal, that is.)

It also makes the whole %whatis situation a little less confusing, as %whatis would now actually be a hook function (see for example #170, though in that case I still think %pathsearch would have been the right function to modify), and removes $&whatis, which has always been awkward. Removing $&whatis also lines up nicely with #219, since $&whatis is the only primitive that really ever used the calling lexical context.

Most relevant to this issue, it would make the following line from the first comment obsolete:

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