From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4792 invoked by alias); 27 Jul 2015 16:15:19 -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: 35936 Received: (qmail 7586 invoked from network); 27 Jul 2015 16:15:18 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=VSNOUIDLZ9zbs9dy0i3F62E+K4QCju7mWFlNPxm/JJw=; b=TwXDuNbJx18DjYc9Pp38x+yhOonkPebu62+p/NbopcEjbervNSiNghH8CBbScmx/XP aF0UhTBAw56Y86ZO1oSw5plZnXRBEhT6STLIlUEmJC5PjvnGmRnYLi2ot8iL46rjiXnf JZNQBWgbCEHuMYCz7XLu6IBLuS5lxlTq75yalEm19XxB3+9IXNYzFusZOyW3O8420GWA GUxY+/bcfkPz6OuVkxXOLf1m/XdfzkpmwW3jVu/+r8rtUVXUdHxHF/esUuYcI2acnXry CilWIW00OgMt/03qnuU+R9qde7QrzYPsXDxD1DL+u9wKoLkdWsW+JvJfTtOIqlyr8KoC oZvA== X-Gm-Message-State: ALoCoQmxvAfMTsPwVcfyhGP3VmStWUk0FiWrtSkSZhzdHtUhLBsq68eRKSIDJs+suwYtzZMibex4 X-Received: by 10.202.15.11 with SMTP id 11mr24380149oip.127.1438013715945; Mon, 27 Jul 2015 09:15:15 -0700 (PDT) From: Bart Schaefer Message-Id: <150727091512.ZM6365@torch.brasslantern.com> Date: Mon, 27 Jul 2015 09:15:12 -0700 In-Reply-To: <87lhe23psr.fsf@secretsauce.net> Comments: In reply to Dima Kogan "zargs parallelization support blows up with |&" (Jul 27, 2:36am) References: <87lhe23psr.fsf@secretsauce.net> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Dima Kogan , zsh-workers@zsh.org Subject: Re: zargs parallelization support blows up with |& MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jul 27, 2:36am, Dima Kogan wrote: } } [... when piping] stdout and } stderr for some output, then ALL the processes are invoked at the same } time, not just 2 at a time like I asked: } } zargs -P2 -i -l1 `seq 10` -- perl -e 'sleep 20' {} |& grep x } } I don't know if this is a bug or an expected consequence of some } internal implementation details, but this is a really nasty failure } mode. The problem is that when you append a pipe to the end, zargs ends up as a subshell, and you can't do job control in a subshell (which you would have seen if you weren't grepping stderr): (eval):wait:1: can't manipulate jobs in subshell The workaround for now is as follows: Copy the zargs script file to somewhere in your $path, e.g. ~/bin/. Edit the copy to add a #!/bin/zsh (or your local path) at the top, and "chmod +x" the file. Then either always run zargs as a script instead of an autoload, or when you need to pipeline it, use "command zargs". This is a little less convenient because it loses access to interactively-defined functions, but if you're zargs-ing another external command such as perl it should work fine.