05/20/81 Changes to the exec_com command and absentee facility A number of changes and additions have been made to the exec_com command, the exec_com language, and the absentee facility. The changes described in this file apply to the default, improved but essentially compatible "version 1" exec_com language. A completely incompatible "version 2" language can also be used, which described in v2_exec_com.info and v2_exec_com.differences.info. List of changes: 1) Exec_com active function 2) &return statement 3) Changes to &attach 4) Recursion check 5) Changes to &if statement syntax 6) Nested &if statements 7) Predicates: &is_af, &is_absin, &is_attached, &is_input_line 8) Redefinition of &0 9) Redefinition of &f 10) New expansion: &ec_switch 11) Implicit quoting of expansions 12) Redefinition of white space 13) New tracing statements: &control_line, &comment_line, &ready_proc 14) Changes to tracing statements 15) &version statement 16) Changed syntax of labels 17) New error message format 18) Absouts can become MSF's, and have strange bit counts. 19) Tracing statements can select the I/O stream for trace output. Exec_com active function: The exec_com command can be called as an active function. All previously valid exec_com segments will return a null result. Exec_com's which return a value will print it on the terminal when invoked as commands. Usage: [ec path {optional_args}] &return statement: A new statement is added to the exec_com language. It is equivalent to the &quit statement, except that the expansion of the rest of the line is the value of the exec_com. When exec_com is invoked as an active function, the expansion will be substituted into the command line that invoked it; when exec_com is invoked as a command, the expansion will be printed on the terminal, with a trailing newline supplied. Unlike the &print statement, the expansion will not be used as an ioa_ control string (see "ioa_.info"). All leading whitespace will be removed from the value returned. Changes to &attach: The &attach feature of exec_com has been changed to use iox_$move_attach. This will cause information about the user_input attachment to be preserved by exec_com. All methods of normal termination of an exec_com (&quit, &return, or running off the end) will now be treated as if an &detach statement had preceded the end. Recursion check: When the &attach mode is in effect, recursive calls for input (such as an attempt to read input from the active function expression of the &if statement) will be passed on to the I/O switch that would be used if &attach were not in effect. When &attach mode is not in effect, recursive invocations will result in the io_error condition being raised; this should never happen in normal operation of the exec_com command. In the .absin segment of an absentee process, such recursive calls will result in immediate termination of the absentee process (there is no switch from which to obtain the input). The usual cause of this is an active function in an &if test which asks a question of the user. Nested &if: Nested &if statements are now defined to work. Any statement except &label and &then may appear as the statement of an &then or &else clause. They may be nested to any desired depth. &else statements will be matched up to &if statements in a manner similar to PL/I syntax: the closest unmatched &if preceding the &else will be used. &then and &else statements remain the only exec_com statements which need not begin at the beginning of a line; however, now only one statement comprises a &then or &else clause, and no intervening statements (other than the &then clause) are allowed between the &if statement and the matching &else statement. Comments are allowed to intervene between the &then and &else statements, but comments and &label statements are forbidden as &then and &else clauses. Changes to &if: The &then and &else keywords are now required to be followed by white space, and preceded by white space if they occur in the middle of a line. Although this change is incompatible, users were probably unaware that &then and &else keywords occurring in the middle of a line did not need to be delimited by white space. Active functions are no longer required in an &if statement. If the expanded string following the &if is "true", then the &then clause will be executed; if it is "false", the &else clause will be executed. This is intended for use with parameters and predicates. Predicates: Three predicates have been added to the exec_com language. Each tests a state Four the exec_com being executed, and is replaced by the string "true" or the string "false" depending on the state. &is_active_function, &is_af is used to determine whether or not the exec_com was invoked as an active function. Different behavior may be desired, although the &return statement allows the programmer to disregard this when writing the exec_com. &is_absin is used to determine whether this exec_com is the controling segment of an absentee process. This is not the same as the result of the user active function, since the segment may have been invoked as an exec_com, and just happens to be in an absentee process. &is_attached is used to determine whether the &attach keyword is in effect at a particular time in the execution of an exec_com. This relieves the programmer from always having to know the &attach state merely by the position within the exec_com. Note that this state is mutually exclusive with &is_absin, since &attach is meaningless for the absin segment. &is_input_line is used to determine if the line currently being read will be a command line or an input line. All lines which are returned (i.e., non control lines) are either command lines or input lines. This applies, then, to the next non control line. For the moment, this is exclusive with &is_absin. Redefinition of &0: &0 is now defined to be the expanded pathname that was used to find the ".ec" or ".absin" segment. It is an absolute pathname with the appropriate suffix appended. However, only lexical processing has been done to it; links have not been chased. Redefinition of &f: &fN is defined to return a list of all the optional_args to the exec_com command from the Nth through the last. However, &f0 does not return &0; it starts with &1. This was done so that &f&n, which is replaced by the last argument will be replaced by nothing when &n is zero (ie., when no optional_args were supplied). New expansion: A new expansion, &ec_switch, expands to the name of the I/O switch that abs_io_ is currently using. In absentee processes, this will be user_i/o, but in other applications it may be harder to predict. For example, exec_com incorporates a 19 character unique string in the name of the switch it uses. The construct is not expected to be terribly useful in the exec_com or absentee environments (although it could be used to send control orders to abs_io_ in exec_com), but is intended for use with abs_io_ in new applications. Quoting of expansions: The three expansions, &ec_dir, &ec_name and &ec_switch, have been changed to perform substitution in the same way that &q1 substitutes arguments. Normally, this will be completely transparent, but if you use them in quoted strings and their expansions contain quotes, the quotes in the expansions will be doubled, preventing an unbalanced quotes error. Redefinition of whitespace: The definition of whitespace, which is required to delimit statement keywords from their arguments, is now the same definition the command_processor_ and abbrev use. Any of the characters SPACE, HORIZONTAL TAB, VERTICAL TAB and FORMFEED are considered interchangeable for use in exec_com statments. Newlines which occur in the input segment are used to delimit lines and statements; however, newlines which occur in expansions are treated as whitespace when delimiting keywords. Newlines which occur in expansions on command or input lines are passed back to the caller as part of a the line. No special action is taken. This is similar in treatment to \012, which causes the teletype dim to return a newline within a line. New tracing statements: Three new tracing statements were added to the exec_com language. Each keyword takes a single argument, which may be one of "on", "off", "true", and "false". There are two states; one is entered by either of the keywords "on" or "true", the other is entered by "off" or "false". If the keyword is unrecognized or absent, a warning message will be printed and "on" will be assumed. &control_line STATE causes each exec_com statement executed to be printed on the user_output switch before it is executed. The lines are printed in expanded form; only those statements actually executed are traced (ie., in an &if statement, only one clause will be traced). All ampersand substitution will have been done before the lines are printed; the active function of an &if statement will not have been evaluated. By default, this mode is "off". &comment_line STATE causes each comment line passed in the normal flow of execution to be traced. Each comment line will be printed in unexpanded form. No tracing will be performed during &label search. By default, this mode is "off". &ready_proc STATE causes the user's ready procedure to be invoked after each command line is executed from the exec_com. Whether the ready procedure prints anything or not is determined by the &ready statement. The states of &ready_proc and &ready are completely independent. When exec_com is invoked as a command, this mode is initially "on"; when invoked as an active function, this mode is initially "off". Neither of the keywords &ready_proc and &ready have any effect in an absin segment. Changes to tracing statements: The three tracing statements &command_line, &input_line and &ready have been extended to accept the keywords "true" and "false" as synonyms for "on" and "off" respectively. When exec_com is invoked as a command, &command_line and &input_line are initially "on"; when it is invoked as an active function, they are initially "off". &ready is always initially "off". &version statement: A statement has been added to the exec_com language to allow for future incompatible changes in the syntax of the language. The statement is only permitted on the very first line of the exec_com, and may have no leading white space. It takes one argument, which for the current version of exec_com must be "1". White space must be delimit &version and its argument. Only white space may follow the version number on the line. If a &version statement is present and the version number is not implemented, the exec_com will not be executed. Syntax of labels: The syntax of labels in &label and &goto statements have changed. Previously, they were terminated by the first white space, now they are terminated by the end of the line. Trailing whitespace is ignored. This change was made so that no non-blank characters on a &label or &goto line would be ignored. Labels may now be of any length, from zero characters to slightly less than a segment. Previously, they were limited to 32 characters and silently truncated if they exceeded this limit. Error message format: Error messages from exec_com and the absentee facility have been greatly improved. They span from two to four lines, depending on how much error message there is, and whether the source line can be printed. In all cases the line number on which the error occurred and the full pathname of the offending exec_com are printed. The source line will always be printed, except for syntax errors occurring in &else clauses which follow on the same line &then clauses which were taken and which returned a command or input line. Changes to absentee output file: The absentee output file may become a multi-segment file using the new abs_io_. Also, while the job is running or if the absentee process terminates abnormally, there may be spurious nulls at the end of the segment. These are present because of changes made in order to make absentee processes cheaper. If they are present, just use the adjust_bit_count (abc) command to remove them. The bit count will always be set at or beyond the logical end of file, so no valid data will ever be invisible. New options in tracing statements: The tracing statements, &command_line, &control_line, &comment_line and &input_line accept the keyword "output_switch" or "osw". An optional I/O switch name follows this keyword. If there is no switch name specified, trace output of the selected type is reverted to the default switch (user_output); if a switch name is specified, trace output will subsequently be done to that switch. The switch name may contain embedded white characters, but leading or trailing white characters will be removed. If stream output is not possible on the specified switch, the io_error condition will be raised to allow the attachments to be manually repaired before restarting the exec_com. Note that this option may not be combined with turning tracing on or off, and has no effect on whether tracing is actually done. ----------------------------------------------------------- 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