Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ptsfa!hoptoad!unisoft!gethen!bdt!david
From: david@bdt.UUCP (David Beckemeyer)
Newsgroups: comp.sys.atari.st
Subject: Re: Pexec Cookbook
Message-ID: <161@bdt.UUCP>
Date: 2 Mar 88 22:45:41 GMT
References: <498@uhnix2.UUCP> <150@bdt.UUCP> <1988Feb27.141030.26647@jarvis.csri.toronto.edu>
Reply-To: david@bdt.UUCP (David Beckemeyer)
Organization: Beckemeyer Development Tools, Oakland, CA
Lines: 24
Keywords: Pexec

In article <1988Feb27.141030.26647@jarvis.csri.toronto.edu> juancho@dgp.toronto.edu (John Buchanan) writes:
>	What can be done about accessing argv[0].  It would be nice to 
>know what the name of the program running is.  I have not seen any discussion
>about this.
The ARGV= environment string (MWC format) supplies argv[0] through argc.
The first string after the ARGV= is argv[0], argv[1] is the second string,
and so on.  Each string is separated by one NUL (zero byte).  The list of
arguments is terminated with two NUL bytes (which marks the end of the env.)

The MWC msh shell and the Beckemeyer Development Micro C-Shell and MT C-Shell
command shells all support this "extended" argument passing convention.

The MWC startup code reads this env. and loads the args into the argv[]
array before calling main().  I don't think any of the other C compilers
do it yet.  So programs written in MWC, when used with msh or csh will
have a valid argv[0].    I have a module that will read the env. for Alcyon
C. If anybody wants it send me mail.  If I get a lot of requests, maybe
I'll post it.  But without that, if you write your programs in another
C, or if you don't use msh or csh, then argv[0] will not be valid in
your programs.
-- 
David Beckemeyer			| "To understand ranch lingo all yuh
Beckemeyer Development Tools		| have to do is to know in advance what
478 Santa Clara Ave, Oakland, CA 94610	| the other feller means an' then pay
UUCP: ...!ihnp4!hoptoad!bdt!david 	| no attention to what he says"