Re: Failure of "typeset" and exit status

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On May 11,  7:43pm, Bart Schaefer wrote:
} Subject: Failure of "typeset" and exit status
}
} torch% ( () { typeset +g -m \* && echo No error } )
} (anon): failed to change user ID: operation not permitted
} (anon): failed to change group ID: operation not permitted
} (anon): failed to change effective user ID: operation not permitted
} (anon): failed to change effective group ID: operation not permitted
} No error
} torch% 
} 
} OK, that's not SO bad, except that "typeset +g -m \*" is intended to
} have made all the variables local ... which it has NOT, as you can see

OK, this is both more confusing and less borked than I thought.

The variables HAVE all been made local.  A subtlety that escaped me is
that in the example above, the read-only error on HISTCMD did not
happen, as it did below:

} (be sure to do this in a subshell if you try it yourself):
} 
} torch% ( () { typeset +g -m \* && unset -m \* } && typeset -p )
} (anon): failed to change user ID: operation not permitted
} (anon): failed to change group ID: operation not permitted
} (anon): failed to change effective user ID: operation not permitted
} (anon): failed to change effective group ID: operation not permitted
} (anon): read-only variable: HISTCMD
} torch% 

I forgot that "unset" on a read-only variable is a fatal error; it has
killed the entire subshell, so "typeset -p" never runs.  I incorrectly
interpreted the lack of output as meaning that all parameters were
unset, and thus were not local.

The *reason* that I believed that is because, when I ran that command
without the subshell parens, the prompt disappeared.  Turns out that
what's really happening there is that when PROMPT is made local, the
value of PS1 is erased because of the way the two are linked.  PS1 is
not yet a local at that point, so even when it is made local later the
damage has been done, localizing PROMPT has clobbered the global PS1
and thereby also clobbered the global PROMPT.

I'm entirely without ideas as to what we should do about that.  Likely
nothing except perhaps documenting it somewhere.

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?