nut@nuthaus.UUCP (Adam G. Tilghman) (02/16/91)
I am writing a program which needs to find out its own name -
I know this is possible, but how is it done? The only way that
I can think of is back-tracing into the parent program to find the
Pexec() parameters, but this doesn't ring very kosher to me :-)
Is there a better way?
-- Adam
--
= Adam G. Tilghman - SysOp/WizOp/Janitor of Eleusesthai BBS =
= USnail: 116 Escanyo Dr., So. San Francisco, CA, 94080-4134 USA =
= Voice Phone: +1 415 873 3091 / BBS Phone: +1 415 871 9451 =
= nut@nuthaus.UUCP {hoptoad,well}!wet!nuthaus!nut nut@wet.UUCP =warwick@batserver.cs.uq.oz.au (Warwick Allison) (02/18/91)
In <2133022@nuthaus.UUCP> nut@nuthaus.UUCP (Adam G. Tilghman) writes: > I am writing a program which needs to find out its own name - >I know this is possible, but how is it done? The only way that >I can think of is back-tracing into the parent program to find the >Pexec() parameters, but this doesn't ring very kosher to me :-) >Is there a better way? The shell_read() call returns the info you are looking for. Watch out though. Apparently, some Shells (command line interpreters) do not set things up properly - it will definately work from the desktop though. -- _ |\ warwick@batserver.cs.uq.oz.au / `-' * <-- Computer Science Department, \__--_/ University of Queensland, V AUSTRALIA.
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (02/18/91)
nut@nuthaus.UUCP (Adam G. Tilghman) writes: > I am writing a program which needs to find out its own name - >I know this is possible, but how is it done? The only way that >I can think of is back-tracing into the parent program to find the >Pexec() parameters, but this doesn't ring very kosher to me :-) >Is there a better way? If your program has been started via shel_write, you can get your path and name by calling shel_read. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de ----------------------------------------------------------------------
7103_2622@uwovax.uwo.ca (Eric Smith) (02/19/91)
In article <2133022@nuthaus.UUCP>, nut@nuthaus.UUCP (Adam G. Tilghman) writes: > > I am writing a program which needs to find out its own name - > I know this is possible, but how is it done? The only way that > I can think of is back-tracing into the parent program to find the > Pexec() parameters, but this doesn't ring very kosher to me :-) > Is there a better way? > Indeed, this is a very bad thing to do -- certainly it will fail big time under MiNT, and probably under RTX and other systems (including, perhaps, future versions of TOS). There is an AES call that can get the program name if the program was started from the desktop. If you were started from a shell that supports the mwc/Atari extended argument passing conventions, the program name is put in the environment after the variable ARGV=. Some C compilers will automatically put this into argv[0] (gcc and mwc will). -- Eric R. Smith email: Dept. of Mathematics eric.smith@uwo.ca University of Western Ontario 7103_2622@uwovax.bitnet
apratt@atari.UUCP (Allan Pratt) (02/20/91)
7103_2622@uwovax.uwo.ca (Eric Smith) writes: >nut@nuthaus.UUCP (Adam G. Tilghman) writes: >> I am writing a program which needs to find out its own name - >> I know this is possible, but how is it done? The only way that >> I can think of is back-tracing into the parent program to find the >> Pexec() parameters, but this doesn't ring very kosher to me :-) >> Is there a better way? >Indeed, this is a very bad thing to do -- certainly it will fail big time >under MiNT, and probably under RTX and other systems (including, perhaps, >future versions of TOS). >There is an AES call [shel_read] ... If you were started from a shell that >supports the mwc/Atari extended argument passing conventions [...] I can't tell you how gratifying it was to see this question, and then no fewer than THREE ANSWERS (A) telling legal ways to do it and (B) discouraging use of any other ways. I'm speechless! Thank you! ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
Bobster@cup.portal.com (Robert Jules Shaughnessy) (02/20/91)
Just a thought, but you might be interested in my train of thought.
A file is executed by the following:
pea env Enviroment
pea com Comand Line Address
pea fil file name address (What you want)
move.w #0,-(sp) Load and Start (Execute the file)
move.w #$4b,-(sp) Function number
trap #1 (Call gemdos)
add.l #16,sp correct the stack
With this in mind, all you should have to do is the followin
sub #4,sp (Subtract 4 from the stack pointer and you should be pointing
at the address of the file name. (This could be -8 instead of 4))
movea (sp)+,a0 (Move the file name address into a0)
Now all you need to do is start reading at that address until you hit a
0 (End of file name marker) and you will have the file name the original
program used. (I think this will work in all situations. Be sure to not
mess with the stack before you do this though. It will probably need to be
the first thing you do. Oh and dont forget to correct the stack when you
done.)
I am not 100% I have this correct, but I am sure someone will tell me if I am
at error... ;^)
I hope this helps a little.csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (02/21/91)
apratt@atari.UUCP (Allan Pratt) writes: >I can't tell you how gratifying it was to see this question, and then no >fewer than THREE ANSWERS (A) telling legal ways to do it and (B) discouraging >use of any other ways. I'm speechless! Thank you! So what's the moral of it: Don't underestimate your users 8-)! BTW, the missing argv[0] in TOS programs really hurts sometimes. Sure, it's a design failure you are not responsible for, but it might be worth it thinking about solutions. >============================================ >Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. >reflect those of Atari Corp. or anyone else. ...ames!atari!apratt ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de ----------------------------------------------------------------------
apratt@atari.UUCP (Allan Pratt) (02/23/91)
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >BTW, the missing argv[0] in TOS programs really hurts sometimes. >Sure, it's a design failure you are not responsible for, but it >might be worth it thinking about solutions. We *have* thought about solutions. That's what the extended argument passing spec is for. It's pretty widely accepted, I think. It's the same as the MWC method, using ARGV= in the environment, except (A) there is no information about file handles (you can find out other ways), and (B) there is a special value in the "length" byte of the command line to tell you the environment's ARGV= is valid. I will try to find the extended argument spec document and post it again. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
kentd@FtCollins.NCR.com (Kent.Dalton) (02/26/91)
>huh, there is already a solution. if your compiler/shell does'nt >support the atari or mwc extended command line conventions, complain Where is this documented? I don't use mwc and I'm not an official Atari developer, but I do have a substantial amount of technical docs on the ST from third party sources and this topic isn't covered. Does this mean I'm not allowed to program my ST anymore? :^) :^) -- /**************************************************************************/ /* Kent Dalton * EMail: Kent.Dalton@FtCollins.NCR.COM */ /* NCR Microelectronics * CIS: 72320,3306 */ /* 2001 Danfield Ct. MS470A * */ /* Fort Collins, Colorado 80525 * (303) 223-5100 X-319 */ /**************************************************************************/ Fortune: Q: Why did the tachyon cross the road? A: Because it was on the other side.
vsnyder@jato.jpl.nasa.gov (Van Snyder) (02/27/91)
In article <2845@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >>BTW, the missing argv[0] in TOS programs really hurts sometimes. >>Sure, it's a design failure you are not responsible for, but it >>might be worth it thinking about solutions. > >We *have* thought about solutions. That's what the extended argument >passing spec is for. It's pretty widely accepted, I think. It's the same >as the MWC method, using ARGV= in the environment, except (A) there is no >information about file handles (you can find out other ways), and (B) there >is a special value in the "length" byte of the command line to tell you the >environment's ARGV= is valid. > >I will try to find the extended argument spec document and post it again. Have you considered the MS-DOS method: The ENV string block ends with 2 nulls, after which is the program name and another null? -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp