Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!ames!ucbcad!ucbvax!decvax!decwrl!sun!oliveb!felix!preston From: preston@felix.UUCP (Preston Bannister) Newsgroups: comp.sys.atari.st Subject: Another proposal for passing argv[] (LONG) Message-ID: <4659@felix.UUCP> Date: Fri, 7-Aug-87 20:18:05 EDT Article-I.D.: felix.4659 Posted: Fri Aug 7 20:18:05 1987 Date-Received: Sun, 9-Aug-87 11:31:06 EDT Sender: daemon@felix.UUCP Reply-To: preston@felix.UUCP (Preston Bannister) Distribution: world Organization: FileNet Corp., Costa Mesa, CA Lines: 93 Keywords: environment arguments argv shell I had some rather non-obvious problems with one of my makefiles. It turned out that the cause of the problem with the way the program arguments were passed between Gulam and programs compiled with MWC. Mark Williams and Beckmeyer have agreed on a convention for passing the argv[] style argument list. The argument list is passed as a part of the environment (pointed to in the basepage). The format is something like: ARGV=CCCPA???????????????\0 ; exact sequence of C|P|A|F|? varies \0 \0 : : \0 \0 ; two nulls end the environment There are two main advantages in passing the argument list like this: 1. The name of the program (in argv[0]) is availible. This is useful if you have a program that might perform different functions if named differently (an example might be a program that either moved or copied lists of files depending on if it was named 'mv' or 'cp'). 2. Long argument lists can be passed. TOS limits the parameter list to a 127 character string. While you or I might not typically type in more than 127 characters to a command, a shell that does wildcard expansion can easily pass that limit. With an argv[] style parameter list you can pass an essentially unlimited number of arguments. Also the string after 'ARGV=' indicates the type of the (up to) 20 files open when the program was invoked (where C = console, P = parallel port, A = serial port, F = file, ? = not open). This information is useful and is necessary for I/O redirection to work from the console. (I believe the above explanation is correct. Someone correct me if I'm wrong :-) The problem with the above scheme is that a program that does not recognize the special form of the ARGV list may pass the environment on to it's child unchanged. If the child _does_ recognize the ARGV list in the environment, and the parent re-directed files or wanted to pass a different argument list, the child will be using the _wrong_ information. What we really need is a means for passing argument lists that will not be accidently propagated by ignorant programs. (You don't think I would have typed all this if I didn't have a suggestion, do you? :-) Apparently MSDOS 3.x uses a scheme that would fit our requirements. If we change the above representation of the environment as follows: \0 ; two nulls end the environment \1 ; indicates argv argument \0 ; list follows... CCCPA???????????????\0 ; exact sequence of C|P|A|F|? varies \0 \0 : : \0 \0 ; two nulls end argument list Programs that were oblivious to the extended argument passing scheme would stop copying the environment list when the first two consecutive nulls were found. The extended argument list would not be copied. The chances of a \1 and a \0 byte immediately following an environment string seem fairly remote (the people at Atari who have access to the sources to Pexec could verify this?). ======================================== Preston L. Bannister USENET : ucbvax!trwrb!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister -- ======================================== Preston L. Bannister USENET : ucbvax!trwrb!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister