Unintended side-effects of "emulate -c" ?

Unintended side-effects of "emulate -c" ?

[Bart Schaefer]

} emulate command might just as well parse other startup-time options
} besides just -c. [...]
} I've got this 98% working by factoring a loop out of init.c:parseargs()

I'm now reasonably sure I have this 100% working.

In the course of doing so I noticed some side-effects of "emulate -c" that
have nothing to do with my fiddling with it.

First, some context:

torch% (){ setopt localoptions restricted } && print $options[restricted]
on
torch% setopt +r
setopt: can't change option: -r

I.e., "restricted" is normally a sticky option.  Once you turn it on, even
in a function context with localoptions in effect, it cannot be turned off.

Now consider (starting again from zsh -f):

torch% emulate sh -c 'setopt restricted' && print $options[restricted]
off

That is, it's possible to have a restricted emulation, and then revert
back to unrestricted when the emulation completes.  This is actually a
nice feature, one that was never do-able before because there was no
scope in which "localoptions" was guaranteed to remain in effect all
the way to the end of the scope.  But ... was it intentional?

Note that for obvious reasons the opposite is prevented, that is, you
can't temporarily become unrestricted:

torch% set -r
torch% emulate sh -c 'unsetopt restricted' && print $options[restricted]
unsetopt: can't change option: restricted
on

I've retained this behavior in my tweaked emulate:

torch% emulate zsh -rc 'print $options[restricted]'
on
torch% print $options[restricted]
off
torch% set -r
torch% emulate zsh +rc 'print $options[restricted]'
emulate: can't change option: -r
on

Restricted-ness is not "sticky" the way emulation mode is, so you can't
use this trick to create a function that is always restricted ... but I
suspect it might not be too difficult to change that.

Another less desirable unintended side-effect:

torch% emulate zsh -c 'set -o vi'

This is equivalent to "bindkey -v" and leaks out of the emulate scope.
A similar thing happens with sunkeyboardhack and banghist.

On a related note, naming the sunkeyboardhack option to setopt even with
no change in state, discards any user-assigned value of $KEYBOARD_HACK;
and assigning to KEYBOARD_HACK turns on the behavior without changing
the setting of the option.  That should at least be documented?

Re: Unintended side-effects of "emulate -c" ?

[Bart Schaefer]

On Mar 4,  8:59pm, I wrote:
}
} Another less desirable unintended side-effect:
} 
} torch% emulate zsh -c 'set -o vi'
} 
} This is equivalent to "bindkey -v" and leaks out of the emulate scope.
 
Unfortunately for setopt vi / emacs, there's no way outside of the zle
module to tell which keymap is in effect.  Changing the setting of the
vi or emacs options changes the keymap, but changing the keymap (with
bindkey) does not change the options, so literally any keymap might
need to be restored.  Managing this from "emulate" would require at
least two new ZLE_CMD* entry points.

So for the time being I've punted, and asserted that you can't change
those two options with emulate.

} A similar thing happens with sunkeyboardhack and banghist.

As it turns out the only effect this has for banghist is a bit obscure;
history references continue to work but for a limited time the quoting
rules for "!" are changed.  This doesn't last long as inittyptab() gets
called almost ridiculously often, which eventually repairs it again.

-- 
Barton E. Schaefer