Ok, I've been thinking some more about this and I went through rc's config.h to see what could be done about it all. Here's a walk through the list of options in config.h, I wanted to see if I could get rid of most or all of them: > #define DEFAULTPATH "/usr/ucb", "/usr/bin", "/bin", "." I think this can be deduced by running /bin/sh as a login shell with $PATH unset, and snarfing the output of "echo $PATH". > #define NODIRENT > #define SVSIGS Handled by GNU autoconf. > #define NOCMDARG > #define DEVFD > #define TMPDIR "/var/tmp" I am sorely tempted to remove named pipe support. It never worked properly. So something is needed to auto-sense the particular encoding for /dev/fd (systems encode this differently), which I doubt is supplied by GNU autoconf. > #define NOLIMITS Should be handled by autoconf, or can be extended to do so. > #define NOSIGCLD Handled by autoconf. > #define READLINE Leave this as-is. > #define NOEXECVE I think I should bundle my fake execve; it is a very small amount of code and will only cause extra file opens and the like on an exec failure, which is out of the "performance loop". > #define DEFAULTINTERP "/bin/sh" Ditto, this should just be a standard feature. > #define PROTECT_ENV Given that every /bin/sh I have tried croaks on rc-native environment variable representation in some way or other, PROTECT_ENV should be the only method for encoding env. variable names. > #define NOECHO rc's echo should be built in. > #define NOJOB Does anyone use this? It forces sh-like semantics for backgrounding. Why should it be an option? I haven't found a use for it, but I think I put it in in self-defense early on. My conclusion: It seems that rc + an autoconfig script could take out all the configuration options. I don't see the point of going with Posix, then.
> I am sorely tempted to remove named pipe support. It never worked
> properly.
I use it all the time (on Digital UNIX). It might not work properly,
but it works well enough to be useful.
Alan Watson
[ On Tue, April 1, 1997 at 14:28:39 (-0500), Byron Rakitzis wrote: ] > Subject: autoconfig > > > #define DEFAULTPATH "/usr/ucb", "/usr/bin", "/bin", "." > > I think this can be deduced by running /bin/sh as a login shell > with $PATH unset, and snarfing the output of "echo $PATH". Ssh (which also uses GNU autoconf) adds a special option to the autoconf generated configure script: --with-path=PATH Default path passed to user shell by sshd. (autoconf has an AC_ARG_WITH() macro to support such features....) > I am sorely tempted to remove named pipe support. It never worked > properly. So something is needed to auto-sense the particular > encoding for /dev/fd (systems encode this differently), which I > doubt is supplied by GNU autoconf. It would be sad to lose it, though of course if it doesn't wrok right (I admit I've not tried it in a very long time), > > #define DEFAULTINTERP "/bin/sh" > > Ditto, this should just be a standard feature. Though of course autoconf can tell for sure. (Note that many modern systems don't have a /bin directory, eg. SunOS-4 & 5, though of course they do usually have a symlink there pointing at /usr/bin) > > #define PROTECT_ENV > > Given that every /bin/sh I have tried croaks on rc-native environment > variable representation in some way or other, PROTECT_ENV should > be the only method for encoding env. variable names. What if DEFAULTINTERP isn't /bin/sh? ;-) -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
byron@netapp.com (Byron Rakitzis) writes: | > #define DEFAULTPATH "/usr/ucb", "/usr/bin", "/bin", "." | | I think this can be deduced by running /bin/sh as a login shell | with $PATH unset, and snarfing the output of "echo $PATH". I like adding /usr/local/bin to defaultpath, something /bin/sh doesn't do, because rc doesn't source .rcrc unless it is a login shell and more localized defaults makes rsh work better. | I am sorely tempted to remove named pipe support. It never worked | properly. But it works just barely well enough for SunOS, which has no /dev/fd (unless you install a nonstandard modloaded device, or override open().) | > #define NOJOB | | Does anyone use this? It forces sh-like semantics for backgrounding. | Why should it be an option? I haven't found a use for it, but I think | I put it in in self-defense early on. If anyone ever ports it to Plan 9, it might be handy. (I get an urge to do this every time I hit a feature that your shell does better than the original, most often multi line lists.)
On Tue, 1 Apr 1997, Byron Rakitzis wrote:
>My conclusion: It seems that rc + an autoconfig script could take
>out all the configuration options. I don't see the point of going
>with Posix, then.
The main thing I think Posix has which would be nice/useful for
portability is sigaction() - but even that isn't totally portable
(SA_ONESHOT vs SA_RESETHAND vs OS's which assume one shot).
David.
On Tue, Apr 01, 1997 at 08:11:13PM -0500, Greg A. Woods wrote:
> [ On Tue, April 1, 1997 at 14:28:39 (-0500), Byron Rakitzis wrote: ]
> > Subject: autoconfig
> >
> > > #define DEFAULTPATH "/usr/ucb", "/usr/bin", "/bin", "."
> >
> > I think this can be deduced by running /bin/sh as a login shell
> > with $PATH unset, and snarfing the output of "echo $PATH".
This doesn't work for me (Solaris 2.5.1, DEC OSF/1 3.2) - sh just
echoes nothing if started with PATH unset. There have to be default
values compiled into the shell, but those are not echoed if $PATH
is empty.
On POSIX systems, there is the possibility of using confstr(_CS_PATH),
(pdksh does that as far as I know) but I don't know wether/how the
returned value is useful/configurable. I also vote for adding a
special option to the configure script (as I'd like to add our instal-
lation dependant local directories).
In my opinion, support for named pipes should be continued - I use
it quite often and it works fine for me.
Bye,
Stefan
--
Stefan Dalibor - dalibor@immd3.informatik.uni-erlangen.de
> My conclusion: It seems that rc + an autoconfig script could take
> out all the configuration options. I don't see the point of going
> with Posix, then.
Posix feels more "professional" than autoconfig. Perhaps I'm just very vain.
Bengt
>> 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
--
> I am sorely tempted to remove named pipe support. It never worked
> properly. So something is needed to auto-sense the particular
> encoding for /dev/fd (systems encode this differently), which I
> doubt is supplied by GNU autoconf.
Here is the test from bash's aclocal.m4 (the `local extensions' to
autoconf). It handles /dev/fd and Linux's whacky /proc/self/fd, and it
is easy enough to add more directory prefixes to the check. The bash
code then checks whether a file in /dev/fd is specified and constructs
the pathname to use with DEV_FD_PREFIX. The bash `test' code and the
code that builds filenames for use in process substitution both use
DEV_FD_PREFIX when HAVE_DEV_FD is defined.
AC_DEFUN(BASH_CHECK_DEV_FD,
[AC_MSG_CHECKING(whether /dev/fd is available)
AC_CACHE_VAL(bash_cv_dev_fd,
[if test -d /dev/fd && test -r /dev/fd/0; then
bash_cv_dev_fd=standard
elif test -d /proc/self/fd && test -r /proc/self/fd/0; then
bash_cv_dev_fd=whacky
else
bash_cv_dev_fd=absent
fi
])
AC_MSG_RESULT($bash_cv_dev_fd)
if test $bash_cv_dev_fd = "standard"; then
AC_DEFINE(HAVE_DEV_FD)
AC_DEFINE(DEV_FD_PREFIX, "/dev/fd/")
elif test $bash_cv_dev_fd = "whacky"; then
AC_DEFINE(HAVE_DEV_FD)
AC_DEFINE(DEV_FD_PREFIX, "/proc/self/fd/")
fi
])
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu
> Posix feels more "professional" than autoconfig. Perhaps I'm just very vain.
It's not vain, just very silly.
Until one standard is 100% of the "marketplace" that you wish to serve,
then leveraging well-understood, succesful, tools like FSF's autoconf
are the way to go.
This is my experience based on having developed and released several
software packages to the net at large.
/r$
>But it works just barely well enough for SunOS, which has no /dev/fd Ok, I'm convinced that people use named pipes w/rc! It will be no problem to leave it as-is. >| > #define NOJOB >| Does anyone use this? It forces sh-like semantics for backgrounding. >If anyone ever ports it to Plan 9, it might be handy. Well, NOJOB *forces* sh-like semantics for backgrounding, but those semantics are used by default when the SIGTT* signals are undefined: #if !defined(NOJOB) && defined(SIGTTOU) && defined(SIGTTIN) && defined(SIGTSTP) setsigdefaults(FALSE); [...] I'm asking whether anyone forces NOJOB on a job-control Unix. Byron.
> Posix feels more "professional" than autoconfig. Perhaps I'm just very vain.
Professional is not necessarily functional, and can sometimes be
equivalent to getting half the functionality at twice the price, and
four times the frustration and aggravation.
Posix isn't ubiquitous by any stretch of the imagination, and there
will be legacy systems where people want to run rc for a long time to
come. I've been making UNIX code work for over 10 years, and I'd
rather see autoconf.
Sm
> Posix feels more "professional" than autoconfig. Perhaps I'm just very vain.
My $0.02. I'd be happy with autoconfig, for the same reasons that Rich Salz
gave.
Warren
Greetings, Since it is a very large majority for autoconfig (and some gentle remarks about my wrongfull interest in Posix :-) I can only add that I belive that one Posix is better than several other "standards" _at the same time_. One by one the others might be "better", but it is their multitude that makes me pine for Posix. OK? Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengtk@damek.kth.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.''