Date: Thu, 30 Mar 2000 13:06:39 -0800 (PST) From: Doug Barton <Doug@gorean.org> To: Garance A Drosihn <drosih@rpi.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Proposed new Bourne shell init files Message-ID: <Pine.BSF.4.21.0003301257170.61776-100000@dt051n0b.san.rr.com> In-Reply-To: <v04210101b50957a5c962@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Mar 2000, Garance A Drosihn wrote:
> 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.
No argument there. I think it's more likely that they would
explicitly export something that they were adding themselves, but then
we're multiplying the ways that we can confuse 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.
I agree, which is why I explicitly disabled it. ATST, I don't
really think this is a big problem, but I'm starting to agree with you
that allexport introduces more problems than it solves.
> 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,
I briefly considered, then rejected that option. If we're going to
tie the connection between setting then exporting an environment variable
together then the two commands should be right next to each other. This
helps reduce the possibility that the user would add the command in one
place, but not the other. The exact problem I was trying to solve by using
allexport. If you have one long list of variables to export the danger is
that the list will get out of synch with the variables.
> 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.
Your response was well reasoned, and obviously comes from a
position of having some knowledge and experience with the subject. "I
don't understand this, so I don't like it." is not a valid argument in my
book.
I will submit a follow-up to my original message with the change
you suggested.
Thanks,
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?Pine.BSF.4.21.0003301257170.61776-100000>