🚀 go-pugleaf

In article <187@obie.UUCP>, Barnacle (wes@obie.UUCP) sez:
< In article <1719@ncsuvx.ncsu.edu>, wolf@csclea.ncsu.edu (Thomas Wolf) writes:
< % In article <4129@watcgl.waterloo.edu> mberkley@watnext.waterloo.edu (Mike Berkley) writes:
< % [some deleted text]
< % >One side effect of all this is that when I use the MWC cc, it thinks
< % >that I'm compiling from the desktop, so I have to press return after
< % >every cc command, a logical thing for it to do, but very annoying.
< % 
< Try setting the environment variable 'camefrom=gulam'.  This is a
< variable used by the cc program and msh to tell where it came from
< (obviously).  If it doesn't find 'camefrom' in the environment, it
< assumes 'camefrom=desktop'.  If 'gulam' doesn't work, try 'msh'.

How very strange.  I have been running MWC with my own shell, from version
1 right up to the latest beta that I got of version 3, and I have neither
had this problem, nor have I ever set (or was aware of) a "camefrom"
variable.  A scanning of the Lexicon entries for "msh" and "cc" yields no
mention of this variable, or of any other thing that might cause "cc" to
decide whether to wait for a return after it is finished.

I note that if even if I *do* set 'camefrom=desktop' (or CAMEFROM=DESKTOP,
or CAMEFROM=desktop, or camefrom=DESKTOP'), "cc" *still* runs as it ought
to from a shell, i.e. it does not wait for a return after it is done.
Perhaps this "camefrom" thing is only one of the cues that it uses.  There
is also the special "_iovector" encoding (look up crts0 in the Lexicon).
The _iovector value tells what devices the standard i/o streams are attached
to.  I wonder if Gulam sets this up properly?

-mm-
-- 
Mark E. Mallett  PO Box 4188/ Manchester NH/ 03103 
Bus. Phone: 603 645 5069    Home: 603 424 8129
uucp: mem@zinn.MV.COM  (...decvax!elrond!zinn!mem   or   ...sii!zinn!mem)
BIX: mmallett