Open jpco opened 8 months ago
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".
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. I still think it's a good idea to have %run
, but it is hard to do a lot with it effectively.
es has a hook function called
%run
for fork/exec-ing a binary with the given arguments as itsargv
. This is cool, but the function isn't actually used by es itself without some hackery to%pathsearch
and then potentially doing something to deal with the fact that
%whatis bin
now returns the uglyand 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 ineval()
with calls to%run
(or maybe fall back to$&run
, if%run
isn't set). Outside of$&run
,eval()
is the only place whereforkexec()
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 (fromman bash
, this: "the full pathname used to invoke each command executed and placed in the environment exported to that command"), like this: