From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29418 invoked by alias); 13 May 2015 08:39:56 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 35095 Received: (qmail 14869 invoked from network); 13 May 2015 08:39:53 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-f79c56d0000012ee-2c-55530dd4db84 Date: Wed, 13 May 2015 09:39:45 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Failure of "typeset" and exit status Message-id: <20150513093945.749366aa@pwslap01u.europe.root.pri> In-reply-to: <150512215919.ZM13985@torch.brasslantern.com> References: <150511194320.ZM12928@torch.brasslantern.com> <150512215919.ZM13985@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsVy+t/xq7pXeINDDWY3aVkcbH7I5MDoserg B6YAxigum5TUnMyy1CJ9uwSujA+/JrIVvOeqWDx3KlMD4zGOLkZODgkBE4ndh3eyQthiEhfu rWfrYuTiEBJYyihx4cQKRghnBpPE9OeNUM42Rokne7YzgbSwCKhKdLUeYwax2QQMJaZums0I YosIiEucXXueBcQWBoqvWt0FNJaDg1fAXmLjJCmQMKeAlcT3B7/ANgsJZEq8Wr8XzOYX0Je4 +vcTE8RF9hIzr5wBG8krICjxY/I9sJHMAloSm7c1sULY8hKb17xlhpijLnHj7m72CYxCs5C0 zELSMgtJywJG5lWMoqmlyQXFSem5hnrFibnFpXnpesn5uZsYIUH7ZQfj4mNWhxgFOBiVeHhn vA0MFWJNLCuuzD3EKMHBrCTCe5Q7OFSINyWxsiq1KD++qDQntfgQozQHi5I479xd70OEBNIT S1KzU1MLUotgskwcnFINjLFfVqQufCv4/NYiN7G+uGVcGztF6nidD6qzXPqk+mZtVuXL2Q7H xJnkVbbKGRTMPZ0VENMYoGa0PL3OV92oytGx7Nq7eZob8pyc+o5nXZ9wrc/C6O//H7vubHGU l7uy4ZtjlcG5fXtjq+KljSvX3lsuYay/aPoTx45Z8uWzt2neSHo6h/ljkRJLcUaioRZzUXEi AJQTgr1WAgAA On Tue, 12 May 2015 21:59:19 -0700 Bart Schaefer 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