Does anybody here use es -e?

[jpco]

I was poking around with changing es' exit-on-false behavior to throw an exception on false, similar to how the exit command works by throwing an exception, and I realized that es -e is actually pretty difficult to use -- especially given the "assigments return the value" behavior es has.

So, I'm curious -- does anybody use es -e for their scripts?

Would it be easier or harder to use if assignments were special-cased not to cause $&exitonfalse to "fire"? Would that be worth the extra complexity and (potentially) extra surprise?

Incidentally, it actually causes an interactive shell to immediately exit for me, because my %prompt ends with an assignment. (Also my %write-history when using #65). Do people agree that that's weird -- %prompt shouldn't make the shell exit, even with the -e flag enabled?

Curious about others' thoughts -- since I don't tend to use this feature much, I don't trust my intuition a ton on it. (I do strongly feel that it should use an exception, though.)

[wryun]

I have tried to use it briefly in the past, and like you found it mostly useless. I can't remember exactly what problems I had, but I suspect the return values of assignments was the deal breaker (where assignments of course include things like function definitions).

The way I think about '-e' is that it's trying to catch results you've ignored, and if you've assigned the result you haven't ignored it, just like if you used it in the condition of an if statement. The current behaviour is the one that's surprising.

Having said that, I don't really understand how the original authors used it; perhaps it's a regression. It might be worth going back to when it was originally introduced and seeing if es behaved differently.

[jpco]

Having said that, I don't really understand how the original authors used it; perhaps it's a regression. It might be worth going back to when it was originally introduced and seeing if es behaved differently.

Well, I have a couple guesses here.

1. -e behaves the same way in rc and was added to es immediately (at least by 0.67), so I suspect it may have been included for compatibility and not necessarily for its specific usefulness in this shell.
2. Based on the CHANGES file, assignment only started returning its assigned value after 0.84 (it's added in 0.9-alpha1). This feature might be the "regression" itself.

[memreflect]

I believe this is due to the Unix-oriented shell semantics associated with truthiness.

To simplify things, a list is considered "true" if it is empty, i.e. (), or if the list is made up of one or more of the following:

• the string '0', indicating a Unix process exited without an error occurring
• empty strings '', because it's a string of length 0
• empty commands {}, because there are 0 commands

Everything else is considered "false", including result {} because that is treated as '{}', which is different from {}.
This means any use of the built-in vars function is guaranteed to the shell to exit immediately due to how it's written.
Fully fixing this would mean finding a way to differentiate between the string '0' and a Unix exit process status of 0 without breaking $&pipe, and determine how to handle {} and () as well, but things would behave more like other programming languages afterward, and this would no longer be an issue.
If an empty list became "false" instead of "true", it would also mean reading a file would be more intuitive:

# currently wrong: a non-empty line will result in a list of length 1, which is "false"
{
  while {line = <=%read} {
    echo $line
  }
} < file

# currently right: a non-empty line will result in a list of length 1, which `!` turns into 0 (true)
{
  while {! %count <={line = <=%read}} {
    echo $line
  }
} < file

This is likely why you think you experienced issues with your %write-history function.
The primitive results in (), which is "true".
The non-readline version is also fine as 0 will always be returned if you are able to write to the file.
But when you catch an error exception in %interactive-loop, the last line in the body of the if block is msg = $msg(1), which will cause trouble because you won't get a syntax error if the line is empty.

[jpco]

Okay, I've convinced myself that the fact that %parse can cause the shell to exit is actually a bug.

By my reasoning, the reason we have the %exit-on-false function at all is to make sure that the exit-on-false behavior can only be triggered in the right spots in the interactive or batch loops -- namely, the stuff that is called within %dispatch. Equivalently, the exit-on-false behavior should only ever be triggered if prim_exitonfalse is in the call stack. But %parse doesn't get called within %dispatch, and if you do some gdb spelunking, you'll see that prim_exitonfalse is nowhere in the call stack when a false result from %parse triggers the exit-on-false behavior.

The relevant code is runinput() in input.c, where the %dispatch function is defined:

if (flags & eval_exitonfalse)
	dispatch = mklist(mkstr("%exit-on-false"), dispatch);
varpush(&push, "fn-%dispatch", dispatch);

repl = varlookup((flags & run_interactive)
		   ? "fn-%interactive-loop"
		   : "fn-%batch-loop",
		 NULL);
result = (repl == NULL)
		? prim("batchloop", NULL, NULL, flags)
		: eval(repl, NULL, flags);

The problem, as I see it, is that flags is first used to add %exit-on-false to %dispatch, and then is reused unmodified in the eval(repl, ...) calls, making the %exit-on-false function completely redundant! You can test it yourself: Delete the whole if (flags & eval_exitonfalse) block and tell me if you find any change in the shell's behavior.

The right behavior here is to clear the eval_exitonfalse flag after setting %dispatch, like this:

if (flags & eval_exitonfalse) {
	dispatch = mklist(mkstr("%exit-on-false"), dispatch);
	flags &= ~eval_exitonfalse;
}

This makes %exit-on-false actually relevant, and makes %parse (and anything else invoked in the repls outside of %dispatch) free to be falsey.