localoptions, emulate -L, and top-level shell

localoptions, emulate -L, and top-level shell

[Bart Schaefer]

I'm wondering whether "setopt localoptions", including via "emulate -L",
perhaps ought to at least grumble if its state changes from unset to set
at the top level of an interactive shell.

Can wait until after 5.3, obviously.  Just thinking "aloud."

Re: localoptions, emulate -L, and top-level shell

[Daniel Shahaf]

Bart Schaefer wrote on Fri, Dec 02, 2016 at 15:50:33 -0800:
> I'm wondering whether "setopt localoptions", including via "emulate -L",
> perhaps ought to at least grumble if its state changes from unset to set
> at the top level of an interactive shell.
> 
> Can wait until after 5.3, obviously.  Just thinking "aloud."

Perhaps some people intentionally setopt localoptions in .zshrc so that
no plugin can change global options... but then, a plugin doing «setopt
nolocaloptions foo» would still set 'foo' globally, despite the zshrc
setting.

Re: localoptions, emulate -L, and top-level shell

[Peter Stephenson]

On Sat, 3 Dec 2016 08:23:43 +0000
Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Bart Schaefer wrote on Fri, Dec 02, 2016 at 15:50:33 -0800:
> > I'm wondering whether "setopt localoptions", including via "emulate -L",
> > perhaps ought to at least grumble if its state changes from unset to set
> > at the top level of an interactive shell.
> > 
> > Can wait until after 5.3, obviously.  Just thinking "aloud."
> 
> Perhaps some people intentionally setopt localoptions in .zshrc so that
> no plugin can change global options... but then, a plugin doing «setopt
> nolocaloptions foo» would still set 'foo' globally, despite the zshrc
> setting.

I think setting localoptions globally for the benefit of safety with
your own functions is a perfectly reasonable usage --- and it's also
compatible with supplied functions, which will happily leave the glocal
setting alone, so probably best not to do anything to undermine it
centrally.

I'm vaguely aware of having used "nolocaloptions" to pass up option
settings in the past, but I don't think there are standard functions
that do that.

pws

Re: localoptions, emulate -L, and top-level shell

[Bart Schaefer]

On Dec 5,  9:46am, Peter Stephenson wrote:
}
} I think setting localoptions globally for the benefit of safety with
} your own functions is a perfectly reasonable usage --- and it's also
} compatible with supplied functions, which will happily leave the glocal
} setting alone, so probably best not to do anything to undermine it
} centrally.

I wouldn't propose *preventing* it, and I agree that it should be OK to
set it in dotfiles at startup.

On the other hand executing "emulate -L" from an interactive prompt when
not inside a function scope is pretty suspicious -- it implies that the
user is expecting the emulation to have a limited scope.  A similar
point can be made about "setopt" if localoptions is applied at the same
time as one or more other options.

So I am musing about issuing a warning that the global scope is being
changed, and then doing it anyway, not musing about making it an error.

Re: localoptions, emulate -L, and top-level shell

[Sebastian Gniazdowski]

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

Subject: localoptions, emulate -L, and top-level shell
Local Time: December 3, 2016 12:50 AM
UTC Time: December 2, 2016 11:50 PM
From: schaefer@brasslantern.com
To: zsh-workers@zsh.org

I'm wondering whether "setopt localoptions", including via "emulate -L",
perhaps ought to at least grumble if its state changes from unset to set
at the top level of an interactive shell.

Can wait until after 5.3, obviously. Just thinking "aloud."

Just to mention that a little tool detecting option changes is possible – doing diff of options before and after a source of external code. Zplugin does that, one can detect what a plugin changes.

Best regards,
Sebastian Gniazdowski