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

[Stephane Chazelas <stephane.chazelas@xxxxxxxxx>]

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