Date: Thu, 30 Mar 2000 09:58:29 -0800 From: Doug Barton <Doug@gorean.org> To: Sue Blake <sue@welearn.com.au> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Proposed new Bourne shell init files Message-ID: <38E395C5.DDBFCEB7@gorean.org> References: <38E2F801.548AAAF1@gorean.org> <20000330193658.V69444@welearn.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Sue Blake wrote:
>
> On Wed, Mar 29, 2000 at 10:45:21PM -0800, Doug Barton wrote:
>
> <many good comments and suggestions snipped>
>
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38E395C5.DDBFCEB7>