PATCH: return command's exit code from _call

PATCH: return command's exit code from _call

[Oliver Kiddle]

completion for groups had broken again, with ypcat dumping error
messages over my terminal. The problem was that _call was now being used
to call ypcat but didn't pass on its exit code.

Oliver

Index: Completion/Core/_call
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_call,v
retrieving revision 1.2
diff -u -r1.2 _call
--- Completion/Core/_call       2000/04/01 20:43:43     1.2
+++ Completion/Core/_call       2000/05/11 15:29:31
@@ -11,3 +11,5 @@
 else
   eval "$argv[2,-1]"
 fi
+
+return $?

Re: PATCH: return command's exit code from _call

[Bart Schaefer]

On May 11,  4:30pm, Oliver Kiddle wrote:
} Subject: PATCH: return command's exit code from _call
}
} completion for groups had broken again, with ypcat dumping error
} messages over my terminal. The problem was that _call was now being used
} to call ypcat but didn't pass on its exit code.

The exit value of a function is supposed to be the exit value of the last
command that it executed.  That is, "return $?" should be unnecessary; if
$? has the right value to begin with, that's what should be returned by
default.

So if this patch really changed the behavior, then there's another bug
somewhere else (perhaps in the wordcode executor for if/else/fi?).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

PATCH: Re: return command's exit code from _call

[Oliver Kiddle]

Bart Schaefer wrote:
> 
> The exit value of a function is supposed to be the exit value of the last
> command that it executed.  That is, "return $?" should be unnecessary; if
> $? has the right value to begin with, that's what should be returned by
> default.

I sort-of knew that somewhere at the back of my mind but I wasn't sure
if the last command would be the if statement or the eval command?

> So if this patch really changed the behavior, then there's another bug
> somewhere else (perhaps in the wordcode executor for if/else/fi?).

Oops, this is my fault for being too hasty and too stupid. The problem
is that the redirection of stderr had been lost and was nothing to do
with the exit code. The exit code was my first guess because that was
what the problem was last time. It appeared to fix the problem, because
the first time, I ran it, it produced the error message, I reloaded
_call and it worked properly but that was because _cache_groups had now
been set.

The patch fixes _groups. I'll also correct _call.

Sorry about that

Oliver

Index: Completion/User/_groups
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_groups,v
retrieving revision 1.3
diff -r1.3 _groups
10c10
<         tmp=$(_call groups ypcat group.byname); then
---
>         tmp=$(_call groups ypcat group.byname 2>/dev/null); then