Re: PATCH: skip command from debug trap

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Wow, longest thread in quite a while.

I'll preface this with a "gotcha" that I just noticed.  If you execute
these commands:

	TRAPDEBUG() { return 1 }
	setopt DEBUG_BEFORE_CMD IGNORE_EOF

You've just rendered your shell useless.  You can't even exit from it
(except by way of the ten-EOFs failsafe we put in some while ago).

On Aug 6, 10:30am, Rocky Bernstein wrote:
}
} >        x=3
} >        return --x
} >
} > returns "2".  How are you going to make any kind of option parsing for
} > return behave compatibly with that?
} 
} How about "return $((x))", or "return $((-x))"?

On Aug 6,  3:59pm, Stephane Chazelas wrote:
}
} See for instance kill(1). To kill a process group, you have to
} do:
} 
} kill -- -<pid>
} 
} So you'd have to do
} 
} return -- -3

You're both answering the inverse of the question I asked.  I *didn't*
ask "How do you make returning a math expression compatible with return
taking an option?"  The issue, as PWS understands, is that "return" is
already accepting math expressions, so introducing option parsing would
break that (unless done with some caveats).

} -- is not a valid math expression, so changing return -- so that
} it is the same as "return" instead of giving an error message
} shouldn't be a problem.

True, but not helpful all by itself.

On Aug 6,  4:34pm, Peter Stephenson wrote:
}
} Grrrr. All the control commands do that, and all for the sake of
} making the command line less clear by omitting the $((...)).

That's not really why, of course ... if you go back far enough, IIRC
you'll come to a version of the shell that has "return --x" but that
does not have $((...)).  Be that as it may ...

} However, return has never taken more than one argument up to now,
} so there's nothing to stop us only evaluating the final argument
} mathematically and require "return -s 0" to skip a statement and
} behave as if it returned 0.

I can live with that, if Rocky can live with the fact that to get the
debug trap to return the current value of $? and also skip the next
statement, one must do "return -s $?" or "return -s --".   Counting
arguments prevents any equivalence of "return" with no arguments and
"return" with only the skip option.

However, I have an alternate proposal (more on that below).

} We have a choice of rule: (i) with more than one argument, option and
} argument parsing becomes like other commands (so you need a -- if
} there's possibly a negative expression at the end but otherwise if it
} doesn't look like an option you still get math processing) (ii) with
} more than one argument, the last argument is always a value. I think
} (i) is probably slightly clearer.

Currently more than one argument is an error, so there shouldn't be any
way for an existing zsh script to run afoul of choice (i).

On Aug 6,  6:54pm, Peter Stephenson wrote:
}
} "Rocky Bernstein" wrote:
} > A couple other approaches are setting a variable or calling a routine.
} >  For example  "trap_return --skip"  or TRAP_RETURN="skip"
} 
} I don't like adding a new builtin just for this.
} 
} The variable version is doable, we've done similar things before.  You'd
} have to note that it didn't force return from the current environment,
} either the inline trap or TRAPDEBUG.  You'd also have to be prepared for
} the shell to manipulate the variable behind your back, else you'd run
} into problems with having it set on future traps.  It's not disastrous,
} but I'm not convinced this is simpler.  In fact, at the moment it seems
} to me manifestly much more complicated.

Here's another possibility.  Presently it's fairly useless to combine
"setopt ERR_EXIT" (set -x) with TRAPDEBUG, because any nonzero return
from the trap will cause the entire shell to exit, rather than just the
surrounding function.

I propose that ERR_EXIT be unset on entry to TRAPDEBUG, always.  Then at
return from the function, if ERR_EXIT has become set, treat that as an
indication to skip the command (and restore ERR_EXIT to whatever its
pre-function state was).  If you setopt ERR_EXIT and return non-zero
you still get what you always would (anyway, if you really wanted the
shell to exit, you can just call "exit" from the trap).  I can imagine
someone having done something arcane where they expect a failure of a
command inside a debug trap to kill their shell only when ERR_EXIT has
already been set globally, but it seems unlikely.

On Aug 6,  3:09pm, Rocky Bernstein wrote:
}
} But given the choice of adding
}    1) an option in the return statement everywhere that is specific to
} just "trap DEBUG" or
}    2) specifying what specific numbers do when on a return from "trap DEBUG",
} 
} isn't 2) simpler and more consistent with programming in shell
} languages work?

In other contexts return values above 128 are treated as indicative of
a caught signal.  If there were an imaginary signal that trips the DEBUG
trap, we could make return of $((128+SIGDEBUG)) mean something special.
But an out-of-band mechanism seems better.

I don't really have anything to say to PWS's most recent message on this.