Methods of shadowing a builtin call

Methods of shadowing a builtin call

[Sebastian Gniazdowski]

Hello,
I shadow setopt to gather data of what is being done in sourced
script. I currently use alias setopt=--setopt-shadow and then source a
script. This works fine except for z-sy-h. For that project, when I
source it with the alias being in place, interiors of it then still
use the shadowing function during their later operations. How to
suppress this? Self-insert is in some way catched by z-sy-h, and each
keypress invokes my shadowing function.

When I change:
    alias setopt=--shadow-setopt
to:
    setopt() { --shadow-setopt "$@" }

then Zsh segfaults. I'm not sure if on OS X gdb gives meaningful
output, but this is the backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000001000184e4 in execrestore ()
(gdb) bt
#0  0x00000001000184e4 in execrestore ()
#1  0x00000001000135c4 in execlist ()
#2  0x0000000100012c27 in execlist ()
#3  0x0000000100012818 in execode ()
#4  0x0000000100016be2 in runshfunc ()
#5  0x0000000100016540 in doshfunc ()
#6  0x0000000100017ca6 in execrestore ()
#7  0x000000010001c031 in execrestore ()
#8  0x00000001000135c4 in execlist ()
#9  0x0000000100012d84 in execlist ()
#10 0x000000010003efae in execif ()
...

How to explain the segfault?

Is there any third method of attaching to setopt?

Best regards,
Sebastian Gniazdowski

Re: Methods of shadowing a builtin call

[Sebastian Gniazdowski]

The segfault problem clarified itself, it was a recursive setopt call,
without "builtin" prefix, done within --shadow-setopt.

Best regards,
Sebastian Gniazdowski

Re: Methods of shadowing a builtin call

[Bart Schaefer]

On Jan 29, 10:33pm, Sebastian Gniazdowski wrote:
}
} I shadow setopt to gather data of what is being done in sourced
} script.

As I alluded to in an earlier message, there is *no* effective way
to shadow "setopt" because of the way "localoptions" works.  If you
have

    --shadow-setopt() { builtin setopt "$@" }

and you execute e.g.

    --shadow-setopt localoptions shglob shwordsplit

then when --shadow-setopt exits, shglob and shwordplit will revert
to their previous settings and the whole thing is a no-op.  The same
thing will happen if you have

    emulate -L zsh
    --shadow-setopt shglob shwordsplit

because "emulate -L" turns on "localoptions".

And if you try to avoid that with this:

    --shadow-setopt() { unsetopt localoptions; builtin setopt "$@" }

then

    some_func() {
	--shadow-setopt localoptions shglob shwordsplit
    }
    some_func

will incorrectly leave shglob and shwordsplit turned *on* after the
function completes, because localoptions will never be seen in the
context of some_func.

The only way to track option changes is by examining deltas of values
in the $options hash.

} I currently use alias setopt=--setopt-shadow and then source a
} script. This works fine except for z-sy-h. For that project, when I
} source it with the alias being in place, interiors of it then still
} use the shadowing function during their later operations. How to
} suppress this?

It depends how z-sy-h declares or defines its functions.  If they are
declared with "autoload" but the -U option is not being used, then any
aliases defined at the time the function is first executed will expand
(because parsing and execution are effectively simultaneous, see next
sentence).

If instead the functions are fully defined, body and all, "in-line" in
the z-sy-h source files, there is no way to suppress this, because the
aliases expand when the function is *parsed*, and therefore the expanded
command text is already in place later when it is executed.

Re: Methods of shadowing a builtin call

[Sebastian Gniazdowski]

On 30 January 2016 at 00:09, Bart Schaefer <schaefer@brasslantern.com> wrote:
> The only way to track option changes is by examining deltas of values
> in the $options hash.

Thanks, don't know how could I miss this. I've re-implemented the
feature of tracking what options does a plugin change via $options
diffing. Code is much simpler, result also quite better – user sees
what changed in his environment, not what was done step by step.

> If instead the functions are fully defined, body and all, "in-line" in
> the z-sy-h source files, there is no way to suppress this, because the
> aliases expand when the function is *parsed*, and therefore the expanded
> command text is already in place later when it is executed.

Quite clear. Was hoping for some third method of shadowing,
add-zsh-hook and preexec maybe, something like this.

Best regards,
Sebastian Gniazdowski

Re: Methods of shadowing a builtin call

[Bart Schaefer]

On Jan 30, 10:31am, Sebastian Gniazdowski wrote:
}
} Was hoping for some third method of shadowing,
} add-zsh-hook and preexec maybe, something like this.

You could use the DEBUG trap, but that might interfere with other
uses thereof.