noclobber overzealous with multios and /dev/stdout

noclobber overzealous with multios and /dev/stdout

[Mikael Magnusson]

I can't really see the logic here, so I'm guessing it's a bug somewhere:

zsh -f
% setopt clobber
% echo test > /dev/stdout > file
test
% echo test > /dev/stdout > file
test
% setopt noclobber
% echo test > /dev/stdout > file
zsh: file exists: file
% rm file
% echo test > /dev/stdout > file
test
% echo test > file > /dev/stdout
zsh: file exists: file
% rm file
% echo test > file > /dev/stdout
zsh: file exists: /dev/stdout


this is also pretty weird
% rm file
% echo test > file > /dev/fd/0
test
% rm file
% echo test > file > /dev/fd/1
zsh: file exists: /dev/fd/1

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

-- 
Mikael Magnusson

Re: noclobber overzealous with multios and /dev/stdout

[Bart Schaefer]

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.

-- 

Re: noclobber overzealous with multios and /dev/stdout

[Mikael Magnusson]

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

Re: noclobber overzealous with multios and /dev/stdout

[Bart Schaefer]

On Oct 5,  5:18pm, Mikael Magnusson wrote:
} Subject: Re: noclobber overzealous with multios and /dev/stdout
}
} On 5 October 2010 17:00, Bart Schaefer <schaefer@brasslantern.com> wrote:
} > ... 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".
} 
} > } 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?

Yes!

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

Exactly.

} What i was actually trying to do when i encountered this was use
} multios to write both to the terminal and a file.

You can do that, but you must always name the terminal device first,
or use a device such as /dev/tty that doesn't depend on stdin/stdout.
So

    echo test > /dev/stdout > file

should do what you want, or

    echo test > file > /dev/tty

if what you really mean is the terminal, rather than the previous
stdout.

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

That's what you have to do in the absence of multios, e.g. in /bin/sh
(except of course {myfd} doesn't work there, you have to pick a number).