Date: Thu, 30 Mar 2000 14:42:26 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Doug Barton <Doug@gorean.org>, Sue Blake <sue@welearn.com.au> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Proposed new Bourne shell init files Message-ID: <v04210101b50957a5c962@[128.113.24.47]> In-Reply-To: <38E395C5.DDBFCEB7@gorean.org> References: <38E2F801.548AAAF1@gorean.org> <20000330193658.V69444@welearn.com.au> <38E395C5.DDBFCEB7@gorean.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 9:58 AM -0800 3/30/00, Doug Barton wrote:
>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.
> >
> > 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.
If the novice user is writing their own script, then they need to
understand exporting variables.
>The other alternatives are fairly harmless. First the user doesn't
>see/understand the allexport lines, and exports their variables
>explicitly anyway. They work.
...and setting allexport has not helped them.
>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.
This is where I'd disagree. Some scripts define variables that they
really do not expect to be exported. Exporting those variables is
not always "harmless", and (speaking from experience) can be quite
confusing to track down. This is particularly true when a user is
dealing with scripts that they did not write.
> > 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.
It is more complex in the sense that the user has to realize that
"allexport" is changing a basic shell behavior. If a person does
not realize the connection between:
var1=foo
export var1
then how is it "more obvious" to them what is happening with:
allexport on
var1=foo
allexport off
The first one is explicitly stating what it's doing, whether or
not the user understands the significance of "export". If you
don't understand the significance of "export", then you're
certainly not going to understand what "allexport" is there for.
This is probably a matter of personal opinion, but then you did
ask for people's opinions... :-)
> > 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.
Again, as you were asking for opinions, I'd say that using "allexport"
does nothing to reduce the number of ways the user can shoot themselves
in the foot.
It does reduce the clutter somewhat, but I would rather have the
explicit 'export's than the reduced clutter. Another way to reduce
clutter would be to export all the variables at once, at the end,
but I am not overly fond of that idea either. (even if that is what
I do for some of my scripts, I wouldn't put that in a default script
for all users...).
> > 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.
The fact that *you* THINK it has no downside does not mean everyone
will agree that it has no downside. If someone thinks there is a
downside, then it is definitely constructive criticism for them
to say so. You can't very well ask for opinions and then dismiss
opinions as "not really constructive" just because they do not agree
with some basic premise of your position.
(I'm not really sure if your above paragraph refers to "allexport",
or if it refers to the suggestion of a separate file with lengthy
comments. In either case it seems very odd that you explicitly asked
for comments, someone wrote up some perfectly reasonable comments,
and you react by saying the person "don't understand it" and thus
their comments aren't "really constructive criticism". Very odd)
---
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or drosih@rpi.edu
Rensselaer Polytechnic Institute
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?v04210101b50957a5c962>