dave@galaxia.newport.ri.us (David H. Brierley) (02/11/91)
Submitted-by: dave@galaxia.newport.ri.us (David H. Brierley) Posting-number: Volume 1, Info 1 Archive-name: info1 Welcome to comp.sources.3b1. This message contains information about the structure of the newsgroup, archive sites, and other junk. This group is modeled after the newsgroup comp.sources.misc with the difference being that this group is intended for programs that are specific to the AT&T 3B1 computer. This computer is known by several other names as well, including: AT&T Unix-pc, AT&T PC7300, AT&T Unix-pc/7300, Convergent Technologies S/50, and Convergent Technologies Safari. This information message was shamelessly stolen from the comp.sources.misc newsgroup. Thanks to Brandon and Kent for supplying such a nice template. Also, thanks to Kent for supplying a copy of the software used to post these articles. This message is probably extreme overkill for this newsgroup but I figured that since all I had to do was edit the old one I could afford to go wild. I am always looking for suggestions on how to improve the usefulness of the newsgroup. *Please* do not hesitate to send suggestions to dave@galaxia.newport.ri.us. Dave. -------------------- Subject: Introduction Comp.sources.3b1 is intended for programs which are specific to the AT&T 3B1 computer. This group will be run in an informal fashion. In general, any program source code which is pertinent to the AT&T 3B1 will be accepted, but discussion and "sources wanted" requests will be discarded with a message back to the sender advising him/her to post to the correct newsgroup. Programs which are not specific to the 3B1 are probably better off being sent to comp.sources.misc or comp.sources.unix but they can be posted here if you are insistent. As stated above, the primary reason a submission will be rejected is if it is a non-source. I, as the moderator, am striving to get things out as quickly as possible while not posting non-sources; testing is not done. If it's something that's worth testing, it probably belongs in comp.sources.unix instead. (Send submissions to comp-sources-unix@<backbone> in that case.) Testing may be done in the future. -------------------- Subject: The structure of comp.sources.3b1 articles Each posting in comp.sources.3b1 is called an "issue"; there are roughly 100 issues to a volume. The division is arbitrary, and has varied greatly in the past. There are two types of articles in comp.sources.3b1; sources and "information postings." They can be distinguished by the subject line: Subject: v01INF1: Introduction to comp.sources.3b1 This first word in the title identifies this as the first info posting of volume one. Similarly, the subject line shown below: Subject: v01i001: xtclient: use a 3b1 as a layers terminal, part01/04 identifies this as the 1st source article in Volume 1. In the above example, the Part01/04 indicates that this is the first part of a four part posting. All sources are broken up into pieces. This is done so that there will be a proper storage directory when patches are issued. The first few lines of an article are auxiliary headers that look like this: Submitted-by: root@freeware.ATT.COM Posting-number: Volume 7, Issue 82 Archive-name: os2-login/part01 The "Submitted-by" is the author of the program. IF YOU HAVE COMMENTS ABOUT THE SOURCES PUBLISHED IN COMP.SOURCES.3B1, THIS IS THE PERSON TO CONTACT. When possible, this address is in domain form, otherwise it is a UUCP bang path relative to some major site such as "uunet." The second line repeats the volume/issue information for the aide of NOTES sites and automatic archiving programs such as rkive. The Archive-name is the "official" name of this source in the archive. Large postings will have names that look like this: Archive-name: tipx/part01 Please try to use this name when requesting that sources be mailed to you. Also, note that the "part number" given in the title, and the archive name given in the auxiliary header need not be identical. Official patches will be posted as "archname/patchNN". Single-part submissions are treated as multi-part submissions for this purpose, with a single "part01" component. To support the tracking of patches the Patch-To: line is used in c.s.3b1. The Patch-To: line exists for articles that are patches to previously posted software. The Patch-To: line only appears in articles that are posted, "Official", patches. The initial postings do not contain the Patch-To: auxiliary header line. Patch-To: syntax Patch-To: package-name: Volume X, Issue x[-y,z] Patch-To: examples. These are examples and do not reflect the accurate volume/issue numbering for rkive. In the first example, the article that contains the following line is a patch to a single part posting. Patch-To: rkive: Volume 22, Issue 122 This example shows that the 122-124 indicates the patch applies to a multi- part posting. The '-' is used to mean "article A through article B, inclusive.. Patch-To: rkive: Volume 22, Issue 122-124 If a patch applies to multiple part postings that are not consecutive, a comma is used to separate the part issue numbers. It is possible to mix both commas and dashes on a single Patch-To: line. Patch-To: rkive: Volume 22, Issue 122,125,126,127 Patch-To: rkive: Volume 22, Issue 122,125-127 -------------------- Subject: Patches Handling Patches will be handled as swiftly as possible. Authors of sources posted to c.s.3b1 should send all patches to me so that I can post them back through the newsgroup in order that the patches can be archived. This has not been done in the past in other sources groups and has lead to lost patches. If the patches must get out *real* fast, post them to comp.sources.bugs and send me a copy at the same time so that they will be available when they are needed in the future. Again, patches will receive priority processing so make sure I get them... I would prefer not to post patches that are not sent by the author of the original posting unless special arrangements have been made with the author. Please send your unofficial patches to the author so that the author can incorporate them into their postings baseline. Unofficial patches can be posted to comp.sources.bugs as a method of letting the community use the fix or enhancement during the interim. It is up to the author to determine if there have been major enough changes to warrant a complete reposting. This may be necessary if the size of the patches exceeds the size of the source but in most cases only patches are posted. Total repostings should be treated as an initial posting. What follows pertains to patches... 1. When patches are submitted, they should be in context diff format. 2. A patch to patchlevel.h should be done to reflect that the patch has been applied if a patchlevel.h existed in the initial posting. If one was not included initially, maybe now is a good time to consider including one... :-) 3. Include information about which previously posted issues the patch pertains to if they were initially posted to c.s.3b1. For more information on patch see patch.man in util/patch/patch.man in the X11 Release 4 distribution or in volume7 of the comp.sources.unix archives. -------------------- Subject: Guidelines for submitting source for publication Items intended for posting and problem notes should be sent to one of the following: comp-sources-3b1@uunet.uu.net comp-sources-3b1@<news backbone site> comp-sources-3b1@galaxia.newport.ri.us Newsgroup-related mail that is *not* a submission should be sent to me at one of the following: dhb@uunet.uu.net dave@galaxia.newport.ri.us If you want verification of arrival, say so in a cover note, or at the beginning of your submission, if it is small. I will try to do this by default but if you want it guaranteed, ask... To make life easier for both myself and the users of the comp.sources.3b1 newsgroup, I request that all submissions follow the following guidelines. Not following these guidelines may result in longer delays, since some things *must* be fixed for news to accept the submission, and others fixed so that I can spend time processing submissions rather than responding to flames. ;-) The first rule is that "shell archives" as created by "shar", "cshar", "bundle", etc. be used to package files. Preferably, use cshar: it guards against mangling by older news programs, Bitnet mailers, etc. I must repack non-shar'ed submissions so that they have a better chance of surviving older mail/news systems and inter-network gateways. Second, a Subject: header should *always* be included in a submission. When a posting arrives without a Subject: line, not only does it force me to make one up for the archive list, but (more importantly) inews, the driving program for the Usenet news system, will not accept articles which lack a subject line. Please do not package executable programs and sources in the same submission. If you have a program that you absolutely *must* distribute in binary form I can arrange for it to be placed in the att7300 archive on osu-cis but it should not be posted to a sources newsgroup. Other nice things to consider/supply when submitting sources... 1. A Makefile. 2. A manual page is highly recommended for any substantial sized submissions. 3. A README file is also highly desirable. This should contain a brief description of what the posting is and any special considerations in building it. The README should also contain a list of authors and the distribution and copying policy. 4. A patchlevel.h -- This file can be used to keep track of how many official patches have been applied. -------------------- Subject: Reporting and tracking bugs. You should subscribe to comp.sources.bugs. Sometimes, when new versions of previously-published software is available, just patches are put out, usually in the form of shar files containing input for the "patch" program, new files, etc. Sometimes complete new versions are put out. Which method is used depends on the poster and the moderator. Minor updates must be in patch form and update the patchlevel.h file. Major updates should follow the guidelines for initial postings. To report bugs, contact the person listed in the Submitted-by header. Often there is a contact address in a README file, too. I do not maintain the sources I moderate, so don't send your bug reports to me. Likewise, I normally do not post patches for a package from anyone except the author. If you have patches you would like to see included in the package, send them to the person listed in the Submitted-by header. -------------------- Subject: Becoming an archive site If you collect comp.sources.3b1 postings and are willing and able to make your collection available to other people, please let me know. Benefits include the undying gratitude of your colleagues, and a promise from me to try to make sure you never lose an article whether you use rkive or not. If you can provide access to your archives send me some email and I will get you some publicity. -------------------- Subject: Archive access via ftp If an archive site provides "anonymous FTP" access, sites directly on the Internet (that is, sites possessing an IP address, which looks like four small numbers separated with periods) can use the "ftp" program to get at sources. Sites which aren't on the Internet (more properly, the NSFnet) can not use ftp to retrieve this information. And no, having the ftp program does not mean that you can access NSFnet: there are many systems which use TCP/IP over local networks only, and at least one brand of system which has a program called "ftp" that has nothing to do with the Internet at all. You should check with a local system administrator to find out the details of using ftp. On most systems and to most archive sites, the following will work: type the command "ftp system.domain" (example: "ftp uunet.uu.net" -- case does not matter), enter "anonymous" when it asks for a user name, and enter *your* Internet address for the password. If "ftp" says that the system doesn't exist, check your spelling -- if the system name is spelled correctly, look for an IP address for the archive site and badger your system administrator to install a version of ftp which knows about nameservers. You should also be warned that some systems (like uunet) will not accept FTP connections from sites not registered with a nameserver. Once you are logged in to the archive system, you will get a prompt that looks like "ftp>". (It may not be identical, since it is possible to change the ftp prompt with a command in many versions of ftp.) At this point, you can use "cd" to change directories, "ls" or "dir" to list files, and "get" to retrieve them. For sources archives, it is not necessary to worry about file types unless the files are compressed; in that case, you must use the "binary" command for Unix or VMS hosts and "tenex" on Tenex (TOPS-10, TENEX, TOPS- 20/TWENEX) hosts. *** Not switching the file type can result in a garbled file, especially on Tenex hosts, which do not store binary data the same way as Unix hosts. *** To disconnect from the archive site, enter the "bye" command. -------------------- Subject: Archive access via uucp UUCP archives aren't quite as standardized as FTP archives; check the archive list for the user name and password to use, and ask your system administrator to arrange to be able to poll the archive site. (If s/he/it refuses, you are stuck.) The "uucp" command is used to request files from a UUCP archive. Unlike FTP, UUCP does not (usually) do the transfer immediately; this is because most UUCP sites must be called over phone lines, so long-distance calls will usually be made in the early morning hours. Since you can't look around in the archives, you must know the pathname of the article to be retrieved. Most archives have an index file available via FTP; check the archive list in the next posting. It's a good idea to retrieve this file before getting anything from the archive, since things can move around without warning. The command to retrieve a submission looks like uucp -r archivesite!path/to/file "archivesite" is the name of the archive site, and "path/to/file" is the pathname listed in the archive index for that site. Please be warned that for security reasons, it is not usually possible to specify wildcards (?, *, [], or ~name) in the pathname. Also, while more recent versions of uucp allow a uucp command to traverse multiple systems (uucp -r systemA!systemB!file), for security reasons this is usually disabled. In both cases you won't find out until after the archive site has been called. -------------------- Subject: Archive access via email Some archive sites have mail servers that will accept mail from you and mail back files from the archive. There are no standards here; however, it's usually safe to mail a message containing the single word "help" to the mail server. Check the archive list for more information. -------------------- Subject: Extracting a retrieved archive member If the article came from an archive site, it may be compressed; if it was sent by a mail server, it may also be uuencoded. Compressed files have an extension of ".Z". Uuencoded files can be recognized by a line saying "begin 666 filename", followed by lines of what looks like random gobbledygook. (If a mail server splits a file into multiple parts, you may just have the gobbledygook. In this case, the server will include a message saying which part of the file it is, and will tell you how to combine them.) To extract a uuencoded file, give the command "uudecode filename". This will create a (binary, usually compressed) file in the current directory. To extract a compressed file, give the command "uncompress filename". The ".Z" extension will be removed from the file. The original, compressed file will be removed as part of this operation. After doing this, you should be left with a news article exactly as it is stored in the news spool directories. This file will contain a news header, a description (usually), and a "shell archive" ("shar"). Move to an empty directory (important!) and unpack the archive. Some systems have a command "unshar" to unpack these files; if yours does, use it. Otherwise, you can use an editor to remove the header, then just say "sh filename". I use a small (one line) shell script: sed '1,/^[#:]/d' $1 | sh which will handle anything (I hope!) in the comp.sources.3b1 archives. I do attempt to confirm that a shell archive contains nothing dangerous, but if you unpack as root and the archive removes your /etc directory or something equally unpleasant, I don't want to hear about it. Unpack shell archives as an unprivileged user. Once you've unpacked the archive, you're on your own. Keep the header from the submission handy, in case you can't figure out what's going on; the address in the "Submitted-by:" line can be used to contact the author of the program. -------------------- Subject: Listing of archive sites in no particular order Here is what each field means: Site: The name of the site nice enough to act as an archive site. Contact: The name of the person to contact and their mail address Location: The general area of the world the site is located in. Modems: For providing UUCP access, what types of modems are available. UUCP: Type of UUCP access is available. FTP: Type of FTP access is available. Mail Server: Account address of the automated mail server if available. Additional: Additional information pertaining to accessing the archive. ************************ U S A - EASTERN ************************ Site: uunet.uu.net Contact: Dave Brierley (dhb@uunet.uu.net) Location: Fairfax, VA Modems: Telebit UUCP: uunet uucp customers only FTP: anonymous ftp Mail server: netlib@uunet Additional: UUNET is keeping archives in ~ftp/comp.sources.3b1, and I will be maintaining them. You can also use 1-900-GOT-SRCS to access this archive. ************************ U S A - CENTRAL ************************ Site: cheops.cis.ohio-state.edu/osu-cis Contact: Karl Kleinpaste <uucp@cis.ohio-state.edu> Location: Columbus OH USA Modems: Telebit, V.32, 2400, 1200, 300 UUCP: anonymous (osu-cis) FTP: anonymous (cheops.cis.ohio-state.edu) Mail server: none Additional: The compleat MIT X.V11R4 distribution, most of the fixes, a few of the contrib toys. Contact uucp@cis.ohio-state.edu (== osu-cis!uucp) for anonymous UUCPing instructions exit 0 # Just in case...
dave@galaxia.newport.ri.us (David H. Brierley) (02/11/91)
Submitted-by: dave@galaxia.newport.ri.us (David H. Brierley) Posting-number: Volume 1, Info 1 Archive-name: info1 Welcome to comp.sources.3b1. This message contains information about the structure of the newsgroup, archive sites, and other junk. This group is modeled after the newsgroup comp.sources.misc with the difference being that this group is intended for programs that are specific to the AT&T 3B1 computer. This computer is known by several other names as well, including: AT&T Unix-pc, AT&T PC7300, AT&T Unix-pc/7300, Convergent Technologies S/50, and Convergent Technologies Safari. This information message was shamelessly stolen from the comp.sources.misc newsgroup. Thanks to Brandon and Kent for supplying such a nice template. Also, thanks to Kent for supplying a copy of the software used to post these articles. This message is probably extreme overkill for this newsgroup but I figured that since all I had to do was edit the old one I could afford to go wild. I am always looking for suggestions on how to improve the usefulness of the newsgroup. *Please* do not hesitate to send suggestions to dave@galaxia.newport.ri.us. Dave. -------------------- Subject: Introduction Comp.sources.3b1 is intended for programs which are specific to the AT&T 3B1 computer. This group will be run in an informal fashion. In general, any program source code which is pertinent to the AT&T 3B1 will be accepted, but discussion and "sources wanted" requests will be discarded with a message back to the sender advising him/her to post to the correct newsgroup. Programs which are not specific to the 3B1 are probably better off being sent to comp.sources.misc or comp.sources.unix but they can be posted here if you are insistent. As stated above, the primary reason a submission will be rejected is if it is a non-source. I, as the moderator, am striving to get things out as quickly as possible while not posting non-sources; testing is not done. If it's something that's worth testing, it probably belongs in comp.sources.unix instead. (Send submissions to comp-sources-unix@<backbone> in that case.) Testing may be done in the future. -------------------- Subject: The structure of comp.sources.3b1 articles Each posting in comp.sources.3b1 is called an "issue"; there are roughly 100 issues to a volume. The division is arbitrary, and has varied greatly in the past. There are two types of articles in comp.sources.3b1; sources and "information postings." They can be distinguished by the subject line: Subject: v01INF1: Introduction to comp.sources.3b1 This first word in the title identifies this as the first info posting of volume one. Similarly, the subject line shown below: Subject: v01i001: xtclient: use a 3b1 as a layers terminal, part01/04 identifies this as the 1st source article in Volume 1. In the above example, the Part01/04 indicates that this is the first part of a four part posting. All sources are broken up into pieces. This is done so that there will be a proper storage directory when patches are issued. The first few lines of an article are auxiliary headers that look like this: Submitted-by: root@freeware.ATT.COM Posting-number: Volume 7, Issue 82 Archive-name: os2-login/part01 The "Submitted-by" is the author of the program. IF YOU HAVE COMMENTS ABOUT THE SOURCES PUBLISHED IN COMP.SOURCES.3B1, THIS IS THE PERSON TO CONTACT. When possible, this address is in domain form, otherwise it is a UUCP bang path relative to some major site such as "uunet." The second line repeats the volume/issue information for the aide of NOTES sites and automatic archiving programs such as rkive. The Archive-name is the "official" name of this source in the archive. Large postings will have names that look like this: Archive-name: tipx/part01 Please try to use this name when requesting that sources be mailed to you. Also, note that the "part number" given in the title, and the archive name given in the auxiliary header need not be identical. Official patches will be posted as "archname/patchNN". Single-part submissions are treated as multi-part submissions for this purpose, with a single "part01" component. To support the tracking of patches the Patch-To: line is used in c.s.3b1. The Patch-To: line exists for articles that are patches to previously posted software. The Patch-To: line only appears in articles that are posted, "Official", patches. The initial postings do not contain the Patch-To: auxiliary header line. Patch-To: syntax Patch-To: package-name: Volume X, Issue x[-y,z] Patch-To: examples. These are examples and do not reflect the accurate volume/issue numbering for rkive. In the first example, the article that contains the following line is a patch to a single part posting. Patch-To: rkive: Volume 22, Issue 122 This example shows that the 122-124 indicates the patch applies to a multi- part posting. The '-' is used to mean "article A through article B, inclusive.. Patch-To: rkive: Volume 22, Issue 122-124 If a patch applies to multiple part postings that are not consecutive, a comma is used to separate the part issue numbers. It is possible to mix both commas and dashes on a single Patch-To: line. Patch-To: rkive: Volume 22, Issue 122,125,126,127 Patch-To: rkive: Volume 22, Issue 122,125-127 -------------------- Subject: Patches Handling Patches will be handled as swiftly as possible. Authors of sources posted to c.s.3b1 should send all patches to me so that I can post them back through the newsgroup in order that the patches can be archived. This has not been done in the past in other sources groups and has lead to lost patches. If the patches must get out *real* fast, post them to comp.sources.bugs and send me a copy at the same time so that they will be available when they are needed in the future. Again, patches will receive priority processing so make sure I get them... I would prefer not to post patches that are not sent by the author of the original posting unless special arrangements have been made with the author. Please send your unofficial patches to the author so that the author can incorporate them into their postings baseline. Unofficial patches can be posted to comp.sources.bugs as a method of letting the community use the fix or enhancement during the interim. It is up to the author to determine if there have been major enough changes to warrant a complete reposting. This may be necessary if the size of the patches exceeds the size of the source but in most cases only patches are posted. Total repostings should be treated as an initial posting. What follows pertains to patches... 1. When patches are submitted, they should be in context diff format. 2. A patch to patchlevel.h should be done to reflect that the patch has been applied if a patchlevel.h existed in the initial posting. If one was not included initially, maybe now is a good time to consider including one... :-) 3. Include information about which previously posted issues the patch pertains to if they were initially posted to c.s.3b1. For more information on patch see patch.man in util/patch/patch.man in the X11 Release 4 distribution or in volume7 of the comp.sources.unix archives. -------------------- Subject: Guidelines for submitting source for publication Items intended for posting and problem notes should be sent to one of the following: comp-sources-3b1@uunet.uu.net comp-sources-3b1@<news backbone site> comp-sources-3b1@galaxia.newport.ri.us Newsgroup-related mail that is *not* a submission should be sent to me at one of the following: dhb@uunet.uu.net dave@galaxia.newport.ri.us If you want verification of arrival, say so in a cover note, or at the beginning of your submission, if it is small. I will try to do this by default but if you want it guaranteed, ask... To make life easier for both myself and the users of the comp.sources.3b1 newsgroup, I request that all submissions follow the following guidelines. Not following these guidelines may result in longer delays, since some things *must* be fixed for news to accept the submission, and others fixed so that I can spend time processing submissions rather than responding to flames. ;-) The first rule is that "shell archives" as created by "shar", "cshar", "bundle", etc. be used to package files. Preferably, use cshar: it guards against mangling by older news programs, Bitnet mailers, etc. I must repack non-shar'ed submissions so that they have a better chance of surviving older mail/news systems and inter-network gateways. Second, a Subject: header should *always* be included in a submission. When a posting arrives without a Subject: line, not only does it force me to make one up for the archive list, but (more importantly) inews, the driving program for the Usenet news system, will not accept articles which lack a subject line. Please do not package executable programs and sources in the same submission. If you have a program that you absolutely *must* distribute in binary form I can arrange for it to be placed in the att7300 archive on osu-cis but it should not be posted to a sources newsgroup. Other nice things to consider/supply when submitting sources... 1. A Makefile. 2. A manual page is highly recommended for any substantial sized submissions. 3. A README file is also highly desirable. This should contain a brief description of what the posting is and any special considerations in building it. The README should also contain a list of authors and the distribution and copying policy. 4. A patchlevel.h -- This file can be used to keep track of how many official patches have been applied. -------------------- Subject: Reporting and tracking bugs. You should subscribe to comp.sources.bugs. Sometimes, when new versions of previously-published software is available, just patches are put out, usually in the form of shar files containing input for the "patch" program, new files, etc. Sometimes complete new versions are put out. Which method is used depends on the poster and the moderator. Minor updates must be in patch form and update the patchlevel.h file. Major updates should follow the guidelines for initial postings. To report bugs, contact the person listed in the Submitted-by header. Often there is a contact address in a README file, too. I do not maintain the sources I moderate, so don't send your bug reports to me. Likewise, I normally do not post patches for a package from anyone except the author. If you have patches you would like to see included in the package, send them to the person listed in the Submitted-by header. -------------------- Subject: Becoming an archive site If you collect comp.sources.3b1 postings and are willing and able to make your collection available to other people, please let me know. Benefits include the undying gratitude of your colleagues, and a promise from me to try to make sure you never lose an article whether you use rkive or not. If you can provide access to your archives send me some email and I will get you some publicity. -------------------- Subject: Archive access via ftp If an archive site provides "anonymous FTP" access, sites directly on the Internet (that is, sites possessing an IP address, which looks like four small numbers separated with periods) can use the "ftp" program to get at sources. Sites which aren't on the Internet (more properly, the NSFnet) can not use ftp to retrieve this information. And no, having the ftp program does not mean that you can access NSFnet: there are many systems which use TCP/IP over local networks only, and at least one brand of system which has a program called "ftp" that has nothing to do with the Internet at all. You should check with a local system administrator to find out the details of using ftp. On most systems and to most archive sites, the following will work: type the command "ftp system.domain" (example: "ftp uunet.uu.net" -- case does not matter), enter "anonymous" when it asks for a user name, and enter *your* Internet address for the password. If "ftp" says that the system doesn't exist, check your spelling -- if the system name is spelled correctly, look for an IP address for the archive site and badger your system administrator to install a version of ftp which knows about nameservers. You should also be warned that some systems (like uunet) will not accept FTP connections from sites not registered with a nameserver. Once you are logged in to the archive system, you will get a prompt that looks like "ftp>". (It may not be identical, since it is possible to change the ftp prompt with a command in many versions of ftp.) At this point, you can use "cd" to change directories, "ls" or "dir" to list files, and "get" to retrieve them. For sources archives, it is not necessary to worry about file types unless the files are compressed; in that case, you must use the "binary" command for Unix or VMS hosts and "tenex" on Tenex (TOPS-10, TENEX, TOPS- 20/TWENEX) hosts. *** Not switching the file type can result in a garbled file, especially on Tenex hosts, which do not store binary data the same way as Unix hosts. *** To disconnect from the archive site, enter the "bye" command. -------------------- Subject: Archive access via uucp UUCP archives aren't quite as standardized as FTP archives; check the archive list for the user name and password to use, and ask your system administrator to arrange to be able to poll the archive site. (If s/he/it refuses, you are stuck.) The "uucp" command is used to request files from a UUCP archive. Unlike FTP, UUCP does not (usually) do the transfer immediately; this is because most UUCP sites must be called over phone lines, so long-distance calls will usually be made in the early morning hours. Since you can't look around in the archives, you must know the pathname of the article to be retrieved. Most archives have an index file available via FTP; check the archive list in the next posting. It's a good idea to retrieve this file before getting anything from the archive, since things can move around without warning. The command to retrieve a submission looks like uucp -r archivesite!path/to/file "archivesite" is the name of the archive site, and "path/to/file" is the pathname listed in the archive index for that site. Please be warned that for security reasons, it is not usually possible to specify wildcards (?, *, [], or ~name) in the pathname. Also, while more recent versions of uucp allow a uucp command to traverse multiple systems (uucp -r systemA!systemB!file), for security reasons this is usually disabled. In both cases you won't find out until after the archive site has been called. -------------------- Subject: Archive access via email Some archive sites have mail servers that will accept mail from you and mail back files from the archive. There are no standards here; however, it's usually safe to mail a message containing the single word "help" to the mail server. Check the archive list for more information. -------------------- Subject: Extracting a retrieved archive member If the article came from an archive site, it may be compressed; if it was sent by a mail server, it may also be uuencoded. Compressed files have an extension of ".Z". Uuencoded files can be recognized by a line saying "begin 666 filename", followed by lines of what looks like random gobbledygook. (If a mail server splits a file into multiple parts, you may just have the gobbledygook. In this case, the server will include a message saying which part of the file it is, and will tell you how to combine them.) To extract a uuencoded file, give the command "uudecode filename". This will create a (binary, usually compressed) file in the current directory. To extract a compressed file, give the command "uncompress filename". The ".Z" extension will be removed from the file. The original, compressed file will be removed as part of this operation. After doing this, you should be left with a news article exactly as it is stored in the news spool directories. This file will contain a news header, a description (usually), and a "shell archive" ("shar"). Move to an empty directory (important!) and unpack the archive. Some systems have a command "unshar" to unpack these files; if yours does, use it. Otherwise, you can use an editor to remove the header, then just say "sh filename". I use a small (one line) shell script: sed '1,/^[#:]/d' $1 | sh which will handle anything (I hope!) in the comp.sources.3b1 archives. I do attempt to confirm that a shell archive contains nothing dangerous, but if you unpack as root and the archive removes your /etc directory or something equally unpleasant, I don't want to hear about it. Unpack shell archives as an unprivileged user. Once you've unpacked the archive, you're on your own. Keep the header from the submission handy, in case you can't figure out what's going on; the address in the "Submitted-by:" line can be used to contact the author of the program. -------------------- Subject: Listing of archive sites in no particular order Here is what each field means: Site: The name of the site nice enough to act as an archive site. Contact: The name of the person to contact and their mail address Location: The general area of the world the site is located in. Modems: For providing UUCP access, what types of modems are available. UUCP: Type of UUCP access is available. FTP: Type of FTP access is available. Mail Server: Account address of the automated mail server if available. Additional: Additional information pertaining to accessing the archive. ************************ U S A - EASTERN ************************ Site: uunet.uu.net Contact: Dave Brierley (dhb@uunet.uu.net) Location: Fairfax, VA Modems: Telebit UUCP: uunet uucp customers only FTP: anonymous ftp Mail server: netlib@uunet Additional: UUNET is keeping archives in ~ftp/comp.sources.3b1, and I will be maintaining them. You can also use 1-900-GOT-SRCS to access this archive. ************************ U S A - CENTRAL ************************ Site: cheops.cis.ohio-state.edu/osu-cis Contact: Karl Kleinpaste <uucp@cis.ohio-state.edu> Location: Columbus OH USA Modems: Telebit, V.32, 2400, 1200, 300 UUCP: anonymous (osu-cis) FTP: anonymous (cheops.cis.ohio-state.edu) Mail server: none Additional: The compleat MIT X.V11R4 distribution, most of the fixes, a few of the contrib toys. Contact uucp@cis.ohio-state.edu (== osu-cis!uucp) for anonymous UUCPing instructions -- David H. Brierley Home: dave@galaxia.newport.ri.us; Work: dhb@quahog.ssd.ray.com Send comp.sources.3b1 submissions to comp-sources-3b1@galaxia.newport.ri.us %% Can I be excused, my brain is full. **