05/20/81 Version 2 exec_com (initial implementation) This info seg describes the features to be incorporated in the first installation of the V2 exec_com language. Version change: Version 2 exec_com's are recognized by having "&version 2" as the first line of the ec. Anywhere else, this line is an error. The effect of this line is to switch interpreters, making it unnecessary to have an incompatible change in exec_com command usage. However, there are two incompatible changes to the language syntax. The first concerns the interpretation of unrecognized strings, and the second concerns the order of expansion and execution. In Version 1, any strings beginning with & that are not recognized as language keywords are left intact, ie., not expanded. In Version 2, any unrecognized &string causes an error. The reason for this change is as follows: It is impossible to add new keywords to the V1 language, for example to add the keyword &foo. Since the V1 interpreter doesn't recognize &foo today, it leaves it as &foo. Therefore, &foo already has a meaning: itself. Any change to make &foo mean something different is an incompatible change. A good example is the &(k) construct, where k is an integer. Users of V1 use this construct, not recognized by ec, to pass parameter references to imbedded instances of the do command or active function. For clarity, do and ec should have the same interpretation of the constructs they share; unfortunately, V1 ec cannot be changed. Version 2, on the other hand, rejects all unrecognized keywords so that they remain open for later definition. The second incompatible change is to parse keywords and arguments to exec_com statements, before expanding the arguments themselves. For example: &set foo &(bar) sets the value of foo to be the entire value of the variable bar, whether or not that value contains spaces or ampersands. Version 1 does all expansion first, then parses into arguments. The result is that &then in a parameter value can change the syntax of an &if statement, and so on. Another very visible change is that-- &if [ACTIVE STRING] is changed to-- &if &[ACTIVE STRING] so that the new &[...] construct is uniformly required to expand active functions in control lines. The obsolete syntax will continue to work as a special case, but is discouraged. Variables: Automatic variables are assigned values by the &set statement, which takes pairs of arguments: &set var_name1 value1 var_name2 value2 ... There is no restriction on the syntax of variable names or values, except that variable names are not allowed to start with an &. Spaces and ampersands inside arguments to &set have to be enclosed in the ec quotes &"...", for example: &set all_3 &"(x y z)" &"my name" Russell Russell &"yours truly" which assigns values as follows: VAR NAME VALUE all_3 (x y z) my name Russell Russell yours truly Variables are referenced by &(...) where the contents of the parentheses either is or expands to the name of a variable that has been assigned a value by &set. In the above example, expansions take place as follows: EXPRESSION EXPANDS TO &(all_3) (x y z) &(my name) Russell &(&(my name)) yours truly The V2 interpreter expands from left to right, expanding whenever it encounters a ) matching a previous (. The integer variable names are reserved for arguments to the exec_com command, and currently cannot be set by &set. The parameter reference &(1) expands to the value of the first argument, &r(3) to the value of the third argument requoted, and so on. As in Version 1, a reference to a nonexistent argument, such as &5 or &(5) if there is no fifth argument to ec, is replaced by a null string. Conversely, reference to a variable that has not been assigned a value by &set is an error. Argument defaults: The &default statement is used to set default values in case certain arguments are not specified to the exec_com command. Its syntax is: &default default1 default2 ... where any of the defaults can be &undefined or &undef to hold a place for the jth argument without assigning a default. A parameter reference &k or &(k) where k is an integer expands to the kth arg to exec_com if one is specified, else to the kth default assigned by &default, else to null string. Active function expansion: The &[...] construct is used to expand an active string anywhere in an exec_com line, whereas [...] is only expanded in command lines by the command processor. The new construct can be used, for example, to do loop arithmetic by expanding withinn a &set statement: &set arg_index &[plus &(arg_index) 1] The inner &(arg_index) is expanded first to yield a value (say 4), then the active string [plus 4 1] is expanded and the value 5 is assigned to arg_index. Literals: The first one is &"..." which encloses an arbitrary string not to be expanded. It ends with the matching double-quote character. The second is the && sequence, which expands to a single ampersand. Either this or &"..." can be used, for example, to pass parameter strings to the do command: &&1 is the same as &"&1" The rest of the literal escapes are for inserting one or more of a certain character. If followed immediately by a number in parentheses (no intervening space), the character is repeated the specified number of times. If not followed immediately by an open paren, one character is inserted. The following literal escapes are provided: & same as && if not followed by an open paren. &SP space character &HT horizontal tab &NL newline character &VT vertical tab &FF form feed &BS backspace &QT double-quote For example, &QT(5) expands to """"" and &(3) to &&&. Indenting: The V2 interpreter strips white space (the four characters space, horizontal tab, vertical tab, and form feed) from the beginning and end of each line. Stripping white space from the beginning of each line allows the user to indent the text of the ec. Literal escapes such as &HT(2) can be used to explicitly insert white space, for example at the beginning of editor input lines. Comments: The character sequence used to begin comments is changed from & (where is any white space character) to &- since the latter is less likely as the result of a simple typing error. Everything following this character sequence on a line is ignored by the interpreter, except when comments are being traced by &comment_line. Stripping white space from the ends of lines allows the user to put comments in-line: &if &[equal &1 foo] &then &-Test for "ec foo" The white space preceding the comment is stripped from the executable line, therefore the formatting of comments is left up to the user. See "Continuation" below to see how comments and line continuation interact. Continuation: A line beginning with the character sequence &+ (white space before it is ignored) continues the text of the previous line, for example: &set one hen two ducks three squawking_ &+geese Since white space is stripped from the end of each line including the one being continued, any white space to be inserted at the break must follow the &+. In the example above, squawking_geese is a single argument. White space is not stripped after &+. Since trailing white space and comments are stripped, comments can be interspersed with continuation: mbx_set_acl Database adros *.Elite.* &-Maintainers &+ ao *.*.* &-all others Note that the space after &+ is necessary to separate the third and fourth command line arguments. The complementary sequences &+ and &- can be thought of as saying "this is part of the executable line" and "this isn't" respectively. Tracing: The &command_line and &input_line statements are replaced with the new &trace statement, whose syntax is: &trace TYPES STATE {&prefix STR} {&osw SWITCHNAME} which sets tracing for one or more types of lines. TYPES can be any combination of: &command command lines. &comment comments, including those sharing other lines. &control control lines such as &print.... &input lines being read as input by some command. STATE can be one of the following: off, false disables tracing entirely. on, true enables tracing, in whichever of the following modes was last specified. The default is "unexpanded". &unexpanded prints lines as they appear in the exec_com segment. Implies "on". &expanded prints lines after all expansion has been done. Implies "on". &all prints at each stage of expansion. Implies "on". &both prints each line as it appears in the exec_com, then again after all expansion. Implies "on". PREFIX specifies a character string to be printed at the beginning of traced lines. Prefixes are all null string by default. SWITCHNAME specifies an I/O switch on which to write the trace. Return values: The &return statement operates like &quit but returns the (expanded) rest of the line as a value if exec_com was invoked as an active function. If exec_com was invoked as a command, the return value is printed rather than returned. Correspondingly, an exec_com invoked as an active function that executes a &quit statement returns null string. In summary: COMMAND ACTIVE FUNCTION &quit just quits returns null string &return prints value returns value ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved