Re: Failure of "typeset" and exit status

[Peter Stephenson <p.stephenson@samsung.com>]

On Tue, 12 May 2015 21:59:19 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Now, the other question is, why is it a fatal error to attempt to change
> a variable that is explicitly read-only, but only a warning to attempt
> to change UID, GID, etc. when you do not have permission to do so?

So you're worried about this

  % (){ local UID && print Still going; }
  (anon): failed to change user ID: operation not permitted
  Still going

and the other typeset stuff isn't relevant here.

As far as the *shell* is concerned, you *do* have permission to change
it.  It just happens to be attached to a system call that failed.  The
UID was succesfully made local, and printing it successfully reflects
your current UID.

I don't really have any feel for how to treat failures of this kind.

Here's one possibility: in that case, there's no explicit set to UID so
maybe we should make it local and leave it alone --- I'm not sure how to
detect a case like this, though.  Then if you explicitly assign to it
(in our out of typeset) and *that* fails, return status 1.  Whether this
is a hard error is really up to convenience, since there's no obvious
prior art:  is it more useful forcing people to use a subshell to test
for the assignment failure to ensure attempts to set UID are picked up
safely, or to require them to test the command status?

pws