PATCH: zsh-4.2.1: unset does not follow spec

PATCH: zsh-4.2.1: unset does not follow spec

[Sean C. Farley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 632 bytes --]

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 then checked zsh.  It also fails this specification (if it desired to
follow it for unset?).  I have attached a patch that returns zero for
unset.  It also affects unhash for functions to handle unset -f.

Sean

P.S. I am not on the list; please cc.

P.P.S.  http://www.zsh.org/mla/patches.shtml has not been updated past
March 2004.
---------------
sean@farley.org

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1331 bytes --]

--- Src/builtin.c.orig	Fri Aug 13 05:22:42 2004
+++ Src/builtin.c	Wed Sep 22 09:44:04 2004
@@ -2638,9 +2638,9 @@
 		returnval = 1;
 	    }
 	}
-	/* If we didn't match anything, we return 1. */
+	/* If we didn't match anything, we return 0. */
 	if (!match)
-	    returnval = 1;
+	    returnval = 0;
 	return returnval;
     }
 
@@ -2661,7 +2661,7 @@
 		      gethashnode2(paramtab, s) :
 		      paramtab->getnode(paramtab, s));
 	if (!pm)
-	    returnval = 1;
+	    returnval = 0;
 	else if ((pm->flags & PM_RESTRICTED) && isset(RESTRICTED)) {
 	    zerrnam(name, "%s: restricted", pm->nam, 0);
 	    returnval = 1;
@@ -3056,9 +3056,17 @@
 		returnval = 1;
 	    }
 	}
-	/* If we didn't match anything, we return 1. */
-	if (!match)
-	    returnval = 1;
+	/*
+	 * If we didn't match anything, we return 0 for functions and 1 for
+	 * all other hash types.
+	 */
+	if (!match) {
+	    if (OPT_ISSET(ops,'f')) {
+		returnval = 0;
+	    } else {
+		returnval = 1;
+	    }
+	}
 	return returnval;
     }
 
@@ -3069,7 +3077,11 @@
 	    ht->freenode(hn);
 	} else {
 	    zwarnnam(name, "no such hash table element: %s", *argv, 0);
-	    returnval = 1;
+	    if (OPT_ISSET(ops,'f')) {
+		returnval = 0;
+	    } else {
+		returnval = 1;
+	    }
 	}
     }
     unqueue_signals();

Re: PATCH: zsh-4.2.1: unset does not follow spec

[Bart Schaefer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 994 bytes --]

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).

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.

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1331 bytes --]

--- Src/builtin.c.orig	Fri Aug 13 05:22:42 2004
+++ Src/builtin.c	Wed Sep 22 09:44:04 2004
@@ -2638,9 +2638,9 @@
 		returnval = 1;
 	    }
 	}
-	/* If we didn't match anything, we return 1. */
+	/* If we didn't match anything, we return 0. */
 	if (!match)
-	    returnval = 1;
+	    returnval = 0;
 	return returnval;
     }
 
@@ -2661,7 +2661,7 @@
 		      gethashnode2(paramtab, s) :
 		      paramtab->getnode(paramtab, s));
 	if (!pm)
-	    returnval = 1;
+	    returnval = 0;
 	else if ((pm->flags & PM_RESTRICTED) && isset(RESTRICTED)) {
 	    zerrnam(name, "%s: restricted", pm->nam, 0);
 	    returnval = 1;
@@ -3056,9 +3056,17 @@
 		returnval = 1;
 	    }
 	}
-	/* If we didn't match anything, we return 1. */
-	if (!match)
-	    returnval = 1;
+	/*
+	 * If we didn't match anything, we return 0 for functions and 1 for
+	 * all other hash types.
+	 */
+	if (!match) {
+	    if (OPT_ISSET(ops,'f')) {
+		returnval = 0;
+	    } else {
+		returnval = 1;
+	    }
+	}
 	return returnval;
     }
 
@@ -3069,7 +3077,11 @@
 	    ht->freenode(hn);
 	} else {
 	    zwarnnam(name, "no such hash table element: %s", *argv, 0);
-	    returnval = 1;
+	    if (OPT_ISSET(ops,'f')) {
+		returnval = 0;
+	    } else {
+		returnval = 1;
+	    }
 	}
     }
     unqueue_signals();

Re: PATCH: zsh-4.2.1: unset does not follow spec

[Sean C. Farley]

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@farley.org

Re: PATCH: zsh-4.2.1: unset does not follow spec

[Peter Stephenson]

We discussed this problem with unset before.  I don't think we were
interested enough to do anything about it.  However, I think the
requirement that unsetting an unset variable isn't an error is explicit.

It's a question (I'm sure I or someone said this last time) of whether
you want to know whether the variable was unset by the call, or was in
an unset state at the end of the call.  I can see why you might consider
the latter more useful.  After all, you wouldn't want setting a variable
to fail if it was already set.

The zsh documentation isn't explicit about the return status.  So I
wouldn't think there's any harm in the change.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: PATCH: zsh-4.2.1: unset does not follow spec

[Matthias B.]

On Wed, 22 Sep 2004 08:28:03 -0700 (PDT) Bart Schaefer
<schaefer@brasslantern.com> wrote:

> 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. 

Arguing over the letter of a specification is not useful. You'll have to
ask yourself what the user expects and wants. Users are almost always
interested in results. They want to know if a function has produced the
result that they wanted it to produce. When your boss tells you to hammer
a nail into the wall at spot X, you go there and find that there is
already a nail, what do you do? Do you go crying to your boss that you
can't finish the task? Do you think he cares? Do you think he'll
appreciate it, if you mention this as a problem in your report that could
potentially halt the complete project?

BTW, the behaviour of unset should, I think, depend on the UNSET option.
If UNSET is off, then unset should report an error if the variable is
already unset.


MSB

-- 
Want to learn long division in ternary?
Contact me at ICQ 2101001122212.01/0.00002

Re: PATCH: zsh-4.2.1: unset does not follow spec

[Bart Schaefer]

On Wed, 22 Sep 2004, Matthias B. wrote:

> On Wed, 22 Sep 2004 08:28:03 -0700 (PDT) Bart Schaefer
> <schaefer@brasslantern.com> wrote:
> 
> > 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. 
> 
> Arguing over the letter of a specification is not useful.

Firstly, I was stating a theory, not arguing a position.  Secondly, one 
can't start from the premise of "X does not follow the letter of the 
specification" and then dismiss all discussion of what the letter _is_.

> When your boss tells you to hammer a nail into the wall at spot X, you 
> go there and find that there is already a nail, what do you do?

Wrong question.  When your boss tells you to pull a nail out of the wall 
at spot X and bring it to him, and you go there and find that there is no 
nail to pull, what do you do?  Do you think he'll appreciate it if you
never tell him why he didn't get his nail?

That's not the right question either, but it's closer.  The right question 
is more like:  When your boss tells you to pull a nail out of the wall at 
spot X, and you go there and find that there is no nail to pull and no 
hole where one used to be, how do you find out whether your boss cares 
about the hole?

Nevertheless:

> BTW, the behaviour of unset should, I think, depend on the UNSET option.
> If UNSET is off, then unset should report an error if the variable is
> already unset.

This is actually what I was going to suggest.

(Is it time for "emulate posix"?)

Re: PATCH: zsh-4.2.1: unset does not follow spec

[Peter Stephenson]

Bart Schaefer wrote:
> (Is it time for "emulate posix"?)

I suppose it's plausible, since the addition is transparent.  We
currently have something along the lines of sh being traditional Bourne
shell, ksh and being more or less a superset of sh (though somebody
pointed out a few weeks ago that ksh doesn't seem to have the effect of
sh_file_expansion).  Given that there are differences between ksh and
posix, a new option would probably be necessary.

However, the only use of posix would be to switch to it automatically in
the appropriate place.  If you have to trigger it by hand it's too late
for most of the places where people want to guarantee Posix compliance.
How would that be triggered?  Some (gag) environment variable?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: PATCH: zsh-4.2.1: unset does not follow spec

[Oliver Kiddle]

Bart wrote:
> > BTW, the behaviour of unset should, I think, depend on the UNSET option.
> > If UNSET is off, then unset should report an error if the variable is
> > already unset.
> 
> This is actually what I was going to suggest.

Nice try but the unset option (or nounset to be precise) is one of the
options defined in the POSIX specification.

Even if that were not the case, I would disagree. The unset option deals
with variable expansions and I don't see why it would be useful to
overload it with control of this issue. A user's preference on the two
issues wouldn't necessarily correlate.

The specification looks fairly clear to me (zsh is wrong) and I can't
see why anyone would be sufficiently attached to the old behaviour to
want an option for it.

> (Is it time for "emulate posix"?)

Possibly.

How would it differ from "emulate sh"?

Oliver

Re: PATCH: zsh-4.2.1: unset does not follow spec

[Bart Schaefer]

On Thu, 23 Sep 2004, Oliver Kiddle wrote:

> The specification looks fairly clear to me (zsh is wrong)

On Thu, 23 Sep 2004, Geoff Clare wrote:
> 
> I would say that a non-zero exit for "unset" is definitely an error, but 
> the standard is unclear as to whether "unset" is required to treat an 
> attempt to unset a variable that was not previously set as an ordinary 
> error (as opposed to a "utility syntax error", which is definitely not 
> allowed).
> 
> -- 
> Geoff Clare, opengroup.org

I don't really have a strong opinion either way (I can't remember EVER
testing the exit status of "unset" but I suppose it could affect the
shell in the case of "setopt errexit"), but I don't think it's as cut
and dried as it should be.

(Back to Oliver)
On Thu, 23 Sep 2004, Oliver Kiddle wrote:
> 
> > (Is it time for "emulate posix"?)
> 
> Possibly.
> 
> How would it differ from "emulate sh"?

At the moment, it might not.  If, however, we were to discover a case 
where POSIX specifies behavior that differs from historic /bin/sh 
behavior, we might want a plain way to get either one.

Also, although "emulate" has so far been limited to setting options, it 
might be worth considering whether it should also modify the environment, 
e.g., exporting POSIXLY_CORRECT or UNIX95 or whatever.  However, what it 
exported would depend on compile-time configuration, which although it 
could be OS-specific could not be architecture-specific, making trouble
on binary-compatible platforms that use different techniques to achieve
POSIX conformance.  So, I'm not sure.