Re: [PATCH]: New hook function "atexec"

[Michael Hwang <nomex45@yahoo.com>]

[-- Attachment #1: Type: text/plain, Size: 2488 bytes --]

Peter Stephenson <p.w.stephenson@ntlworld.com>wrote:

> I'm not sure where this needs to be called execcmd(), there's so much
> going on there.  The issue I'm most worried about is redirection; where
> is the output of hook functions called in the middle of a pipeline going?

atexec is triggered before redirection, so it's not a problem.

% atexec () { print -- ${(q-)@} }
% print "Testing 1 2 3" | cat > temp

The commands are printed to the screen, indicating that atexec is not affected by redirection. Opening temp reveals nothing unexpected.

> However, it also worries me that this is calling execcmd() recursively
> in strange ways never before attempted---we partly set up a command for
> execution, then call an entire arbitrary execution tree, then finish
> executing the command.  This could easily have odd effects.  I wonder if
> using execsave() and execrestore() might be sensible.

I'm not sure if it's sensible either. I know at least that I have to set "errflag = 0", as execsave doesn't take care of it.

> I'm surprised you only need to set atexec to zero in two places, but
> there may be another way of testing the conditions you want anyway.

The difficulty is figuring out whether or not the current zsh process is an asynchronous child. As far as I know, zsh doesn't keep track of whether the current process is the result of an asynchronous fork. I don't think we can eliminate the "atexec = 0" here.

Also, I was thinking that sfcontext should be set to SFC_SUBST during command substitution. That would be a way to remove an "atexec = 0".

> I don't see why you need the test for sourcelevel, which stops it
> happening in all "." files.  That might be sensible for init files, but
> otherwise it seems a bit arbitrary when other limitations might be more
> useful.  For example, I don't see anything to stop this being run for
> every individual command in every function run by the user, which could
> be a huge overhead, probably more so that "." files which tend to be
> one-off.  (I think the test for "sfcontext" happens to catch a lot of
> completion functions, however.)  I'd be tempted to add a "locallevel"
> test to exclude all function bodies.  If necessary we can think of a way
> of reactivating it in a function.

Without the test for sourcelevel, a manual "source" by the user would trigger atexec for each command in the file. The sfcontext of the body of a function is SFC_DIRECT, and hence is excluded from atexec.

Michael Hwang



      

[-- Attachment #2: Type: text/html, Size: 3007 bytes --]