* noclobber overzealous with multios and /dev/stdout @ 2010-10-04 21:32 Mikael Magnusson 2010-10-05 15:00 ` Bart Schaefer 0 siblings, 1 reply; 4+ messages in thread From: Mikael Magnusson @ 2010-10-04 21:32 UTC (permalink / raw) To: zsh workers 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: noclobber overzealous with multios and /dev/stdout 2010-10-04 21:32 noclobber overzealous with multios and /dev/stdout Mikael Magnusson @ 2010-10-05 15:00 ` Bart Schaefer 2010-10-05 15:18 ` Mikael Magnusson 0 siblings, 1 reply; 4+ messages in thread From: Bart Schaefer @ 2010-10-05 15:00 UTC (permalink / raw) To: zsh workers 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. -- ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: noclobber overzealous with multios and /dev/stdout 2010-10-05 15:00 ` Bart Schaefer @ 2010-10-05 15:18 ` Mikael Magnusson 2010-10-05 16:16 ` Bart Schaefer 0 siblings, 1 reply; 4+ messages in thread From: Mikael Magnusson @ 2010-10-05 15:18 UTC (permalink / raw) To: zsh workers 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: noclobber overzealous with multios and /dev/stdout 2010-10-05 15:18 ` Mikael Magnusson @ 2010-10-05 16:16 ` Bart Schaefer 0 siblings, 0 replies; 4+ messages in thread From: Bart Schaefer @ 2010-10-05 16:16 UTC (permalink / raw) To: zsh workers 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). ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-10-05 16:16 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-10-04 21:32 noclobber overzealous with multios and /dev/stdout Mikael Magnusson 2010-10-05 15:00 ` Bart Schaefer 2010-10-05 15:18 ` Mikael Magnusson 2010-10-05 16:16 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).