From owner-freebsd-current@FreeBSD.ORG Tue May 4 23:00:55 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 C6EAF16A4CE; Tue, 4 May 2004 23:00:55 -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 5F5F243D41; Tue, 4 May 2004 23:00:55 -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 1BLFSf-000Kn1-Hl; Wed, 05 May 2004 09:00:53 +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 Tue, 4 May 2004 15:28:47 -0400 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 May 2004 09:00:53 +0300 From: Danny Braniss Message-Id: <20040505060055.5F5F243D41@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: Wed, 05 May 2004 06:00:55 -0000 > On Tuesday 04 May 2004 02:11 am, Danny Braniss wrote: > > > 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="X9ca48b3f5b77454e0c00000002000000bfa306310000000000000000000 > > > >0000 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. > > Do you know when they were in kenv? Those flags don't appear in any of the > versions in CVS and, it is actually a fairly recent program: > > ---------------------------- > revision 1.1 > date: 2000/07/08 08:33:40; author: peter; state: Exp; > branches: 1.1.2; > Initial kenv(1) hack for dumping the kernel environment. This can be > used to extract modified boot hints to make loader(8)-time changes > "sticky". It tries to use \ style quoting so that it can be used directly > with foo.conf files. It can also extract specific variables. > ---------------------------- > sorry, all i remember is that it was short lived. danny