Article View: comp.sys.atari.st
Article #32388(none)
From: Dale Schumacher
Date: Wed, 04 May 1988 09:46
Date: Wed, 04 May 1988 09:46
107 lines
4690 bytes
4690 bytes
[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 <stdio.h>
#include <basepage.h>
#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
Technical Details
Message-ID:
<402@stag.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!mailrus!umix!umich!mibte!gamma!ulysses!thumper!faline!bellcore!tness7!petro!swrinde!dpmizar!com50!ems!pwcs!stag!daemonShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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