From owner-freebsd-current@FreeBSD.ORG Mon May 3 23:12:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E04516A4CE; Mon, 3 May 2004 23:12:01 -0700 (PDT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9713643D46; Mon, 3 May 2004 23:12:00 -0700 (PDT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cs1.cs.huji.ac.il with esmtp id 1BKt9q-000C9T-Ja; Tue, 04 May 2004 09:11:58 +0300 X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: John Baldwin In-reply-to: Your message of Mon, 3 May 2004 14:59:36 -0400 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 May 2004 09:11:58 +0300 From: Danny Braniss Message-Id: <20040504061200.9713643D46@mx1.FreeBSD.org> cc: freebsd-current@FreeBSD.org Subject: Re: kenv enhancement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 06:12:01 -0000 > On Saturday 01 May 2004 08:22 am, Danny Braniss wrote: > > Hi, > > I propose to bring back some lost options to kenv, -c and -s > > ie, > > kenv -c class [-s] > > so that > > kenv -h is equivalent to kenv -c hint. > > and > > kenv -c boot.nfsroot. -s > > gives: > > nfshandle="X9ca48b3f5b77454e0c00000002000000bfa3063100000000000000000000000 > >0X" path="/d/6" > > server="132.65.16.100" > > > > the 'enhanced' kenv is in > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/kenv/ > > > > danny > > I rototilled this a bit to make it use the existing style. I also renamed > 'class' to prefix since you can do things like 'kenv -p kern -s' to get > interesting output like: > > el="kernel" > el_options="" > elname="/boot/kernel/kernel" > > :-P > > One thing to note is that 'kenv -p foo' is basically the same as > 'kenv | grep ^foo', and that 'kenv -p foo -s' is basically the same as > 'kenv | sed -ne '/^foo/{s///;p;}'. Generally new options aren't added to > programs if they can be easily duplicated via a simple pipeline. Is there a > reason that you need kenv to do this explicitly rather than using sed or > grep? We use it very early in the boot process - rc.d/initdiskless, and /usr might not be mounted - not true in my particular case though. BTW, the flags I used are the same that once were in kenv and somewhere down the road were removed. danny