Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: zsh-4.2.1: unset does not follow spec
- X-seq: zsh-workers 20401
- From: "Sean C. Farley" <sean@xxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: PATCH: zsh-4.2.1: unset does not follow spec
- Date: Wed, 22 Sep 2004 10:37:05 -0500 (CDT)
- In-reply-to: <Pine.LNX.4.61.0409220822040.16822@xxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20040922091323.V45751@xxxxxxxxxxxxxxx> <Pine.LNX.4.61.0409220822040.16822@xxxxxxxxxxxxxxxxxx>
On Wed, 22 Sep 2004, Bart Schaefer wrote:
On Wed, 22 Sep 2004, Sean C. Farley wrote:
Recently, I read that FreeBSD's /bin/sh fails:
http://www.freebsd.org/cgi/query-pr.cgi?pr=standards/45738
the IEEE Std 1003.1-2001:
http://www.opengroup.org/onlinepubs/007904975/utilities/unset.html
when it comes to the builtin unset. tcsh and bash do follow it.
I don't see how zsh "fails" this specification.
EXIT STATUS
0
All name operands were successfully unset.
>0
At least one name could not be unset.
It appears to me that FreeBSD and Zsh are interpreting "could not be
unset" to include variables that were not set in the first place.
After all, if it isn't set, you can't UNset it, can you? It doesn't
say "0 if all name operands end up unset after this is finished,
regardless of their previous state" (which is how bash and tcsh appear
to interpret it).
This is also in the spec:
Unsetting a variable or function that was not previously set shall
not be considered an error and does not cause the shell to abort.
I assume non-zero is an error.
I'm going to ask about this on the austin-group list. It'll give them
something to discuss that they might actually come to agreement on.
From your comment, it sounds like hell might freeze over first. :)
I can see where both views are correct. Let me know when you hear back
from them.
Sean
---------------
sean@xxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author