From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3501 invoked from network); 6 Jun 2020 15:25:15 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 6 Jun 2020 15:25:15 -0000 Received: (qmail 360 invoked by alias); 6 Jun 2020 15:25:07 -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: List-Unsubscribe: X-Seq: 46009 Received: (qmail 27178 invoked by uid 1010); 6 Jun 2020 15:25:07 -0000 X-Qmail-Scanner-Diagnostics: from mail-ot1-f43.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25828. spamassassin: 3.4.4. Clear:RC:0(209.85.210.43):SA:0(-1.9/5.0):. Processed in 3.234813 secs); 06 Jun 2020 15:25:07 -0000 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.210.43 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r3fJtDSY+xM6n39uRmthyiXkjsSvAqT3FakitO33yGU=; b=kA4NV1IQsGq/7R5eiansRUVm5j1rqCBQct2chhAc/RBv5+iBbgpJrneNbbJ3CYMzTf H7hxA5gg+bfmTUOx0g5sLxks0AUEML3pZOJkzCwJBNH4nkDuOoVsJ6nLCBb3kafIqobI EuvKYjLP6UJJZp9M/Mg1t6WdfTtfTyJMWU2yYk52wiPIRoARcJl8QlXsDoqemzf3cU63 GAP8qYICLq0j36Ob44JWMC1xkMye7fwLXesHjrSPLHWJCL5lp9uD40iGExB2+sit50Yo E8CLgAVWyaMLqDNf/wX+SA2tsriQbdtw3Ex9VhxWkxF2N/6J4rtud5n9zWPS7nuXBWFV lkrQ== X-Gm-Message-State: AOAM532kKE94cCDyjwwrRKs8iIP5pm92cuvqcsGh5B15ecyllFzZphNU kp6MV2KyfqrtsgaNsEH6rlnVqIH36cni8Qhv4l9ygQ== X-Google-Smtp-Source: ABdhPJwlK5VjgVks9Rm8LBN5kPmeDqRhcJFZcULzSsFlP/J3ttjFzpxynMLCdsFQUqoRjvuCYcduyNur0pRQVNtdzSI= X-Received: by 2002:a9d:6c4e:: with SMTP id g14mr8433518otq.229.1591457071824; Sat, 06 Jun 2020 08:24:31 -0700 (PDT) MIME-Version: 1.0 References: <89aed74d-db7b-47ad-b218-8158838049e9@www.fastmail.com> <94e73ebcf39d4d3f9c7ae257b1d75d16@CAMSVWEXC01.scsc.local> <20200605020748.635b9bb3@tarpaulin.shahaf.local2> <1941572212.466119.1591360860372@mail2.virginmedia.com> <13acd486e6457c1f708304026c3e1b59521ad328.camel@ntlworld.com> In-Reply-To: From: Bart Schaefer Date: Sat, 6 Jun 2020 08:24:20 -0700 Message-ID: Subject: Re: Any way to allow clobbering empty files when noclobber is set? To: Roman Perepelitsa Cc: Peter Stephenson , Zsh hackers list Content-Type: text/plain; charset="UTF-8" On Sat, Jun 6, 2020 at 5:49 AM Roman Perepelitsa wrote: > > Having unspecified file content that is the result of interleaved > writes seems pretty bad. > > [... code example ...] > > This output implies that one command has overwritten the output of > another and the user has received no indication to this effect. This returns to my point that this isn't the intended use case for either NO_CLOBBER or CLOBBER_EMPTY. That code example always yields unspecified file contents in a POSIX shell if the empty file already exists and is writable (the only case you couldn't have is the file empty at the end). If you're going to use zsh + noclobber for concurrent programming, then the implementation of clobberempty is entirely irrelevant, because your correct program won't use it. If you're attempting to use zsh + noclobber defensively, that won't work either because any other process not written in zsh won't pay attention to it. Consequently we should be looking at this as an entirely interactive user DWIM feature, and choosing how to implement (or not to) based on that.