Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!cbosgd!cwruecmp!pm
From: pm@cwruecmp.UUCP (Prabhaker Mateti)
Newsgroups: comp.sys.atari.st
Subject: _shell_p standardization: a suggestion
Message-ID: <2124@cwruecmp.UUCP>
Date: Fri, 22-May-87 04:26:22 EDT
Article-I.D.: cwruecmp.2124
Posted: Fri May 22 04:26:22 1987
Date-Received: Sat, 23-May-87 15:10:43 EDT
Organization: CWRU Dept. of Computer Engineering, Cleveland, OH
Lines: 38
Keywords: Gulam, _shell_p, system()

I would like to suggest the following usage for _shell_p.

------------------------------------------------------------------
struct	SHELL
{	long	nmagic;		/* a magic number for shells	*/
	char	shell_id[13];	/* string name of the shell	*/
	long	(* shell_call)();
}	* _shell_p;

#define NMAGIC	0x7368656c	/* ascii codes for "shel"	*/

The shell_id[] should be a \0 terminated string.  I chose 13 because
that is 1 + the max length of the leaf filename in a path.

_shell_p -> shell_call will point to a routine that accepts a ptr to
a C string, and runs that as a cmd in the shell, and returns a long.

The area occupied by struct SHELL is 'owned' by the underlying shell.
--------------------------------------------------------------------


Any other NMAGIC number will do, as long as we all agree to it.  A client
program first checks if _shell_p is non-0L, and even, and then checks if
_shell_p->nmagic equals NMAGIC.  At this point, the client can reliably tell
if indeed there is a shell present.

I included shell_id[] because, as we know, there are enough differences
in the command syntax of the various shells.  A client may be willing and able
to issue different versions of a command string, if the shell's identity
can be determined.


At the moment I don't see any flaws in the scheme.  I plan to implement
this scheme in the next release of Gulam.

-- 
prabhaker mateti,   case western reserve university, cleveland, oh 44106
decvax!cwruecmp!pm  pm@Case (pm%Case@csnet-relay)    (216) 368-2816