On 2/11/10 6:04 AM, Ian wrote:
> Basically, by mixing IO redirection and process substitution I'm left
> with a trailing file descriptor which can cause scripts to hang around
> despite any subsequent redirection of stdout/stderr best practices.
> There's no mechanism to discover these new file d
On 11 Feb, 20:29, Greg Wooledge wrote:
> When the shortcuts are too short, you need to fall back to the original
> tools. In this case, >() is really just a shortcut for "create a FIFO,
> and open it". Doing so by hand should give you the manual control you
> need. At the very least, you can te
Ian wrote:
> The manual suggests I could move and close file descriptors with
>
> [n]>&digit-
>
> but I would need the equivalent of
>
> command1 >&>(...)-
>
> Digit might very well mean (just a) digit but here the process
> substitution, of course, is replaced with /dev/fd/63, say, certai
On Thu, Feb 11, 2010 at 03:04:30AM -0800, Ian wrote:
> The manual suggests I could move and close file descriptors with
>
> [n]>&digit-
>
> but I would need the equivalent of
>
> command1 >&>(...)-
>
> Digit might very well mean (just a) digit but here the process
> substitution, of course
Hi,
I'm not so sure this is a bug rather than a feature but it has
undesirable behaviour to my eye. I found it originally in 3.0.16 but
I've just reproduced it in 4.1.
If I have a script where I use process substitution to log the output
yet keep stdout and stderr as they stand:
command1 > >(
