Path: utzoo!mnetor!uunet!husc6!mailrus!umix!umich!mibte!gamma!ulysses!thumper!faline!bellcore!tness7!petro!swrinde!dpmizar!com50!ems!pwcs!stag!daemon From: dal@syntel.UUCP (Dale Schumacher) Newsgroups: comp.sys.atari.st Subject: (none) Message-ID: <402@stag.UUCP> Date: 4 May 88 09:46:26 GMT Sender: daemon@stag.UUCP Lines: 107 [mem@zinn.MV.COM (Mark E. Mallett) writes...] >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? Aaaah.. such strange incantations in attempt to divine if one was executed from the desktop, or elsewhere. Yes, this is a useful thing to know. Many times I've wished programs were written to pause before exit, but NOT if they're run from a shell. Following a suggestion given to me by Allan Pratt, I've come up with a fairly clean way to determine this information. The idea is this; Your process basepage contains a pointer to your parent process. By tracing the parent->parent chain, you should be able to gather enough information to determine where you came from. In order to attempt to make this portable to other ROMs, you should NOT depend on the desktop to reside at a specific location. The approach I use is to check to see if your parent's text base is in high-memory ROM, and if so, count the number of levels deep you are in the parent chain. The three cases I look for are; Auto folder, which is shallow and in ROM; Desktop, which is one level deeper than Auto and in ROM; and shell, which is not in ROM at all. I admit that this is not fool-proof. If future OS versions change the number of nesting levels for default processes, or if the OS is RAM loaded, this method will fail, but for now it works on the 520/1040ST and it should work on the Mega. The following C program demonstrates... /* * camefrom -- tell what our parent process was. */ #include #include #define FROM_AUTO (-1) #define FROM_SHELL (0) #define FROM_DESKTOP (1) main() { register int from; printf("camefrom() = "); switch(from = camefrom()) { case FROM_AUTO: puts("\AUTO folder."); break; case FROM_SHELL: puts("a shell program."); break; case FROM_DESKTOP: puts("the desktop."); break; default: puts("outer space."); break; } if(from) { printf("Hit [RETURN]..."); getch(); } } camefrom() { register BASEPAGE *p = _base; register int n = 0; p = p->p_parent; if((((long) (p->p_tbase)) & 0x800000L) == 0L) return(FROM_SHELL); while(p = p->p_parent) ++n; return((n == 1) ? FROM_AUTO : ((n == 2) ? FROM_DESKTOP : FROM_SHELL)); } -- Dale Schumacher 399 Beacon Ave. (alias: Dalnefre') St. Paul, MN 55104 ..ihnp4!bungia!stag!syntel!dal United States of America "The ability of new supercomputers to make 10 million mistakes per second adds a whole new dimension of meaning to the term 'Megaflop'". -David Robb