From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.edu with SMTP id <2683>; Wed, 6 Oct 1993 04:48:27 -0400
Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3)
	id AA29158; Wed, 6 Oct 1993 03:48:22 -0500
Message-Id: <9310060848.AA29158@oldp.astro.wisc.edu>
To:	byron@netapp.com (Byron Rakitzis), rc@hawkwind.utcs.toronto.edu
Subject: Re: ifs 
Date:	Wed, 6 Oct 1993 04:48:22 -0400
From:	Alan Watson <alan@oldp.astro.wisc.edu>
X-Mts: smtp

Yes, this all hangs on whether one sees ifs as a per shell or per
environment property.  It depends on whether you expect:

	rc -c $cmd

to be (roughly) identical to:

	@ eval $cmd

or not.  (Yes, I know about the magic $pid variable, but its odd
behaviour is dictated by reasons firmly rooted in pragmatism.)  I tend
to think that the current behaviour is wrong, and would like you to
reconsider this.  If you still feel it's right, please add something to
the man page.

I'm not entirely convinced by the trojan horse argument -- is certainly
doesn't exist to the same degree than it did in sh.  By your argument,
why not disable the export of functions to save people from using
builtin to prevent trojan horse commands?  

I'm more in favour of flexibility.  I tend towards prefering to allow
the programmer to explicitly over-ride functions and ifs (by using
builtin and setting ifs) or to inherit the user's preference from the
environment.  We are all used to setting path and using builtin, why is
setting ifs so different?

Besides, I wouldn't trust Paul's view -- he's on record as being
prejudiced against innocent state variables. :-)