From owner-freebsd-hackers Thu Mar 30 9:58:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11]) by hub.freebsd.org (Postfix) with ESMTP id 8DD0437B738 for ; Thu, 30 Mar 2000 09:58:47 -0800 (PST) (envelope-from Doug@gorean.org) Received: from gorean.org (doug@master [10.0.0.2]) by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id JAA60087; Thu, 30 Mar 2000 09:58:29 -0800 (PST) (envelope-from Doug@gorean.org) Message-ID: <38E395C5.DDBFCEB7@gorean.org> Date: Thu, 30 Mar 2000 09:58:29 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0325 i386) X-Accept-Language: en MIME-Version: 1.0 To: Sue Blake Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Proposed new Bourne shell init files References: <38E2F801.548AAAF1@gorean.org> <20000330193658.V69444@welearn.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sue Blake wrote: > > On Wed, Mar 29, 2000 at 10:45:21PM -0800, Doug Barton wrote: > > > > > Commentary on my files. . . Using allexport instead of an explicit > > 'export' for every variable makes the file easier to read, and gives a > > novice user one less thing to worry about. > > I see your point, and offer an alternative view. > > I don't consider myself a novice user, but when I was I'd heard of > export, yet I've still not heard of allexport until your email. > (OK, I probably read about it and ignored it). > > My fear would be that turning something on in one part of the file and > off again later is likely to assist novices to shoot themselves in the > foot by removing only one of these lines. Actually it's much more likely that a novice user would fail to export a variable, which would result in it not working at all. The other alternatives are fairly harmless. First the user doesn't see/understand the allexport lines, and exports their variables explicitly anyway. They work. The user deletes the line that turns allexport off. Everything still works, and they have a few too many harmless shell settings exported into their environment. The user deletes the line that turns allexport on. Nothing works, the user goes and looks again at the file. Hopefully they see the line that turns it off, and figure it out. Or, maybe they see that the variables aren't exported, know how to export them, and does so. The number of possible outcomes where this fails to work are actually really small, compared to the large number of outcomes where it works. > In one sense it simplifies, > but it does so by making the file's structure more complex. You can't possibly support the argument that it's more complex. How can this: allexport on var1=foo var2=bar var3=baz var4=bic var5=schick allexport off Be more complex than: var1=foo export var1 var2=bar export var2 var3=baz export var3 var4=bic export var4 var5=schick export var5 > Not too > much so, but avoidable. The multiple exports take up more space and > don't look as clever, but their purpose is crystal clear and one goof > doesn't ruin the lot of them. I've addressed the "one goof" issue above. This isn't a matter of "looking clever," rather it's a matter of reducing the number of ways the user can shoot themselves in the foot, and to make the variables being set stand out more clearly. > It would be a good addition to a separate file with lengthy comments, > supplied as an alternative and/or learning exercise. Actually I added the comments I did to the file (in more places than just the allexport lines) to help make things more clear. If you feel that more verbose comments are warranted, I'm sure we would all welcome your suggestions. But shooting down a simple solution that solves several problems at the same time and has little or no down side just because you don't understand it isn't really constructive criticism. Doug -- "So, the cows were part of a dream that dreamed itself into existence? Is that possible?" asked the student incredulously. The master simply replied, "Mu." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message