Re: noclobber overzealous with multios and /dev/stdout

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 4, 11:32pm, Mikael Magnusson wrote:
}
} I can't really see the logic here, so I'm guessing it's a bug somewhere:

This is not really a zsh issue; it depends on the implementation of the
device special files that refer to existing descriptors.

Internally zsh always does these steps:
(1) Attempt to open the file for exclusive write.
    [If this succeeds, we're done, the file didn't exist before.]
(2) Open the file for write, but without truncation, then fstat the
    descriptor and close/fail if a regular file.

The special files /dev/stdout and /dev/fd/1 etc. are oddballs in that
they may appear to be (or not) a regular file depending on how the
related descriptors were previously opened.

So in these two cases ...
 
} % rm file
} % echo test > file > /dev/stdout
} zsh: file exists: /dev/stdout
} 
} % rm file
} % echo test > file > /dev/fd/1
} zsh: file exists: /dev/fd/1

... what has happened is that zsh has opened "file" as the standard
output (fd 1), which changes the meaning of /dev/stdout and /dev/fd/1
to refer to the regular file "file".  This is in turn causes noclobber
to refuse to truncate them; zsh has no way of knowing that the OS has
magically created a new reference to a file that zsh itself created
only a fraction of a second before, it knows only that it may not
truncate an existing file.

} both 0 and 1 are symlinks to /dev/pts/33

No, they aren't.  Left-to-right order is important with multios, as
it is with descriptor duplication using >&DIGITS.

--