Re: noclobber overzealous with multios and /dev/stdout

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 5 October 2010 17:00, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> 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.

Ah, this is sort of half magical stuff, thanks for explaining  :).

> } 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.

In case this was unclear, i was referring to /proc/<pid>/fd/0 and 1
there, they are both symlinks pointing to the same target
(/dev/pts/33). When i created a symlink in the current dir to the same
place, i also didn't get the error. Oh, i just realized now, does what
the symlink in /proc points to change during the evaluation of the
redirect operators? I guess they must, in that case i understand what
happens :). Ie after "> file", /proc/self/fd/1 points to "file", while
0 still points to the terminal...

What i was actually trying to do when i encountered this was use
multios to write both to the terminal and a file. I guess what i must
do in that case is first duplicate stdout to a new fd with {myfd}>&1
(i always forget the exact syntax for this), and then > file >&$myfd ?
This came up in the irc channel, someone wanted to redirect stdout to
one place, and stderr both to a file and stdout, or something like
that. (I can probably figure out the exact command on my own if he
returns).

-- 
Mikael Magnusson