From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16507 invoked by alias); 1 Mar 2017 17:33:16 -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: 40687 Received: (qmail 13810 invoked from network); 1 Mar 2017 17:33:16 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(205.235.26.22):SA:0(0.5/5.0):. Processed in 1.073743 secs); 01 Mar 2017 17:33:16 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: SRS0=o+GU=2K=brasslantern.com=schaefer@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at bounces.park01.gkg.net does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=brasslantern-com.20150623.gappssmtp.com X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=yttmDjnBYIZEcdP4Qc/R/AxMqOgJIy+ES1HrVG7/clA=; b=mobQ69OQjzAkvhOUY0hPNQTi9MLgW+o9bkPDgbjwT9sHl/HASZMDSL13i+Uq5emhDP RxqRrmNRSQOZOXdAuVHfDFVwx+0TDPAKO51YEhZY7ArkbmcRp2AV8HpMkB5nrQw1TPUr ihBMhb4KzGZi2aR0K64tFruaM3H2R72T1OLnPQ1RsWyZQ5onMTSDMu0VUy1k2RU5VdUK KDfvLixlp6uyA1u77SgFJlkoWjIrzXXMgCh3VxuWppuKWoOvLFzPTXAq7Wq1pq4Y8akH Sd842jwMmuoVI71JoK0/HnWdZV46NQiw/gTVBYbfnoNQnOp3RQ05fwpbESTB+uuorXQ0 dp5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=yttmDjnBYIZEcdP4Qc/R/AxMqOgJIy+ES1HrVG7/clA=; b=Rc3LOAcCZ9UYc5ypHaF/uTYbKh0DEED/XVHUXtNVAQsLHFLIa+PXikA2Z2PyHbgqZY ejLKsuCQY2Ot1fCywPrtG6wkjmOLG78eiMTGn9smORg89OuYbVeTz0P1gtnVUnmg43iH PKQbYzAMNXoOsSnq9cEtHYJlRngKEtdZftKP3J82N+HF4brCjgzSFo1UTOWBiuUJ3twS ynpoReDidfppugwV0XZAMIYaOfKb78nvx7rnO1NTBQXGkDGU1OkRjZ5CLJF9ZumKZB4f Jy9aKA7sxAV1oEJeqEwXKnRlfC6tkM3tRiMEFerXFgQDm94Yx2JrnciLQHoZeOPuske2 VFCg== X-Gm-Message-State: AMke39lpKF6lXTlNjVP8DIYpq6kpfup9Y/OlOrJGlbJTxf1bnBcZF+n6ndJ7ghiaZdDL4w== X-Received: by 10.159.39.39 with SMTP id a36mr3842732uaa.32.1488389564395; Wed, 01 Mar 2017 09:32:44 -0800 (PST) From: Bart Schaefer Message-Id: <170301093258.ZM11760@torch.brasslantern.com> Date: Wed, 1 Mar 2017 09:32:58 -0800 In-Reply-To: <1488365385.3896802.896627648.08162014@webmail.messagingengine.com> Comments: In reply to Sebastian Gniazdowski "Cannot write to zsystem flock's descriptor" (Mar 1, 2:49am) References: <1488365385.3896802.896627648.08162014@webmail.messagingengine.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Sebastian Gniazdowski , zsh-workers@zsh.org Subject: Re: Cannot write to zsystem flock's descriptor MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 1, 2:49am, Sebastian Gniazdowski wrote: } } # echo "test" > file } # zsystem flock -t 0 -f MY_FD "file"; echo $? } 0 } # echo a>&${MY_FD} } zsh: 11: bad file descriptor This is actually internal to zsh and has nothing to do with the state of the descriptor itself. See addlockfd() in utils.c and lines 3524 to 3538 (approximately) in exec.c where the redirection is handled. When you do >&${MY_FD} that implies duplicating the descriptor to FD 1 of the "echo" job and then closing that descriptor when echo has finished. Doing so with the descriptor that is being held for flock could cause the lock to be prematurely released, so when the table of allocated descriptors is scanned for those that are valid as redirection targets, the FTD_FLOCK descriptors are skipped. I don't recall whether this is a portability issue -- e.g., it could safely be done on linux as the util-linux flock executable seems to imply, but perhaps it can't be done elsewhere. You can always open a different descriptor on the same file, or first open a descriptor on the file and then flock. Locking with flock is advisory only -- all programs accessing the file must agree to try flock first -- so there's no restriction on other access before or after flock is in place.