Re: Enable/disable (was Re: Enhanced shell)

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

On Jul 24,  1:00am, Nadav Har'El wrote:
> > 
> > As of 4.0.1, `builtin read' will run `read' even after `disable read'.
> > Maybe we need to rethink that.
> 
> Even if builtin's behavior remains, it's not so terrible, because somebody
> who wants to disable a builtin like read will just need to also disable
> "builtin"

That's unpleasant; it makes it impossible [*] to bypass a shell function
without unfunction-ing it.  It makes life more difficult for the person
setting up the restricted environment, as well as for the person using it.

It also potentially breaks the $functions parameter, in which the bodies
of undefined functions appear as `builtin autoload -X'.

> But now that I think of it, does zsh have restricted-shell capabilities at
> all?

It gained restricted shell mode somewhere fairly early in the 3.1 series,
so 4.0.x has it, but 3.0.x does not.

Try `setopt restricted'.  Just note that you can't unsetopt it again, so
you should be prepared to exit.

[*] OK, so it's not quite impossible:

function neither_alias_nor_function() {
  local +h aliases functions
  disable -a ${(k)aliases}
  disable -f ${(k)functions}
  "$@"
}
neither_alias_nor_function echo this is too clever

But of course being able to assign to the arrays from the $parameter module
also allows one to re-enable disabled commands, and one can always assign
to a variable by making it local, so it's impossible to disable enable
unless one disables zmodload, but then completion and lots of other things
don't work, and now you see what a hole we've dug ...