rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: dws@cs.wisc.edu (DaviD W. Sanderson)
To: rc@archone.tamu.edu
Subject: an alternative: hooks for addons
Date: Thu, 1 Aug 1991 15:21:03 -0500	[thread overview]
Message-ID: <9108012021.AA00679@margay.cs.wisc.edu> (raw)

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


             reply	other threads:[~1991-08-01 20:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1991-08-01 20:21 DaviD W. Sanderson [this message]
1991-08-01 21:01 ` Mark-Jason Dominus
1991-08-01 21:36 DaviD W. Sanderson
1991-08-02  8:38 ` Boyd Roberts

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=9108012021.AA00679@margay.cs.wisc.edu \
    --to=dws@cs.wisc.edu \
    --cc=rc@archone.tamu.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).