From: "Mark K. Gardner" <mkgardne@cs.uiuc.edu>
To: byron@netapp.com, rc@hawkwind.utcs.toronto.edu
Subject: Re: autoconfig
Date: Wed, 2 Apr 1997 10:10:00 -0500 [thread overview]
Message-ID: <199704021510.JAA28240@pertsserver.cs.uiuc.edu> (raw)
In-Reply-To: <199704020220.VAA14000@cse.psu.edu> (message from Scott Schwartz on Tue, 1 Apr 1997 21:20:32 -0500)
>> Scott Schwartz <schwartz@cse.psu.edu> writes:
>> Byron Rakitzis <byron@netapp.com> 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
--
next prev parent reply other threads:[~1997-04-02 23:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-04-01 19:28 autoconfig Byron Rakitzis
1997-04-02 1:11 ` autoconfig Greg A. Woods
1997-04-02 8:32 ` autoconfig Stefan Dalibor
1997-04-02 2:20 ` autoconfig Scott Schwartz
1997-04-02 15:10 ` Mark K. Gardner [this message]
1997-04-02 2:59 ` autoconfig David Luyer
1997-04-02 16:32 ` autoconfig Chet Ramey
1997-04-01 23:52 autoconfig Alan Watson
1997-04-02 9:38 autoconfig Bengt Kleberg
1997-04-03 0:15 ` autoconfig Scott Merrilees
1997-04-03 3:14 ` autoconfig Warren Toomey
1997-04-02 17:30 autoconfig Rich Salz
1997-04-02 20:24 autoconfig Byron Rakitzis
1997-04-05 18:38 autoconfig Bengt Kleberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199704021510.JAA28240@pertsserver.cs.uiuc.edu \
--to=mkgardne@cs.uiuc.edu \
--cc=byron@netapp.com \
--cc=rc@hawkwind.utcs.toronto.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).