From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20173 invoked by alias); 28 Jun 2015 07:50:28 -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: 35651 Received: (qmail 20171 invoked from network); 28 Jun 2015 07:50:24 -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=1.0 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,FSL_HELO_BARE_IP_2,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW, RCVD_NUMERIC_HELO,SPF_HELO_PASS autolearn=no autolearn_force=no version=3.4.0 X-Injected-Via-Gmane: http://gmane.org/ To: zsh-workers@zsh.org From: Stephane Chazelas Subject: Re: '>>' does not create file if set -C (noclobber) is active Date: Sun, 28 Jun 2015 08:48:37 +0100 Message-ID: <20150628074837.GB4818@chaz.gmail.com> References: <558B5342.2090706@inlv.org> <150624184916.ZM19079@torch.brasslantern.com> <558B65EB.3060204@inlv.org> <150625003047.ZM19218@torch.brasslantern.com> <558D5E34.3020505@inlv.org> <20150627180230.5fda7e09@ntlworld.com> <558F397D.9030708@inlv.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 2.217.126.102 Content-Disposition: inline In-Reply-To: <558F397D.9030708@inlv.org> User-Agent: Mutt/1.5.21 (2010-09-15) 2015-06-28 02:02:05 +0200, Martijn Dekker: [...] > At the risk of pedantry, I also wonder if 'createappend' or > 'appendcreate' would be a better name, since "clobbering" is commonly > understood to mean overwriting pre-existing files, not creating new ones. [...] Agreed, I also wonder of the rationale behind that feature. For zsh, I understand it copied it from csh, but why would "noclobber" prevent >> from creating files, that has nothing to do with clobbering. In 18 years of using zsh and tcsh before that I had never realised they were doing that and when you reported it, I pretty much assumed it was a bug and was very surprised when it revealed to be a feature. I agree it's a potentially useful feature to prevent >> from creating files, but it shouldn't be done upon a "noclobber" option as it's the opposite meaning that noclobber conveys. BTW, slightly related, I think it would be nice for the shell to have access to some of the other open() flags. I often found myself wishing I could use O_NOFOLLOW for instance. How about a <(flags)> operator where flags is flag[flag...] and flag being [+] or - followed by a one-letter flag (like r, w, a, @ (for follow)..., some of which on by default). So >> would be <(a)> (a implies -r+w, +w implies +c (create)). You'd use: <(w-@)> for no-follow... And we could implement that noclobber on >> with <(a-c)>. That could even be extended to do lseeks(), dups(), (3<(>+20)> to lseek(3, 20, SEEK_CUR))... What do you think? Yes, with that <(..)> syntax there's a slight risk of breaking scripts that do: diff <(cmd1) <(cmd2)> out.txt -- Stephane