Re: PATCH: print -v with an array

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 4,  5:37pm, Oliver Kiddle wrote:
} Subject: Re: PATCH: print -v with an array
}
} On 21 Sep, Bart wrote:
} > Yes, I'm wondering if print -S -f ... should just be an error.
} 
} Combining print -S with multiple arguments with a zsh debug build is printing:
}  exec.c:3837: BUG: q = 3 != queue_in = 4

Thanks for spotting that.  Patch below.

Doesn't answer the question of whether -S -f should be an error.  At the
moment -S and -C and -c are all ignored if -f is with them.  There is
code commented out to make an error of this.

} The most notable thing about this patch is what it does not do. I've
} not moved the array behaviour to a -A option. That's not something
} I'm especially bothered about and if someone is keen to change it
} then I don't especially care.

It has occurred to me that zsh doesn't really need print -v, except
for compatibility.  Other bourne-ish shells fork the right side of
pipes, so piping to read -A won't capture anything in the parent,
but zsh forks to the left.  I suppose print -v does avoid that fork.


diff --git a/Src/builtin.c b/Src/builtin.c
index b7b7bdf..6c9d058 100644
--- a/Src/builtin.c
+++ b/Src/builtin.c
@@ -4552,6 +4552,7 @@ bin_print(char *name, char **args, Options ops, int func)
 		    short *words;
 		    if (nwords > 1) {
 			zwarnnam(name, "option -S takes a single argument");
+			unqueue_signals();
 			return 1;
 		    }
 		    words = NULL;