From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 1 22:28:34 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1AFBF1065698; Wed, 1 Sep 2010 22:28:34 +0000 (UTC) Date: Wed, 1 Sep 2010 22:28:34 +0000 From: Alexander Best To: Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= Message-ID: <20100901222834.GA66517@freebsd.org> References: <20100831180103.GA92584@freebsd.org> <86fwxt5ng1.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86fwxt5ng1.fsf@ds4.des.no> Cc: freebsd-hackers@freebsd.org Subject: Re: expand_number() for fetch'es -B and -S switches X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 22:28:34 -0000 On Wed Sep 1 10, Dag-Erling Smørgrav wrote: > Alexander Best writes: > > just having a quick look around to see, if anybody would be interested in > > fetch -B and fetch -S accepting humanized numbers using expand_number()? > > I can understand it for -B, but not for -S, since in the common case (by > 1023 to 1, assuming a random distribution) the argument to -S can not be > expressed in [kMGTEP]B. you're absolutely correct there. i didn't really think about it. i just thought -B might profit from expand_number() amnd saw that -S was also taking a byte value as argument so i added it to my previous mail. i should have read the description for -S more carefully. ;) since you're the originator of fetch(1): should i send you a patch to add expand_numer() to the -B switch or do you think fetch is better off as it is now without humanised numbers? i'm not sure, but i think fetch(1) is BSD specific so no POSIX regulations need to be taken into consideration. but you probably know more about this matter. cheers. alex > > DES > -- > Dag-Erling Smørgrav - des@des.no -- a13x