1 03/06/86 Enhancements to the read_mail command
2
3 This info segment briefly describes the enhancements made to the
4 read_mail command in various system releases.
5
6
7 03/06/86 Added new requests and active requests:
8 Added the requests, active requests, and message specifiers
9 first last next previous_seen unseen and the requests/active
10 requests seen, unseen, and new.
11
12
13 01/23/86 Added "seen" switch to messages:
14 A message's seen switch is turned on by printing it via the print
15 request. It can also be turned on or off by "switch_on seen <MSGS>"
16 and "switch_off seen <MSGS>". The list request flags seen messages
17 with a capital "S" immediately following the current message *
18 column. The message specifiers "seen", "unseen", and "new" have also
19 been added. The specifier "new" refers to all messages after the
20 latest seen one.
21
22
23 10/11/83 List of enhancements in MR10.2:
24 1 forwarding with comments,
25 2 new forward request control arguments,
26 3 recipient notification in forward and reply,
27 4 improved mailbox selection,
28 5 improved message selection,
29 6 improved control over message display format,
30 7 improved message summaries, and
31 8 use of the Acknowledge-To field
32
33
34 Forwarding with comments:
35 The forward request is now able to add a comment to a message before
36 forwarding the message. This feature is requested by using the new
37 "-add_comments" control argument on the forward request line. When
38 this control argument is given, the user is prompted for the text of
39 the comment; this text may be edited in the same way that the message
40 created by send_mail is edited before transmission.
41
42 The text of the comment is placed in the new "Redistributed-Comment"
43 field which is added by this request in addition to the standard
44 redistribution header fields. The original copy of the message is not
45 modified by this operation.
46
47 For more information, type "help forward".
48
49
50 New forward request control arguments:
51 The following control arguments are now supported by the forward
52 request:
53
54 -acknowledge, -ack
55 specifies that each recipient of the forwarded message will send an
56 acknowledgement to the user who forwarded the message after they
57 have read the message.
58 -no_acknowledge, -nack
59 specifies that the user forwarding the message does not want to
60 receive acknowledgements. Default
61
62
63 -log
64 causes a copy of the forwarded message to be placed in the user's
65 logbox. If the logbox does not it exist, it will be created and a
66 message to that effect will be displayed.
67 -save path, -sv path
68 causes a copy of the forwarded message to be placed into the savebox
69 with the specified pathname. The suffix "sv.mbx" is added if
70 necessary. If the savebox does not exist, the user will be queried
71 for permission to create the savebox. If the user refuses to give
72 permission, the forward request will be aborted without actually
73 sending the message to any of the recipients.
74
75
76 Recipient notification in forward and reply:
77 The forward and reply requests now permit the user to indicate whether
78 or not the mail system should send "You have mail." notification
79 messages to the recipients of the message. This facility is controlled
80 by the following new request control arguments:
81
82 -notify, -nt
83 specifies that the mail system should send a "You have mail."
84 notification to each recipient of the message. Default
85 -no_notify, -nnt
86 specifies that the mail system should not send notification
87 messages.
88
89
90 Improved mailbox selection:
91 The read_mail command now permits the name of an entry in the system
92 mail table to be used to specify the mailbox to be examined. For
93 example, the command line
94
95 read_mail Palter
96
97 will now examine the contents of the user Palter's default mailbox
98 provided that there is no mailbox or savebox in the working directory
99 named Palter.mbx or Palter.sv.mbx, respectively, and that the the mail
100 table entry for Palter specifies his default mailbox as its value.
101
102 For more detailed information, type -
103 help read_mail -ca -user; help read_mail -section mailbox selection
104
105 For more detailed information about the mail table, type -
106 help mail_table.gi
107
108
109 Improved message selection:
110 The read_mail command now provides greater flexibility in determining
111 which messages in the mailbox are to be examined. This new capability
112 is provided by the following read_mail control arguments:
113
114 -accessible, -acc
115 specifies that read_mail should only select those messages in the
116 mailbox that the user is permitted to read. If the user has read
117 r extended access on the mailbox, read_mail will select all
118 messages in the mailbox; if the user has own o extended access on
119 the mailbox, read_mail will select only those messages which the
120 user sent to the mailbox. Default
121 -all, -a
122 specifies that read_mail should select all messages in the mailbox
123 regardless of who sent them. Use of this control argument requires
124 read r extended access on the mailbox.
125
126
127 -own
128 specifies that read_mail should select only those messages in the
129 mailbox that the user himself sent to the mailbox. Use of this
130 control argument requires own o extended access on the mailbox.
131 -not_own
132 specifies that read_mail should select only those messages in the
133 mailbox that were not sent by the user. Use of this control
134 argument requires read r extended access on the mailbox.
135
136
137 Improved control over message display format:
138 The read_mail print request now provides four levels of detail for the
139 information displayed from the message header. Which level of detail
140 to use is specified by one of the following request line control
141 arguments:
142
143 -long_header, -lghe
144 specifies that the print request is to display all information from
145 the message header including network tracing information even if
146 some of the information is redundant. Ie: if the From Sender and
147 Delivery-By fields are all equal this option will force the print
148 request to display all three fields when it prints the message.
149 -header, -he
150 specifies that the print request is to display all information from
151 the message header including user-defined fields while excluding the
152 message trace and redundant information. Default
153
154
155 -brief_header, -bfhe
156 specifies that the print request is to display the minimal amount of
157 information from the message header. The date and authors are
158 always displayed; the subject is displayed if it isn't blank; the
159 number of recipients is displayed either if there is more than one
160 recipient or the user is not the sole recipient of the message; if
161 the message was ever forwarded with comments, these comments will be
162 displayed.
163 -no_header, -nhe
164 specifies that the print request is to display absolutely no
165 information from the message header. Only the message number,
166 message body line count, and message body will be displayed.
167
168
169 The above control arguments are also available on the read_mail command
170 line in order to change the detail level default for the print request
171 within a particular invocation.
172
173 In addition, the print_header request now accepts the "-long",
174 "-default", and "-brief" control arguments to select amongst the first
175 three levels of detail described above.
176
177 For more information, type "help message_format.gi".
178
179
180 Improved message summaries:
181 The message summary produced by the list request has been enhanced to
182 include two new flag characters after the message number. The "A" flag
183 will appear for any message which will be acknowledged after it is
184 printed. The "&" flag will appear for any message which can not be
185 deleted due to insufficient access.
186
187
188 Use of the Acknowledge-To field:
189 The read_mail command now uses the contents of the last Acknowledge-To
190 or Redistributed-Acknowledge-To field in the message to determine to
191 whom it should send message acknowledgements.
192
193
194
195 10/06/82 List of enhancements in MR10.1:
196 1 an improved mailbox selection capability,
197 2 the print_header request,
198 3 the apply request
199 4 elimination of the "-all" control argument,
200 5 extended message selection,
201 6 improvements to the reply request,
202 7 request line abbreviation processing,
203 8 new standard requests,
204 9 improved self-documentation facilities,
205 10 new request name abbreviations,
206 11 new command line control arguments,
207 12 protection from accidental deletion of messages,
208 13 minimal video system support, and
209 14 improved acknowledgements.
210
211
212 Enhanced mailbox selection:
213 The read_mail command now uses a different interpretation of a
214 non-control argument on its command line when selecting a mailbox.
215 This new interpretation was chosen to simplify the selection of
216 mailboxes and saveboxes in the working directory.
217
218 The new interpretation is -
219 STR
220 is any non-control argument and is first interpreted as:
221 -mailbox STR
222 if no mailbox is found, this specification is then interpreted as:
223 -save STR
224 if no savebox is found, this specification is then interpreted as:
225 -user STR
226
227
228 print_header request:
229 The print_header request prints the message header of the selected
230 messages. It is intended as a replacement for the "-header_only"
231 control argument available with the print request. The "-header_only"
232 control argument is now undocumented but will be retained for one
233 release to allow users to convert their exec_coms if any.
234
235
236 apply request:
237 The apply request executes an arbitrary command line on a segment in
238 the process directory containing the header and text of a message.
239
240 For example, the following request line will issue an output request
241 for the current message:
242
243 apply "do ""copy &1 ===; eor &1 -dl"""
244
245 Due to lack of appropriate mail system primitives, the apply request
246 can not be used to modify the actual message in the mailbox.
247
248
249 Elimination of the "-all" control argument:
250 Three new control arguments -- -include_deleted, -only_deleted, and
251 -only_non_deleted -- are added to all requests to replace the "-all"
252 control argument.
253
254 The now obsolete "-all" control argument caused a request to operate on
255 deleted messages in addition to non-deleted messages. However, the
256 choice of "-all" for this control argument caused considerable
257 confusion as it is too similar to the "all" message specifier which
258 selects all non-deleted messages in the mailbox.
259
260 The "-all" control argument is now undocumented but will be retained
261 for one release to allow users to convert to the new control arguments.
262
263
264 List of control arguments replacing "-all":
265 -include_deleted, -idl
266 includes all messages in the mailbox whether or not they have been
267 deleted when processing any message_specifiers to determine which
268 messages to process.
269 -only_deleted, -odl
270 includes only those messages which have been deleted. This is the
271 default for the retrieve request.
272 -only_non_deleted, -ondl
273 includes only those messages which have not been deleted. This is
274 the default for all requests other than retrieve.
275
276
277 Extended message selection:
278 New control arguments are added to the list, print, print_header,
279 delete, and retrieve requests to allow selection of messages by date,
280 author, recipient, and/or subject. A detailed description of these
281 control arguments can be obtained by issuing the following request
282 within the read_mail subsystem:
283 help selection_control_args.gi
284
285 These selection facilities can be used with other requests by use of
286 the list active function. For example, the request line
287
288 log list -before 10/1/81 -from Palter.Multics -subject /mail/
289
290 logs all messages sent by the user Palter.Multics before October 1981
291 whose subject contains the string "mail".
292
293
294 Improvements to the reply request:
295 Numerous enhancements have been made to the reply request:
296
297
298 Improved "Replying to" message:
299 The message printed by reply now lists as many of the recipients as
300 will fit on a single line rather than simply stating how many
301 recipients would receive the reply.
302
303 For example -
304 Replying to Palter.Multics, Sibert.PDO, and 3 others.
305
306
307 Improved -include_original action:
308 The Date, From, and Subject fields of the original message are now
309 included in the reply along with the original text when the
310 "-include_original" control argument is used.
311
312
313 Improved interaction with send_mail:
314 The send_mail created to compose the reply message is created with the
315 same state of abbreviation processing and the same profile as the
316 read_mail invocation in which the reply request is given. In addition,
317 if send_mail is exited without sending the reply, the reply request
318 will refuse to honor the "-delete" control argument.
319
320
321 New reply request control arguments:
322 The following control arguments are added to the reply request:
323
324 -prompt STR
325 specifies the prompt to be used by the send_mail created to compose
326 the reply.
327 -no_prompt
328 specifies that the send_mail created to compose the reply will not
329 prompt for request lines if it enters the request loop.
330
331
332 -include_self, -is
333 allows a copy of the reply to be sent to the person composing the
334 reply if the request determines that such a copy should be sent from
335 use of the "-include_authors" or "-include_recipients" control
336 arguments.
337 -no_include_self, -nis
338 specifies that a copy of the reply only be sent to the person
339 composing the reply if explicitly requested by use of the "-to" or
340 "-cc" control arguments. This is the default. This default allows
341 the user to create a reply abbreviation which automatically logs the
342 reply without receiving an extra copy whenever "-include_recipients"
343 is specified.
344
345
346 Request line abbreviation processing:
347 The user can now request that abbreviations be expanded on read_mail
348 request lines. Through the use of three new control arguments --
349 -abbrev -ab, -no_abbrev -nab, and -profile path -- the user can
350 specify whether abbreviation processing is enabled or disabled when
351 entering the subsystem and can also specify the profile to use to look
352 up abbreviation definitions. If expansion is enabled and a profile is
353 not specified, the same profile used at Multics command level will be
354 used within read_mail.
355
356 A new request, abbrev ab, is also provided which allows the user to
357 enable or disable abbreviation processing and to change profiles once
358 within read_mail.
359
360
361 The use of separate profiles for subsystems and Multics command level
362 is encouraged to avoid problems where command level abbreviations
363 perform unexpectedly within a subsystem and vice-versa.
364
365 For example, the user may define an "rdm" abbreviation to enter
366 read_mail with expansion enabled using the profile
367 "mail_system.profile" in the home directory as follows:
368
369 .ab rdm do "read_mail -abbrev -profile hd>mail_system &rf1"
370
371
372 New standard requests:
373 The following new requests, supplied as part of the subsystem
374 utilities, are now available in read_mail:
375
376 exec_com, ec
377 executes a segment containing read_mail requests. The full
378 capabilities of the Multics exec_com processors versions one and
379 two are available. The read_mail subsystem uses the suffix "rdmec"
380 for its exec_com segments to avoid confusion with exec_com's that
381 are intended for execution at Multics command level. Additionally,
382 read_mail will search for the exec_com using the "mail_system"
383 search list. The default content of this search list is:
384 -working_dir
385 >udd>user project>user name>user name.mlsys
386
387
388 do
389 if
390 answer
391 are identical to the do, if, and answer commands available at
392 Multics command level except that they execute read_mail request
393 lines rather than Multics command lines. These requests are
394 invaluable in the creation of abbreviations within read_mail.
395
396 ready, rdy
397 prints a Multics ready message.
398
399 ready_on, rdn
400 ready_off, rdf
401 control whether a ready message will be printed after the execution
402 of each request line. By default, read_mail does not print ready
403 messages.
404
405
406 subsystem_name
407 subsystem_version
408 return the name and version of the current subsystem, respectively.
409 These requsts are invaluable in abbreviations which are shared by
410 multiple subsystem or which must know whether certain features of a
411 subsystem are present. For example, a "quit" abbreviation may be
412 defined as follows which specifies "-force" only when in read_mail:
413 .ab quit do """quit"" if e equal subsystem_name
414 read_mail -then -force &rf1"
415
416
417 Improved self-documentation facilities:
418 The "?" request now prints a multi-columnar list of the requests
419 available within read_mail.
420
421 The list_requests lr request is added to read_mail to provide the
422 functionality of the old "?" request. It produces a list of valid
423 requests with a brief summary of each request. Additionally, the
424 list_requests request accepts request name topics and lists those
425 request which match those topics. For example, the request line
426
427 list_requests list
428
429 will print the brief summary of the list, list_help, and list_requests
430 requests.
431
432
433 The help request is extended to accept most control arguments accepted
434 by the Multics help command. In particular, the "-brief" control
435 argument can be used to produce a summary of any read_mail request
436 which includes the request's syntax line, arguments, and control
437 arguments. In addition, the help request is changed to explain how to
438 obtain additional online information when it is invoked with no
439 arguments.
440
441
442 New request name abbreviations:
443 The following new abbreviations are now accepted for the listed
444 requests. In addition, abbreviations available in prior releases
445 shown in parentheses are still accepted.
446
447 first: f
448 last: l
449 current: c
450 forward fwd: for
451 print pr: p
452 delete dl: d
453
454
455 New command line control arguments:
456 The following new control arguments are now recognized on the read_mail
457 command line:
458
459 -count, -ct
460 prints the number of messages read from the mailbox before entering
461 the request loop. Default
462 -no_count, -nct
463 does not print the message count.
464 -acknowledge, -ack
465 acknowledges messages which request acknowledgement. Default
466 -no_acknowledge, -nack
467 does not acknowledge any message.
468
469
470 In addition, the following new reply request control argument are now
471 accepted on the read_mail command line to alter the default action of
472 the reply request:
473 -line_length N, -ll N
474 -indent N, -ind N
475 -include_self, -is
476 -no_include_self, -nis
477
478
479 Protection from accidental deletion of messages:
480 The user is now queried for permission to delete any message which
481 hasn't been listed, printed, saved, or written. This change protects
482 the user from accidently deleting newly arrived messages without having
483 first examined them. A new control argument -force -fc is added to
484 the delete request to suppress this query.
485
486
487 Minimal video system support:
488 The print request now issues a "reset_more" control order after
489 printing each message. This change allows users of the video system to
490 easily abort the printing of a single message when printing several
491 messages.
492
493
494 Improved acknowledgements:
495 The message sent when acknowledging a message now includes the subject
496 of the original message if present.