MAILHELP(1)

πŸ’Œ MAILHELP(1) β€” the mailagent's commands, explained by your fave πŸ’…

okay bestie, so this is MAILHELP(1) from the General Commands Manual section, and honestly? It's giving group chat for a whole mail-based package distribution system. Let's get into it. πŸŽ€


✨ NAME ✨

maildist, mailhelp, maillist, mailpatch β€” the mailagent's commands. πŸ¦‹


🌸 SYNOPSIS 🌸

maildist address system [ version ]
mailhelp [ address ]
maillist [ address ]
mailpatch address system version patchlist

πŸ’– DESCRIPTION πŸ’–

okay so first thing, these commands are not meant to be run directly by a user, no cap. πŸ™ˆ They may appear in any mail whose subject is set to Command. Such a mail will get processed by mailagent(1), which will pull out all lines beginning with @SH, followed by one of the commands listed above. Before any of that, the mailagent sets environment variables that every command is gonna use. πŸ’«

maildist is the one that mails a whole distribution to the given address. The version number may be omitted if the system has no version specified !! πŸ‘‘

maildist looks for the Spool/distribs file to figure out where the distribution is located. If it's been archived, the file name extension is what's used to guess how the archive will be restored:

  • .cpio β€” archive is a cpio archive πŸ“¦
  • .tar β€” archive is in tar format πŸ“¦
  • .cpio.Z β€” compressed cpio archive πŸ—œοΈ
  • .tar.Z β€” compressed tar archive πŸ—œοΈ
Note that on file systems with short file names, the final .Z extension could be dropped. Therefore, compressed archives must be explicitly stated in the Spool/distribs file. ⚠️

Once the directory is found (or extracted), maildist goes looking for a .package file. If one is found, then it's assumed this distribution is under control of the dist 3.0 package, and the makedist command gets called to actually mirror the source tree (makedist being part of dist 3.0). 🧚

Otherwise, it looks for a MANIFEST file. If it finds one, only the files listed in there will be sent. Otherwise, all the files get sent, except:

  • the binary executables and object files
  • the RCS sub-directories or RCS files
  • the private U subdirectory and the .package file
  • any core file or files in a bugs subdirectory

Then the following algorithm is used: if no RCS file is found, the file is sent as-is. Otherwise, we look for a defined lastpat symbol. If it's found, the corresponding revision is checked-out and sent. Otherwise, the last-revision on the default branch is extracted, provided that the corresponding working file is not found. πŸ”

The maildist command will not work if the system is tagged as an old one (with an o in the patches column of the distribs file). A message will be sent back to the user, explaining that only patches are available. πŸ’€

mailhelp sends help to the address (if it's omitted, the return path of the mail is used). The help text lives in Spool/agenthelp. It should have been correctly set in the installation procedure, as explained in the mailagent(1) manual page. 🫢

maillist sends the list of available distributions, with current patchlevels if necessary. The Spool/distribs and Spool/proglist files are both used to build that list. πŸ“‹

mailpatch sends one or more patches for a maintained distribution. The directory or the archive is found by scanning Spool/distribs. The bugs sub-directory must then hold the available patches. The patches may be stored in compressed form (with the ending .Z), because mailpatch knows about them and will uncompress the patch before sending. πŸ—‚οΈ

Patches for old systems are kept in a separate directory, either in normal or in compressed form. If the version number of the old system is x.y, then the directory must be named bugs-x.y and placed in the root directory of the system, just like bugs is. πŸ—ƒοΈ

Whenever the user asks for an old system, mailpatch inserts a little note giving the latest version number for that system. πŸŽ€


πŸ“ NOTE πŸ“

For a more accurate description of these commands (user's point of vue), you may want to have a look at the help file, or just send help to yourself using the mailhelp command. ✨


πŸ” FORWARDING πŸ”

When the author of a package wishes to relinquish all maintenance duty, he is most often stuck by the weight of the past: Configure scripts have his e-mail address hardwired (see unit MailAuthor.U) and Command messages for package registration and/or patch requests will continue to reach him. 😭

The answer to that is to leave a .forward file at the top of the package tree, and commands will automatically forge new requests and forward them to the address listed in the .forward file. Now the recipient surely needs a mailagent at the other end to deal with forwarded requests! πŸ¦‹

Only plain e-mail address(es) are allowed in the .forward. The "|command" processing hook is not supported, since it's not sendmail which interprets that file but the command itself. 🚫

Forwarding applies to maildist, mailpatch and package commands only. πŸ‘‘


πŸ“ FILES πŸ“

  • ~/.mailagent β€” configuration file for mailagent.
  • /usr/share/mailagent β€” directory holding templates and samples.
  • Spool/agenthelp β€” help file
  • Spool/distribs β€” distribution list
  • Spool/proglist β€” comments for available distributions
  • Spool/plsave β€” records patchlevel of archived distributions
  • Log/agentlog β€” mailagent's log file

πŸ› BUGS πŸ›

The proglist file ought to make a distinction between different versions of a same system. (it's giving "we know, we know" πŸ’€)


πŸ‘‘ AUTHOR πŸ‘‘

Raphael Manfredi <Raphael_Manfredi@pobox.com> πŸ’œ


πŸ”— SEE ALSO πŸ”—

mailagent(1), package(1).


okay that's the whole thing bestie, you ate that. 🫢 written by ram, and yeah it's MAILHELP(1) β€” go forth and distribute some packages. periodt. πŸ’…πŸŒΈ