X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Date: Tue, 17 Feb 2009 13:11:00 -0600 (CST) From: Tim McDaniel To: cygwin AT cygwin DOT com Subject: Re: subshell redirection (/dev/fd/x) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Tue, 17 Feb 2009, Brian Ford wrote: > $ uname -a > CYGWIN_NT-5.1 PC1163-8460A-XP 1.7.0(0.193/5/3) 2009-02-09 22:27 i686 > Cygwin > > Just curious if the following is known behavior? > > $ echo a | tee >(wc) > a > tee: /dev/fd/63: Bad file descriptor > > $ 0 0 0 The bash term is "Process Substitution". I had the dim impression that there was a Windows misfeature that prevented >(...) from working. Anyway, thanks for reminding me about what I got onto the list to complain about. I think that, out of the box, <(...) doesn't work under Cygwin. We had to do ln -s /proc/self/fd /dev/fd (We got there after we deleted all of Cygwin's directories and reinstalled. Apparently we'd set up that symlink before: <(...) worked before the reinstall, but didn't work afterwards until we did the symlink above.) The bash manual says, by the way, Process substitution is supported on systems that support named pipes (FIFOs) or the /dev/fd method of naming open files. -- Tim McDaniel, tmcd AT panix DOT com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/