> > > Doesn't this suppress a diagnostic that is likely to be valuable to > anyone who > > accidentally runs an affected tool from a context with closed standard > output? > Yes it's not ideal. > Also it doesn't map directly to closed stdout. > If we were to support it then --no-stdout would probably be best. > That would allow symmetric use of processing substitutions also. > i.e. tee --no-stdout >(cmd1) >(cmd2) > rather than the slightly awkward: tee --no-stdout >(cmd1) | cmd2
This is exactly my point of view as well. If we want to support it we should do this right. I consider both >&- and >/dev/full as workarounds. I think that --no-stdout is the best solution for this. Jirka On Fri, Nov 20, 2015 at 7:08 PM, Eric Blake <ebl...@redhat.com> wrote: > On 11/20/2015 10:38 AM, Bernhard Voelker wrote: > > On 11/20/2015 01:08 PM, Pádraig Brady wrote: > >> + tee no longer diagnoses write errors to a closed standard output, as > this > >> + can be useful when further piping the output from process > substitutions. > > > > I'm not sure this is allowed by POSIX, > > POSIX says you are non-conforming the moment you start an application > with fd 0, 1, or 2 closed, and that all bets are off (so we can do > whatever we think makes the most sense, but if it is more than just tee > with stdout closed we may be aggravating the problem). > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > >
