pm@cwruecmp.UUCP (Prabhaker Mateti) (05/22/87)
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-2816john@viper.Lynx.MN.ORG (John Stanley) (05/25/87)
In article <2124@cwruecmp.UUCP> pm@cwruecmp.UUCP (Prabhaker Mateti) writes: >I would like to suggest the following usage for _shell_p. > >------------------------------------------------------------------ >[description of method] >-------------------------------------------------------------------- > > >At the moment I don't see any flaws in the scheme. I plan to implement >this scheme in the next release of Gulam. > No, No, No...!! PLEASE don't even think about doing it that way. There -is- one MAJOR flaw... It's -totaly- incompatable with the existing reciently described use for the _shell_p variable! You -could- modify your method to be compatable, but the method you described will consistantly fool any program correctly using _shell_p into crashing. The easiest method to identify the shell that won't effect any programs in a negative way would be to define a command that could be passed to the shell. The shell would then pass back either an error code, nothing, or (if it's a shell that supports this) a pointer to an identification block similar to the one you mentioned in your idea. The command should be something not likely to blow up stupid shells, but also not something likely to ever be used as a real command line. A possibility would be shell("\n\007\007\007WRU?"). I would also recommend using something for the MAGIC number less likely to be found randomly in a shell program. If you're interested, I'd be willing to create a few code samples to demonstrate how this could be done. Please let me know... --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
t68@nikhefh.UUCP (05/26/87)
In article <1042@viper.Lynx.MN.ORG>, john@viper.Lynx.MN.ORG (John Stanley) writes: > In article <2124@cwruecmp.UUCP> pm@cwruecmp.UUCP (Prabhaker Mateti) writes: > >I would like to suggest the following usage for _shell_p. > > > >------------------------------------------------------------------ > >[description of method] > >-------------------------------------------------------------------- > > The easiest method to identify the shell that won't effect any > programs in a negative way would be to define a command that could > be passed to the shell. The shell would then pass back either an > error code, nothing, or (if it's a shell that supports this) a > pointer to an identification block similar to the one you mentioned > in your idea. > This is all getting us in trouble. The easiest way to identify a parent process is via the environment string. So if you want to make shure that you are running from a particular shell you check in the environment for the string SHELL=whatever. Any decent shell program passes its identity this way. For the communication between an editor and a shell one doesn't even need this, as the shell will eat the command or it won't, depending on whether the user knows the syntax of the shell he is using. For utilities that come with a shell there is also no need for an identity check, as they were designed for the shell in case. Only if you want to make them more general you have to look in the environment. The best way is still the way as cooked up between Atari and Gert Poletiek. To get around the problem of GemDos not zeroing some variables one could have a little program as the first program in the auto folder that erases the contents of the _shell_p variable. In that case everything works perfectly and there is no need to change the 'current standard'. Jos Vermaseren T68@nikhefh.uucp
braner@batcomputer.UUCP (05/27/87)
[]
Another solution to the shell-existance checking is to keep the _shell_p
vector pointing to executable code (as described here recently) but
put some ID info just before that code. (That is of course impossible
if you write your shell in C with a compiler that does not allow in-line
assembly. End of plug :-)
This is similar to my protocol for RAM-resident utilities. I suggest that
the long word starting at offset -8 from [the address _shell_p points to]
hold an ID string, and the next long word hold a magic number. So a
calling program can do: (loose syntax here)
struct shellid {
long id
long magic
};
struct shellid *sp;
long addr;
typedef int fri(); /* function returning an int */
...
addr = *(long *) SHELL_P;
sp = (struct shellid *) (addr-8);
if (sp->magic != MAGIC) CrashAndBurn();
if (sp->id == JOHN) say("hi, john!");
return ((fri *)addr(command));
Now how do we choose the value of MAGIC? (How about ASCII of "!SH!"?)
- Moshe Braner