From owner-freebsd-questions@FreeBSD.ORG Wed Apr 6 13:45:19 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5020516A4CF for ; Wed, 6 Apr 2005 13:45:19 +0000 (GMT) Received: from dc.cis.okstate.edu (dc.cis.okstate.edu [139.78.100.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0121B43D2D for ; Wed, 6 Apr 2005 13:45:19 +0000 (GMT) (envelope-from martin@dc.cis.okstate.edu) Received: from dc.cis.okstate.edu (localhost.cis.okstate.edu [127.0.0.1]) by dc.cis.okstate.edu (8.12.6/8.12.6) with ESMTP id j36DjIY5035139 for ; Wed, 6 Apr 2005 08:45:18 -0500 (CDT) (envelope-from martin@dc.cis.okstate.edu) Message-Id: <200504061345.j36DjIY5035139@dc.cis.okstate.edu> To: freebsd-questions@freebsd.org Date: Wed, 06 Apr 2005 08:45:18 -0500 From: Martin McCormick Subject: Re: Bourn Shell Scripts that Produce Multiple Files X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2005 13:45:19 -0000 Mario Hoerich writes: >This sounds a bit like a truncation issue. > >If you do something like > > command1 > bar > # some code > command2 > bar > >then the second redirect will truncate the file to 0 bytes >before redirecting the output from command2 into it. Yes. My code was very similar to what you describe only more like: command1 > bar #some code command2 > bar2 #should leave bar alone and open bar2 #Instead, bar and bar2 both end up empty of anything. >Try using >> instead of >, as it appends to the file. What's sad is, I think I tried that but forgot to remove some older versions of the same files created by a less elegant method so it looked like the new files had too many lines in them and I figured that appending didn't work either. I should have cleaned house first and things would have been fine. Appending did solve the problem. >If this doesn't help, please post the script (or a simplified >version thereof). We're not clairvoyant, you know... :) Here is the simplified origin of the problem: #! /bin/sh searchfor () { #line of awk that produces standard output return 0 } while read currentnumber; do #This line does work according to your suggestion. searchfor >>$currentnumber.txt #This line was what I had which opens new files but never fills them: #searchfor >$currentnumber.txt done <~/numbers The value held in $currentnumber.txt changes with each loop iteration so we should be writing to bar2, bar3, etc and leaving bar1 alone. It apparently does not work that way. It reminds me of what happens in C if a program ends without closing an open file for whatever reason. The buffer never gets emptied so the file is left either empty or partially filled depending upon luck and how much data got written to the disk before the abnormal end. My short-term problem is solved so thanks again, but it appears that even opening new files without appending them confuses the shell on previously-opened files such that you do not receive any data in any of the files. Martin McCormick WB5AGZ Stillwater, OK OSU Information Technology Division Network Operations Group