* 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).