Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!labrea!decwrl!pyramid!uccba!hal!ncoast!allbery From: allbery@ncoast.UUCP (Brandon Allbery) Newsgroups: comp.lang.pascal,comp.sys.ibm.pc Subject: Re: Environment variables in Turbo Pascal Message-ID: <4085@ncoast.UUCP> Date: Thu, 6-Aug-87 22:51:19 EDT Article-I.D.: ncoast.4085 Posted: Thu Aug 6 22:51:19 1987 Date-Received: Sat, 8-Aug-87 19:16:37 EDT References: <151@ivory.SanDiego.NCR.COM> <1690@bellcore.bellcore.com> <1013@vi.ri.cmu.edu> Reply-To: allbery@ncoast.UUCP (Brandon Allbery) Followup-To: comp.lang.pascal Distribution: world Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 48 Xref: mnetor comp.lang.pascal:242 comp.sys.ibm.pc:6467 As quoted from <1013@vi.ri.cmu.edu> by jfb@vi.ri.cmu.edu (John Brennen): +--------------- | In article <1690@bellcore.bellcore.com>, tr@wind.bellcore.com (tom reingold) writes: | > I just discovered an undocumented feature of the more recent | > versions of DOS: it is at last possible to obtain argv[0]. | | Supposedly, this was considered a problem in DOS 2.0. Personally, I've never | had a real desire to know what argv[0] is. MS-DOS doesn't support links | (hard or symbolic), so each file has a unique name. But I can see where | you might want to be really friendly or something, and parse argv[0]. +--------------- Actually, it sometimes _is_ useful. I once tried to cobble together a "ps" utility to tell me how deeply I was nested in sub-COMMAND.COM's; I have a nasty tendency, under both UNIX and MS-DOS, to spawn sub-"shells" and then forget that I'm in a subshell. Under UNIX, I run csh, so I use an environ- ment variable and update it in cshrc; the result is a prompt that tells me where I am: % coesys sh COEsys@2 % unixstat UNIX|STAT@3 % ^D COEsys@2 % ^D % ^D login: Needless to say, this is a royal pain under DOS 2.11 (3.x's floppy access is way too slow for my tastes); so I tried to write a program to print out the commands (or, under 2.x, the PSP addresses) of nested processes. Not perfect, but at least I could check the nesting depth. BTW, I was finally stopped because, while I found two addresses in the PSP which apparently pointed back to the parent process's PSP, I couldn't find the way to stop it at the boot COMMAND.COM. I suppose it's possible that searching for the segment address of the beginning of the PSP was wrong. That or it is correct for the boot COMMAND.COM to point to itself -- except that an explicit check for this didn't stop the looping. Can anyone tell me what address in the PSP contains a pointer to the parent PSP, and what form the pointer takes (i.e. fully-qualified address of start of PSP, segment address of back-pointer in parent PSP, etc.)? Better yet, can anyone mail me a reasonably complete description of the various items in a PSP? Thanks in advance. -- Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!cwruecmp!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <>