Re: noclobber overzealous with multios and /dev/stdout

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxx> 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).