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

[Stephane Chazelas <stephane.chazelas@gmail.com>]

2015-06-28 11:38:14 -0700, Bart Schaefer:
> On Jun 28,  3:00pm, Stephane Chazelas wrote:
> }
> } 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.
> 
> "<>" already means open r/w, and "<flags>" is syntactically ambiguous
> with redirecting input from the file named flags followed by redirecting
> output.  
[...]

Oh yes sorry, I mentionned the conflict with process
substitution (diff <(cmd)> output) in my earlier post, because
I had initially (when I first had that idea of a generic
redirection operator a few months ago and which this thread
reminded me of) thought of: <(flags)>. Another alternative could
be <{flags}>. I like <(flags)> because it's consistent with
${(flags)var}, ${var[(flags)x]}, *glob*(flags)

[...]
> Let me remind everyone that redirection operators were designed as a
> front-end on stdio, e.g. fopen(3) and friends, and not on open(2) and
> similar OS-level calls.  fopen(3) doesn't interface to the full suite
> of flags supported by open(2).  Throw in all this additional detail and
> you are effectively preventing the shell implementation from using the
> stdio library, which could limit portability.
[...]

I'm not sure what you mean here. Surely the shell only opens
files on file descriptors (stdio having no exposed notion of
file descriptors) and then runs applications that may or may not
use stdio but that's independent from the shell. The Bourne
shell never used stdio. And a shell can't buffer its (limited)
output since it mostly runs external commands.

> Therefore the sysopen suggestion is probably the most appropriate one.

Yes, I like that one too and the idea of having a low-level
interface to all the file-related system calls.

> The next-best idea I can think of offhand would be to have a variable
> that behaves like the umask does for file permissions, except that it
> applies to the file opening mode instead.  You could tweak this in
> the list of variables that prefix the command, e.g.,
> 
>     OPENMODE=04600 cat < $file
> 
> There could be a builtin command to translate symbolic names into the
> bits for OPENMODE e.g.
> 
>     OPENMODE=$(openmode O_EXCL O_NOCTTY O_NONBLOCK) cat < $file
> 
> Or I suppose this could all be done as a pre-command modifier:
> 
>     openmode O_EXCL,O_NOCTTY,O_NONBLOCK cat < $file

Except that that would mean all redirections would get the same
flags. The idea with a generic redirection operator is that it
could combine different O_RDONLY, O_RDWR, O_APPEND... flag
combinations (and the extra O_DIRECTORY, O_SYNC, O_EXCL) and
also deal with openat, lseek, and potentially more to come
later.

One thing I like with zsh is that it provides with alternatives
to the glob option settings (like $~var (for globsubst), *(N)
(for nullglob)). Having a way to avoid having to use "set -C" on
a per redirection basis appeals to me like in:

cmd 1<(we)> out 2>> /var/log/my.log

(noclobber for out, normal append with O_CREAT for my.log).

-- 
Stephane