Re: [BUG] Issue with set built-in in 5.8 (?)

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

dana wrote on Sun, 16 Feb 2020 20:19 -0600:
> Most of these errors are useful, but i'm not sure they should unconditionally
> abort the shell.
⋮
> @Daniel, we talked about the first one before, but this particular concern
> didn't come up at the time — what do you reckon?

Considerations:

- Compatibility with what zshoptions(1) has promised would work, though
  that didn't work before 5.8.

- Consistency with POSIX.  (POSIX doesn't specify -p, but still.)

- Consistency with other shells.

- Consistency between «set» and «setopt».

- On the one hand, "Errors should never pass silently".  On the other
  hand, in the shell language there are few other cases of aborting the
  shell just because a syscall returned an error.

- Regardless of what we choose, the other behaviour is achievable: if
  we make the error fatal people can use «eval» to make it non-fatal,
  and if we make the error non-fatal people can use «… || exit 1» to
  make it fatal.

I'm not sure what these add up to, but these are the addends I have
in mind.

Cheers,

Daniel


> % sudo perl -e '$< = 1; $> = 2; exec("zsh", "-fc", "id; unsetopt privileged; echo still here");'
> uid=1(daemon) gid=1(daemon) euid=2 egid=0(wheel) groups=...
> zsh:unsetopt:1: PRIVILEGED: supplementary group list not changed due to lack of permissions: EUID=2
> zsh:unsetopt:1: can't change option: privileged
> still here
> 
> % sudo perl -e '$< = 1; $> = 2; exec("zsh", "-fc", "id; set +p; echo still here");'
> uid=1(daemon) gid=1(daemon) euid=2 egid=0(wheel) groups=...
> zsh:unsetopt:1: PRIVILEGED: supplementary group list not changed due to lack of permissions: EUID=2
> zsh:set:1: can't change option: -p
>