Re: an alternative: hooks for addons

Re: an alternative: hooks for addons

[DaviD W. Sanderson]

The problems with local builtins forseen by Mark-Jason Dominus are
NO DIFFERENT from the portability problems of *any* shell script
that uses local programs.
Just because a using a local program will make a shell script
nonportable doesn't mean you shouldn't have local programs.
It's not a good enough reason to prohibit hooks for local builtins.

Re: an alternative: hooks for addons

[Boyd Roberts]

    The problems with local builtins forseen by Mark-Jason Dominus are
    NO DIFFERENT from the portability problems of *any* shell script
    that uses local programs.
    Just because a using a local program will make a shell script
    nonportable doesn't mean you shouldn't have local programs.
    It's not a good enough reason to prohibit hooks for local builtins.

Au contraire.  A local program is completely different to a shell builtin.
You miss the point entirely.  A shell builtin dictates functionality and
by definition can be relied upon.  The builtin's are what defines the shell's
command language.  All lexical, semantic and functional constructs of the
shell are `builtins'.

Say the shell had no metacharacter expansion, but there was a local hack
called `glob' (just like V5 or was it V6).  Would you write your scripts to
use `glob' when you knew it wasn't portable?  I know I wouldn't.

Just in the environment here it would be a nightmare.  Scripts that ran on
machine X would fail on machine Y, until I installed `glob'.

I run `rc' on 3 different types of systems here.  The last thing I want to
do it have to compile/port/support another supporting program.

A case in point is the global `.rcrc' (or .cshrc) at PRL.  It's executed by
at least 3 different types of machines, on 50, or so, machines around the lab.
It has to be standard and executable on all those machines, so I would
ensure that no `local hacks' were used.  I need portability.

The last thing I need to explain to someone that their login environment
is screwed because `oh, you'll need access version 5.8 for that new hack
I put into the system.rcrc yesterday, sorry'.  What I'm going to do is not
use local hacks, so I won't get bitten.

If you can't rely on the command language you'd better not use the shell.
Look at csh.  Ever written a script with an I/O re-direction on a control
flow construct?  How quickly did you realise that shell scripts are written
in sh(1)?

If you put it in the shell, you set it in concrete.  Once you add it
you've defined the command language.  Once it gains acceptance you
_cannot afford to change it_.  This is why I am so vehemently opposed
to ill thought out and gratuitous changes to the shell.

Sure, it's easy to code up.  But, it's impossible to remove.

Welcome to rc '99 that runs on a MIPS 1E9 with a terabyte of RAM...

Re: an alternative: hooks for addons

[Mark-Jason Dominus]

``Hi, MJD.  Here's that account expire script you asked for.  It runs
under rc version 1.2 beta.''

(some time later)

``Hey, it didn't work.  Are you running any funny builtins?''

``Oh, yeah, our system's version of rc is compiled with Fred Flooney's
`test' builtin and Miles Jacobi's `seq' builtin.''

``I don't know about `seq'; where'd you get it?'' 

``I think I ftp'ed it from tut.cis.ohio-state.edu last month.'' 

(some time later)

``It isn't there any more.''

``I'll send you the source code.''

``Geez, I have to recompile rc on all our machines.''

(some time later)

``Your `test' builtin is incompatible with Joe Blow's `test' builtin,
which has slightly different semantics and which is installed on our
machines `cod' and `bass' so that Professor Dingle can run the `bite-me'
script which uses it and is essential to his research.''

``I guess you'll just have to rewrite the account expire script so it
doesn't use those builtins.''

``Gee, thanks a lot.''

an alternative: hooks for addons

[DaviD W. Sanderson]

Here is an alternative proposal.  I suggest adding hooks to builtin.c
to allow for locally-defined builtins.  It would be really easy to do.

There would be two new source files: addon.h and addon.c

------ addon.h -------
/*
 * This file is the interface to the rest of rc for any locally
 * defined addon builtins.
 * The interface consists of the following macros.
 *
 * ADDON_FUN	A comma-separated list of the function names for the
 *		builtins.
 *
 * ADDON_STR	A comma-separated list of string literals corresponding
 *		to the function names in ADDON_FUN.
 *
 * The addon functions must also have proper prototypes in this file.
 * The builtins all have the form:
 *
 *	void b_NAME(char **av);
 *
 * Builtins report their exit status using set(TRUE) or set(FALSE).
 *
 * Example:
 *
 *	#define ADDON_FUN	b_access, b_printf
 *	#define ADDON_STR	"access", "printf"
 */

#define ADDON_FUN	/* nothing */
#define ADDON_STR	/* nothing */
------ addon.h -------

------ addon.c -------
/*
 * This file contains the implementations of any locally defined
 * builtins.
 */

#include "rc.h"		/* for boolean TRUE, FALSE */
#include "status.h"	/* for set() */
#include "addon.h"

static char dummy;	/* prevent an "empty translation unit" */
------ addon.c -------

Then builtins.c would be modified to #include "addon.h".
The definitions of the builtins[] and builtins_str[] arrays would
simply be augmented to:

static builtin_t *const builtins[] = {
	b_break, b_builtin, b_cd, b_echo, b_eval, b_exec, b_exit,
	b_limit, b_return, b_shift, b_umask, b_wait, b_whatis, b_dot
	, ADDON_FUN
};

static char *const builtins_str[] = {
	"break", "builtin", "cd", "echo", "eval", "exec", "exit",
	"limit", "return", "shift", "umask", "wait", "whatis", "."
	, ADDON_STR
};

This would work because the code doesn't do anything fancy like
a binary search to find the builtins.
Even adding these hooks would probably offend the zealots, but I don't
think they would stop using rc because of it.  After all, there are
already (considerably more elaborate) hooks for readline().

If this were done then I could easily add the builtins I wanted to my
own private copy of rc without offending anyone.  Also, the presence of
such builtins could be detected easily via whatis.

DaviD Sanderson