10/11/83 Enhancements to the read_mail command This info segment briefly describes the enhancements made to the read_mail command in various system releases. 10/11/83 List of enhancements in MR10.2: (1) forwarding with comments, (2) new forward request control arguments, (3) recipient notification in forward and reply, (4) improved mailbox selection, (5) improved message selection, (6) improved control over message display format, (7) improved message summaries, and (8) use of the Acknowledge-To field Forwarding with comments: The forward request is now able to add a comment to a message before forwarding the message. This feature is requested by using the new "-add_comments" control argument on the forward request line. When this control argument is given, the user is prompted for the text of the comment; this text may be edited in the same way that the message created by send_mail is edited before transmission. The text of the comment is placed in the new "Redistributed-Comment" field which is added by this request in addition to the standard redistribution header fields. The original copy of the message is not modified by this operation. For more information, type: help forward New forward request control arguments: The following control arguments are now supported by the forward request: -acknowledge, -ack specifies that each recipient of the forwarded message will send an acknowledgement to the user who forwarded the message after they have read the message. -no_acknowledge, -nack specifies that the user forwarding the message does not want to receive acknowledgements. (Default) -log causes a copy of the forwarded message to be placed in the user's logbox. If the logbox does not it exist, it will be created and a message to that effect will be displayed. -save path, -sv path causes a copy of the forwarded message to be placed into the savebox with the specified pathname. The suffix "sv.mbx" is added if necessary. If the savebox does not exist, the user will be queried for permission to create the savebox. If the user refuses to give permission, the forward request will be aborted without actually sending the message to any of the recipients. Recipient notification in forward and reply: The forward and reply requests now permit the user to indicate whether or not the mail system should send "You have mail." notification messages to the recipients of the message. This facility is controlled by the following new request control arguments: -notify, -nt specifies that the mail system should send a "You have mail." notification to each recipient of the message. (Default) -no_notify, -nnt specifies that the mail system should not send notification messages. Improved mailbox selection: The read_mail command now permits the name of an entry in the system mail table to be used to specify the mailbox to be examined. For example, the command line read_mail Palter will now examine the contents of the user Palter's default mailbox provided that there is no mailbox or savebox in the working directory named Palter.mbx or Palter.sv.mbx, respectively, and that the the mail table entry for Palter specifies his default mailbox as its value. For more detailed information, type: help read_mail -ca -user; help read_mail -section mailbox selection For more detailed information about the mail table, type: help mail_table.gi Improved message selection: The read_mail command now provides greater flexibility in determining which messages in the mailbox are to be examined. This new capability is provided by the following read_mail control arguments: -accessible, -acc specifies that read_mail should only select those messages in the mailbox that the user is permitted to read. If the user has read (r) extended access on the mailbox, read_mail will select all messages in the mailbox; if the user has own (o) extended access on the mailbox, read_mail will select only those messages which the user sent to the mailbox. (Default) -all, -a specifies that read_mail should select all messages in the mailbox regardless of who sent them. Use of this control argument requires read (r) extended access on the mailbox. -own specifies that read_mail should select only those messages in the mailbox that the user himself sent to the mailbox. Use of this control argument requires own (o) extended access on the mailbox. -not_own specifies that read_mail should select only those messages in the mailbox that were not sent by the user. Use of this control argument requires read (r) extended access on the mailbox. Improved control over message display format: The read_mail print request now provides four levels of detail for the information displayed from the message header. Which level of detail to use is specified by one of the following request line control arguments: -long_header, -lghe specifies that the print request is to display all information from the message header including network tracing information even if some of the information is redundant. (Ie: if the From, Sender, and Delivery-By fields are all equal, this option will force the print request to display all three fields when it prints the message). -header, -he specifies that the print request is to display all information from the message header including user-defined fields while excluding the message trace and redundant information. (Default) -brief_header, -bfhe specifies that the print request is to display the minimal amount of information from the message header. The date and authors are always displayed; the subject is displayed if it isn't blank; the number of recipients is displayed either if there is more than one recipient or the user is not the sole recipient of the message; if the message was ever forwarded with comments, these comments will be displayed. -no_header, -nhe specifies that the print request is to display absolutely no information from the message header. Only the message number, message body line count, and message body will be displayed. The above control arguments are also available on the read_mail command line in order to change the detail level default for the print request within a particular invocation. In addition, the print_header request now accepts the "-long", "-default", and "-brief" control arguments to select amongst the first three levels of detail described above. For more information, type: help message_format.gi Improved message summaries: The message summary produced by the list request has been enhanced to include two new flag characters after the message number. The "A" flag will appear for any message which will be acknowledged after it is printed. The "&" flag will appear for any message which can not be deleted due to insufficient access. Use of the Acknowledge-To field: The read_mail command now uses the contents of the last Acknowledge-To or Redistributed-Acknowledge-To field in the message to determine to whom it should send message acknowledgements. 10/06/82 List of enhancements in MR10.1: (1) an improved mailbox selection capability, (2) the print_header request, (3) the apply request (4) elimination of the "-all" control argument, (5) extended message selection, (6) improvements to the reply request, (7) request line abbreviation processing, (8) new standard requests, (9) improved self-documentation facilities, (10) new request name abbreviations, (11) new command line control arguments, (12) protection from accidental deletion of messages, (13) minimal video system support, and (14) improved acknowledgements. Enhanced mailbox selection: The read_mail command now uses a different interpretation of a non-control argument on its command line when selecting a mailbox. This new interpretation was chosen to simplify the selection of mailboxes and saveboxes in the working directory. The new interpretation is: STR is any non-control argument and is first interpreted as: -mailbox STR if no mailbox is found, this specification is then interpreted as: -save STR if no savebox is found, this specification is then interpreted as: -user STR print_header request: The print_header request prints the message header of the selected messages. It is intended as a replacement for the "-header_only" control argument available with the print request. The "-header_only" control argument is now undocumented but will be retained for one release to allow users to convert their exec_coms (if any). apply request: The apply request executes an arbitrary command line on a segment in the process directory containing the header and text of a message. For example, the following request line will issue an output request for the current message: apply "do ""copy &1 ===; eor &1 -dl""" Due to lack of appropriate mail system primitives, the apply request can not be used to modify the actual message in the mailbox. Elimination of the "-all" control argument: Three new control arguments -- -include_deleted, -only_deleted, and -only_non_deleted -- are added to all requests to replace the "-all" control argument. The now obsolete "-all" control argument caused a request to operate on deleted messages in addition to non-deleted messages. However, the choice of "-all" for this control argument caused considerable confusion as it is too similar to the "all" message specifier which selects all non-deleted messages in the mailbox. The "-all" control argument is now undocumented but will be retained for one release to allow users to convert to the new control arguments. List of control arguments replacing "-all": -include_deleted, -idl includes all messages in the mailbox whether or not they have been deleted when processing any message_specifiers to determine which messages to process. -only_deleted, -odl includes only those messages which have been deleted. This is the default for the retrieve request. -only_non_deleted, -ondl includes only those messages which have not been deleted. This is the default for all requests other than retrieve. Extended message selection: New control arguments are added to the list, print, print_header, delete, and retrieve requests to allow selection of messages by date, author, recipient, and/or subject. A detailed description of these control arguments can be obtained by issuing the following request within the read_mail subsystem: help selection_control_args.gi These selection facilities can be used with other requests by use of the list active function. For example, the request line log [list -before 10/1/81 -from Palter.Multics -subject /mail/] logs all messages sent by the user Palter.Multics before October 1981 whose subject contains the string "mail". Improvements to the reply request: Numerous enhancements have been made to the reply request: Improved "Replying to" message: The message printed by reply now lists as many of the recipients as will fit on a single line rather than simply stating how many recipients would receive the reply. For example: Replying to Palter.Multics, Sibert.PDO, and 3 others. Improved -include_original action: The Date, From, and Subject fields of the original message are now included in the reply along with the original text when the "-include_original" control argument is used. Improved interaction with send_mail: The send_mail created to compose the reply message is created with the same state of abbreviation processing and the same profile as the read_mail invocation in which the reply request is given. In addition, if send_mail is exited without sending the reply, the reply request will refuse to honor the "-delete" control argument. New reply request control arguments: The following control arguments are added to the reply request: -prompt STR specifies the prompt to be used by the send_mail created to compose the reply. -no_prompt specifies that the send_mail created to compose the reply will not prompt for request lines if it enters the request loop. -include_self, -is allows a copy of the reply to be sent to the person composing the reply if the request determines that such a copy should be sent from use of the "-include_authors" or "-include_recipients" control arguments. -no_include_self, -nis specifies that a copy of the reply only be sent to the person composing the reply if explicitly requested by use of the "-to" or "-cc" control arguments. This is the default. This default allows the user to create a reply abbreviation which automatically logs the reply without receiving an extra copy whenever "-include_recipients" is specified. Request line abbreviation processing: The user can now request that abbreviations be expanded on read_mail request lines. Through the use of three new control arguments -- -abbrev (-ab), -no_abbrev (-nab), and -profile path -- the user can specify whether abbreviation processing is enabled or disabled when entering the subsystem and can also specify the profile to use to look up abbreviation definitions. If expansion is enabled and a profile is not specified, the same profile used at Multics command level will be used within read_mail. A new request, abbrev (ab), is also provided which allows the user to enable or disable abbreviation processing and to change profiles once within read_mail. The use of separate profiles for subsystems and Multics command level is encouraged to avoid problems where command level abbreviations perform unexpectedly within a subsystem and vice-versa. For example, the user may define an "rdm" abbreviation to enter read_mail with expansion enabled using the profile "mail_system.profile" in the home directory as follows: .ab rdm do "read_mail -abbrev -profile [hd]>mail_system &rf1" New standard requests: The following new requests, supplied as part of the subsystem utilities, are now available in read_mail: exec_com, ec executes a segment containing read_mail requests. The full capabilities of the Multics exec_com processors (versions one and two) are available. The read_mail subsystem uses the suffix "rdmec" for its exec_com segments to avoid confusion with exec_com's that are intended for execution at Multics command level. Additionally, read_mail will search for the exec_com using the "mail_system" search list. The default content of this search list is: -working_dir >udd>[user project]>[user name]>[user name].mlsys do if answer are identical to the do, if, and answer commands available at Multics command level except that they execute read_mail request lines rather than Multics command lines. These requests are invaluable in the creation of abbreviations within read_mail. ready, rdy prints a Multics ready message. ready_on, rdn ready_off, rdf control whether a ready message will be printed after the execution of each request line. By default, read_mail does not print ready messages. subsystem_name subsystem_version return the name and version of the current subsystem, respectively. These requsts are invaluable in abbreviations which are shared by multiple subsystem or which must know whether certain features of a subsystem are present. For example, a "quit" abbreviation may be defined as follows which specifies "-force" only when in read_mail: .ab quit do """quit"" [if [e equal [subsystem_name] read_mail] -then -force] &rf1" Improved self-documentation facilities: The "?" request now prints a multi-columnar list of the requests available within read_mail. The list_requests (lr) request is added to read_mail to provide the functionality of the old "?" request. It produces a list of valid requests with a brief summary of each request. Additionally, the list_requests request accepts request name topics and lists those request which match those topics. For example, the request line list_requests list will print the brief summary of the list, list_help, and list_requests requests. The help request is extended to accept most control arguments accepted by the Multics help command. In particular, the "-brief" control argument can be used to produce a summary of any read_mail request which includes the request's syntax line, arguments, and control arguments. In addition, the help request is changed to explain how to obtain additional online information when it is invoked with no arguments. New request name abbreviations: The following new abbreviations are now accepted for the listed requests. In addition, abbreviations available in prior releases (shown in parentheses) are still accepted. first: f last: l current: c forward (fwd): for print (pr): p delete (dl): d New command line control arguments: The following new control arguments are now recognized on the read_mail command line: -count, -ct prints the number of messages read from the mailbox before entering the request loop. (Default) -no_count, -nct does not print the message count. -acknowledge, -ack acknowledges messages which request acknowledgement. (Default) -no_acknowledge, -nack does not acknowledge any message. In addition, the following new reply request control argument are now accepted on the read_mail command line to alter the default action of the reply request: -line_length N, -ll N -indent N, -ind N -include_self, -is -no_include_self, -nis Protection from accidental deletion of messages: The user is now queried for permission to delete any message which hasn't been listed, printed, saved, or written. This change protects the user from accidently deleting newly arrived messages without having first examined them. A new control argument (-force, -fc) is added to the delete request to suppress this query. Minimal video system support: The print request now issues a "reset_more" control order after printing each message. This change allows users of the video system to easily abort the printing of a single message when printing several messages. Improved acknowledgements: The message sent when acknowledging a message now includes the subject of the original message if present. ----------------------------------------------------------- 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