This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Beginnings of a patch: /etc/hosts


That rule is only apt if the user knows what external state is used as input to the program they're running. If that input or dependency is made explicit somehow (documentation might suffice), then you're right and it's a matter of user control. However, if the user must examine the program's source code to know why it's not behaving in the manner its authors describe, that's not cool.

As you may know, I don't subscribe to that "Use the Source, Duke" business. If one must understand the internal workings of a thing just to use it, it's not very good technology. It virtually negates the concept of automation!

Randall Schulz
Mountain View, CA USA

At 16:15 2002-09-11, Robert Collins wrote:
On Thu, 2002-09-12 at 08:57, Igor Pechtchanski wrote:
> On Wed, 11 Sep 2002, Paul Johnston wrote:
> > > No, I'm not. I'm incorporating Warren Young's suggestion. Unless someone
> > > with ME can confirm that 'uname -s' returns CYGWIN_9*? Nicholas?
> >
> > To me that's a step backwards - uname -s or $OS are the correct ways to
> > detect the operating system. Warren's approach would be fooled if a user
> > defined $SYSTEMROOT on Win 9x.
> Win 9x does not set $OS... At least my Win 98 machine at home doesn't.
> Besides, the user can always set $OS to fool the script,

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.


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]