Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Subject: Re: Beginnings of a patch: /etc/hosts
From: Robert Collins <rbcollins AT cygwin DOT com>
To: cygwin AT cygwin DOT com
In-Reply-To: <Pine.GSO.4.44.0209112003300.1269-100000@slinky.cs.nyu.edu>
References: <Pine DOT GSO DOT 4 DOT 44 DOT 0209112003300 DOT 1269-100000 AT slinky DOT cs DOT nyu DOT edu>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature";
	boundary="=-ea8EWY622UVO3CzXd1Fw"
Date: 12 Sep 2002 16:49:41 +1000
Message-Id: <1031813381.22459.132.camel@lifelesswks>
Mime-Version: 1.0

--=-ea8EWY622UVO3CzXd1Fw
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-09-12 at 10:10, Igor Pechtchanski wrote:

> > Rule #1: The user knows better than the tool. If the user wants to fool
> > the script, they can, even with uname. If a user is doing that, assume
> > they have a reason and let them do it with grace.
> >
> > Rob
>=20
> True.  Hey, I'm a control freak myself...  I was not speaking against
> "fooling the script", I was just making an observation.  However, the
> issue here is not the intentional "fooling" that you describe, but
> unintentional.  It's much harder to do that with 'uname -s' than with an
> environment variable.

Ok, I mis-interpreted your intention.
=20
> Besides, why would anyone want to fool a post-install script?
> Mmm, I guess I could think of a few reasons, but then shouldn't all
> post-install scripts be susceptible to fooling in the same way, i.e.,
> "with grace"?  Should this be documented somewhere?

I wasn't suggesting they *should* or *should not* be foolable. I was
really trying to say that the design should not be based on whether or
not a user can *intentionally* override something - because one way or
another the user can. The design should be whatever is:
* easy to maintain
* robust in the face of usual and common-unusual conditions.

Rob

--=-ea8EWY622UVO3CzXd1Fw
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9gDkEI5+kQ8LJcoIRAkshAKCwT8CJRTbGF4mv7l9HZZMnhhknCwCfR/eY
742c1yFeBiecCrcLZ1VA7dI=
=Q70b
-----END PGP SIGNATURE-----

--=-ea8EWY622UVO3CzXd1Fw--