From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pertsserver.cs.uiuc.edu ([128.174.247.69]) by hawkwind.utcs.utoronto.ca with SMTP id <24649>; Wed, 2 Apr 1997 18:58:04 -0500 Received: (from mkgardne@localhost) by pertsserver.cs.uiuc.edu (8.8.5/8.8.5) id JAA28240; Wed, 2 Apr 1997 09:10:00 -0600 (CST) Date: Wed, 2 Apr 1997 10:10:00 -0500 Message-Id: <199704021510.JAA28240@pertsserver.cs.uiuc.edu> From: "Mark K. Gardner" To: byron@netapp.com, rc@hawkwind.utcs.toronto.edu In-reply-to: <199704020220.VAA14000@cse.psu.edu> (message from Scott Schwartz on Tue, 1 Apr 1997 21:20:32 -0500) Subject: Re: autoconfig Reply-to: mkgardne@cs.uiuc.edu >> Scott Schwartz writes: >> Byron Rakitzis writes: Byron> > #define DEFAULTPATH "/usr/ucb", "/usr/bin", "/bin", "." Byron> Byron> I think this can be deduced by running /bin/sh as a login shell Byron> with $PATH unset, and snarfing the output of "echo $PATH". Scott> I like adding /usr/local/bin to defaultpath, something /bin/sh Scott> doesn't do, because rc doesn't source .rcrc unless it is a Scott> login shell and more localized defaults makes rsh work better. Except that /usr/local/bin isn't completely standard. Our support department, in their infinite wisdom, has decided to use /local/bin instead. I like the idea (suggested by someone else) that there be an autoconfig option to set the default path. Generalizing: any setting which is not universally standard should not be hard-wired into the source (i.e., there should be an autoconfig option for it). To do otherwise would limit the portability of the code. As I see it, limiting portability is against the spirit of the upcoming release. (It would be easy to argue that there is no such thing as a universal standard in the unix world...suggesting that everything should be an option. This is where keen judgement is required. I defer to the sages among us for a definition of what is sufficiently universal.) Byron> I am sorely tempted to remove named pipe support. It never worked Byron> properly. Scott> But it works just barely well enough for SunOS, which has no Scott> /dev/fd (unless you install a nonstandard modloaded device, or Scott> override open().) It also seems to work for Solaris 2.5.1 (SunOS 5.51) which does provide /dev/fd, though I haven't tested it a lot. I would really like to see this feature continue. As I posted separately, I have dreamed of this feature for a long time and now that I have discovered that my favorite shell has it... Well, I would hate to give it up! -- Mark K. Gardner (mkgardne@cs.uiuc.edu) University of Illinois at Urbana-Champaign Real-Time Systems Laboratory --