Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ames!ncar!tank!shamash!nic.MR.NET!hal!ncoast!allbery
From: allbery@ncoast.ORG (Brandon S. Allbery)
Newsgroups: comp.databases
Subject: Re: Interactive shells from ACCELL (WAS: Re: Accell 1.3 & Unify 4.0...)
Message-ID: <13494@ncoast.ORG>
Date: 24 Mar 89 00:17:34 GMT
References: <198125@hrc.UUCP> <13452@ncoast.ORG> <6000@mrspoc.UUCP>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.databases
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 42

As quoted from <6000@mrspoc.UUCP> by itkin@mrspoc.UUCP (Steven M. List):
+---------------
| In article <13452@ncoast.ORG> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
| > I use csh as my shell (one of those old csh's from the PDP-11, pre-job
| > control, under System V).  When I shell out from Accell via push_shell$() or
| > selecting the menu option from the Development Environment, it prints a
| > prompt but doesn't maintain history; i.e. it's only *partially* interactive.
|
| After reading this, I tried the same thing with an application of mine.
| This application allows me to specify the command line to be executed and
| then executes it with the ACCELL 1.4 system$() function call.  When I just
| called "csh", I had the same problem as Brandon.  When I changed the call
| to "csh -i", however, I got history and everything!  It's certainly possible
+---------------

I am aware of this workaround.  But I have the nasty suspicion that whatever
causes csh to mess up will also cause something *else* to mess up; what
*else* does Accell screw up in the subshell's environment, besides stderr?
I'd rather fix the problem than fix the symptom.

Does 1.3 have system$()?  (I guess I'll have to check tomorrow.)  I don't
remember seeing it in the manual.

Does anyone happen to know how to use the special functions which adev
uses?  (You can see them in a strings on AMGR; they end with $$ instead of
just $.)

---

WORD OF WARNING:  I used to think our copy of 1.3 was completely broken.
Then I got the idea of moving DEFSIZE out to around 6MB -- and magically,
all the "broken" features started working.  Pay close attention to this
parameter.  (Note that the malloc() on the system in question is somewhat
brain-damaged; on other systems you won't get random errors, you'll probably
get an "out of memory" indication.)

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery@hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser