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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.  

">*" is multio syntax, and if you add ksh globbing, ">@" is ambiguous.

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.

Therefore the sysopen suggestion is probably the most appropriate one.

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

All of this would simply be ignored in environments where it could not
be supported, which is why I think an explicit sysopen that could fail
with well-defined error conditions is preferable.