Re: '>>' does not create file if set -C (noclobber) is active

[Stephane Chazelas <stephane.chazelas@xxxxxxxxx>]

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<ws> "$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