From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2471 invoked by alias); 28 Jun 2015 14:05:17 -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: 35653 Received: (qmail 2909 invoked from network); 28 Jun 2015 14:05:15 -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 15:00:50 +0100 Message-ID: <20150628140050.GA10570@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> <20150628074837.GB4818@chaz.gmail.com> <16434.1435482953@thecus.kiddle.eu> 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: <16434.1435482953@thecus.kiddle.eu> User-Agent: Mutt/1.5.21 (2010-09-15) 2015-06-28 11:15:53 +0200, Oliver Kiddle: [...] > I'm not so bothered about the name but perhaps a CSH_ prefix on it would > make sense. Agreed. > > > 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 > > O_NOFOLLOW is fairly easily emulated, either with a condition or, if you > really want succinct, a glob qualifier: > file(^@) Well, the idea with O_NOFOLLOW is that it's race free. Also open("a/b/c", O_NOFOLLOW) guarantees the whole path is symlink free (none of "a", "a/b", "a/b/c" are symlinks or the open fails). The idea being to use those in non-trusted areas (world writable dirs etc) to process files created by others. To be fully usable, cd would probably need a similar option and some frontend to cdat() openat() would be needed as well. > But for other flags like O_CLOEXEC or O_SYNC, you can't do much. > We'd also have to worry about how portable each of the open flags are. Yes. > New syntax has additional costs such as making scripts less readable. An > alternative would be to add a sysopen builtin to the zsh/system module. > Or perhaps a -o option to exec, e.g. exec -o nofollow 3>file Yes, that would work as well, though would make it more cumbersome to use like: (sysopen -o O_SYNC,O_WRONLY,O_CREAT -d 3 -- "$file" && cmd >&3) instead of cat 1 "$file" (but such a need is probably rare enough that it would not be a concern). I'd have thought a <(flags)> operator would have appealed to zsh developers/users as it's similar to things like the parameter expansion or globbing flags: while other shells have various operators of different shape and behaviour nesting or not in non obvious ways, zsh has a clear, consistent, extensible ${(flags)var} API. That's very similar with redirection operators. Some shells like ksh93 have a plethora of different operators. We could for instance add a >@ for O_NOFOLLOW, >* for O_CLOEXEC... etc, but it becomes unclear how they can be combined, while <(flags)> would make it neater. > > That could even be extended to do lseeks(), dups(), (3<(>+20)> > > to lseek(3, 20, SEEK_CUR))... > > Recent ksh has <#((offset)) and <##pattern for seeking. > Along with (( fd<# )) to get the current position. > I'm not sure how useful that would really be, especially as byte offsets > are less meaningful when you have multibyte encodings. [...] Yes, a few examples of usage of <#(()): https://unix.stackexchange.com/a/180039 https://unix.stackexchange.com/a/209648 https://unix.stackexchange.com/a/70718 https://unix.stackexchange.com/a/177652 Having a way to tell the current position (like that ((fd<#)) would be necessary to be able to seek back to a previous position. Again, I'd agree a sysseek and systell would work as well and probably be enough. ksh93's builtin head command has a -s option for that. -- Stephane