From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <6b5dcd845b37ef60c5063f852832aea0@vitanuova.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] multiple inputs From: rog@vitanuova.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-rbfuxponujdtqmquxiqcomcqio" Date: Tue, 30 Mar 2004 19:27:55 +0100 Topicbox-Message-UUID: 47ea11dc-eacd-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-rbfuxponujdtqmquxiqcomcqio Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > fn bt { > eval '{'for {tail -f $i &} '}' > } > > mimics how I would write it by hand. if that's all you need, then fn bt { for(i){tail -f $i&} } should be just fine. then bt > file might work (if file is append-only, otherwise you'd need a process (e.g. cat) in the middle to avoid overlapping writes) using eval is disastrous... consider what happens if you've got a filename with a shell metacharacter in it. --upas-rbfuxponujdtqmquxiqcomcqio Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by doppio; Tue Mar 30 19:20:50 BST 2004 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 56ECE19C2C; Tue, 30 Mar 2004 13:15:37 -0500 (EST) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 69E9719C57; Tue, 30 Mar 2004 13:15:31 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 4D6CD19E2A; Tue, 30 Mar 2004 13:14:05 -0500 (EST) Received: from smtp.med.unc.edu (ahoskie.med.unc.edu [152.19.4.48]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 9679419E0E for <9fans@cse.psu.edu>; Tue, 30 Mar 2004 13:14:03 -0500 (EST) Received: from 192.168.222.128 (d8k4c531.med.unc.edu [152.19.50.16]) by smtp.med.unc.edu (8.12.8p1/8.12.8) with ESMTP id i2UIE33q020586 for <9fans@cse.psu.edu>; Tue, 30 Mar 2004 13:14:03 -0500 (EST) Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] multiple inputs From: Noah Evans In-Reply-To: <19236d27e19c4ebbe4ba92e507e29149@vitanuova.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-xvmovnniftcvgeloqnuvadhuom" Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Tue, 30 Mar 2004 11:14:32 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psuvax1.cse.psu.edu X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Level: This is a multi-part message in MIME format. --upas-xvmovnniftcvgeloqnuvadhuom Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I'll agree with you there. The eval is unnecessary. But fn bt { eval '{'for {tail -f $i &} '}' } mimics how I would write it by hand. {tail -f file1 &; tail -f file2 &; tail -f file3 &}>file Which allows me to consider the command one block, which I can pipe to and from etc. The idiom that you and matt give doesn't work for pipes tail -f file1 &; tail -f file2 &; tail -f file3 >file only puts the text from file3 in the pipe. The for loop you gave obviates that problem, since it counts as a single block, but it's considerably different than my interactive shell usage and is more verbose(though much more readable :)). Noah --upas-xvmovnniftcvgeloqnuvadhuom Content-Type: message/rfc822 Content-Disposition: inline Return-path: <9fans-admin@cse.psu.edu> Received: from mpspam4.TIS.case.Edu (mpspam4.tis.case.Edu [129.22.104.191]) by ims-msg.cwru.edu (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPS id <0HVE00QRMDG31E@ims-msg.cwru.edu> for npe@cwru.edu; Tue, 30 Mar 2004 11:21:39 -0500 (EST) Received: (from localhost [127.0.0.1]) by mpspam4.TIS.case.Edu (MOS 3.4.4-GR) id AEE63078 (forwarded by mail filter of npe); Tue, 30 Mar 2004 11:21:38 -0500 (EST) Received: from mirapoint2.tis.cwru.edu (mirapoint2.TIS.CWRU.Edu [129.22.104.47]) by mpspam4.TIS.case.Edu (MOS 3.4.4-GR) with ESMTP id AEE63076; Tue, 30 Mar 2004 11:21:37 -0500 (EST) Received: from mail.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mirapoint2.tis.cwru.edu (MOS 3.4.3-CR) with ESMTP id ASJ57268; Tue, 30 Mar 2004 11:21:29 -0500 (EST) Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id B2DD519DE3; Tue, 30 Mar 2004 11:21:28 -0500 (EST) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id D58AB19AD7; Tue, 30 Mar 2004 11:21:26 -0500 (EST) Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id D764219E0E; Tue, 30 Mar 2004 11:20:05 -0500 (EST) Received: from rapido.vitanuova.com (unknown [62.254.170.97]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 2967619C1D for <9fans@cse.psu.edu>; Tue, 30 Mar 2004 11:20:04 -0500 (EST) Date: Tue, 30 Mar 2004 17:25:46 +0100 From: rog@vitanuova.com Subject: Re: [9fans] multiple inputs In-reply-to: Sender: 9fans-admin@cse.psu.edu To: 9fans@cse.psu.edu Errors-to: 9fans-admin@cse.psu.edu Reply-to: 9fans@cse.psu.edu Message-id: <19236d27e19c4ebbe4ba92e507e29149@vitanuova.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Precedence: bulk X-BeenThere: 9fans@cse.psu.edu Delivered-to: 9fans@cse.psu.edu X-Mirapoint-Loop-ID: cb554f7c7f0064cc56e600f872486f69 X-Original-To: 9fans@cse.psu.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psuvax1.cse.psu.edu X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.63 X-Junkmail-Status: score=5/45, host=mpspam4.TIS.case.Edu X-Mailman-Version: 2.0.11 List-Archive: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> Original-recipient: rfc822;npe@spamfree.cwru.edu > You need to put the brackets on the outside to make the combination of > tail -f's act like a single 'tail -f'. That was my real conceptual > misunderstanding the first time around. erm, i don't think so. {a & b &} should be exactly the same as a & b & you almost never need eval in rc, unless you genuinely want to evaluate an rc expression that's unknown beforehand (which isn't true in your case). you could have got the behaviour i think you were after with something like: fn bt { x=$1 shift for(i) {tail -f $i &} tail -f $x } --upas-xvmovnniftcvgeloqnuvadhuom-- --upas-rbfuxponujdtqmquxiqcomcqio--