[comp.sources.d] v16INF1: Introduction to comp.sources.misc

ggw%wolves@cs.duke.edu (Gregory G. Woodbury) (01/04/91)

First.  A Warm Welcome to the new moderator and a hearty thank you to
the old one.  We really do appreciate the service!

In article <1991Jan3.063119.4373@sparky.IMD.Sterling.COM>
kent@sparky.IMD.Sterling.COM (Kent Landfield) writes:
>Submitted-by: kent@sparky.imd.sterling.com (Kent Landfield)
>Posting-number: Volume 16, Info 1
>Archive-name: intro16
              ^^^^^^^^^^  and here is the nit!

All the other postings "Archive-Name:" headers are of the form

	directory/part

EXCEPT FOR THESE DARN INTROS!

This needlessly complicates the scripts used to stash articles for
archiving.  Additionally, it clutters up the top level of the archive
directory until someone goes in and cleans it up by hand.

I would like to suggest that the volume introductions and informational
postings all get assigned a directory of "volNNN/xxxxxx"  where the
xxxxx becomes something like "intro1", "intro2", index01, index02...
and the info postings get info.01, etc....

Or am I totally missing out on "the official way to archive" these
postings?
>
>Well here we go...
>
>comp.sources.misc is back in business!!  Sorry that it took so long to
>get the switch over accomplished. The holidays delayed things a bit...
>
>To begin with, I would like to thank Brandon for all the *great* work
>he has put in to this newsgroup.  I would also like to thank him for
>all the help he has given me in getting setup, from the software
>donation, to answering my silly questions.  Thanks again Brandon!
>
>At first glance you will notice that a few things are new or different but
>beyond the reformatting of the info postings and addition of the patchlog, 
>nothing has changed. 
>
>This is the first of five introductory messages about comp.sources.misc.
>It describes the newsgroup's history, how to submit sources to c.s.misc, 
>where the archive sites are, and how to contact and access them.
>The second, third and fourth postings together comprise the index of 
>previously posted software. The fifth article is a cross-index of patches 
>that have been posted to this newsgroup.
>
>I am currently trying to get a complete index for sources that may be 
>missing from the index posted in the second, third and fourth INF postings. 
>If you have sources posted through c.s.misc that are not listed in the index,
>please let me know so that I can update the index and the archives. Thanks.
>
>I am always looking for suggestions on how to improve the usefulness
>of the newsgroup. *Please* do not hesitate to send suggestions to
>kent@sparky.imd.sterling.com.
>
>			-Kent+
>--------------------
>Subject:  Introduction
>
>Comp.sources.misc is sort of a "catch-all" sources group.  The intent is that
>small sources, non-Un*x sources for which no newsgroup exists, and sources
>which the moderators of comp.sources.unix and comp.sources.games will not
>accept can be sent here.  This does not mean that large Un*x sources will not
>be accepted, but they will probably gain a wider distribution if they are sent
>to comp.sources.unix.  They also slow down the flow of sources through this
>newsgroup to some extent.
>
>As a result, the group will be run in an informal fashion.  In general, *any*
>program source code 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.  Please do not send either to me, they don't
>belong here.)
>
>This newsgroup isn't intended to be a high-volume one, since the "big" stuff
>should be sent elsewhere.  Of course, if I'm sent a 50-part submission like
>jetroff, the volume goes up a bit....  However, it is to be hoped that people
>still have the desire to post their favorite prompt generators, integer square
>root algorithms, etc.
>
>The moderated comp.sources.misc replaced the unmoderated net.sources in May
>1987.  This was done by the Usenet backbone in response to the observed fact
>that net.sources was largely NON-sources by number of articles.  Mail Brandon
>received at the time indicated that the majority of people were willing to 
>trade the small delays (mainly caused by network delays in mail) for having 
>a source group that wasn't full of noise.
>
>As stated above, the only 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: Deciding where to post your software
>
>There are three choices for sources newsgroups, not counting local sources
>groups (fl.sources) or groups for specific systems (comp.sys.sun, et al.).
>Choosing between them can be somewhat difficult for the novice, and even for
>seasoned sources posters with unusual submissions.  Here, then, is a
>discussion of the various "primary" sources groups, their advantages and
>disadvantages, and a crude attempt at quantifying when to use them.
> 
>First off is comp.sources.unix, the major sources group.  It is rather
>unfortunately named, but don't let that stop you from trying to submit
>something if it fits the group's guidelines otherwise.  The benefits you'll
>get are testing of source on at least some machines before posting and
>guaranteed archiving at many Internet and UUCP sites.  The problem is that
>smaller postings aren't usually accepted, especially if they don't come with a
>Makefile and README file -- and sometimes the moderator declares a moratorium
>on certain types of postings, like text editors.  Trying doesn't hurt,
>however; if the moderator rejects something, he dumps it into the c.s.misc
>mailbox.  I should also note that the current policy of comp.sources.unix is
>not to accept "shareware" programs, programs which request or require a fee to
>the author for continued use.
> 
>For small sources and beta copies of programs (which probably should not be
>archived, in favor of the production release), one might choose alt.sources.
>It has one major advantage over the other possibilities:  there is no
>moderation, meaning no delays and no rules for formatting.  You're free to
>just pipe a source file to inews if the fit takes you (not that I recommend
>it).  But it also has one major disadvantage:  since the group isn't
>moderated, there is nothing preventing people from starting up discussions
>ranging from source code topics to why EUnet works the way it does.  This, if
>you'll recall, is what caused comp.sources.misc to be created in the first
>place; although it seems that at least some people have benefitted from the
>lesson and have started to work harder to prevent its happening to
>alt.sources.  Another disadvantage is that, being an "alt" group, it doesn't
>get as wide a distribution as the "mainstream" Usenet.  (For further
>information on the "alt" hierarchy, see the "Alternative Newsgroup
>Hierarchies" document posted once a month by Gene Spafford in news.lists.)
> 
>And then there's this group, comp.sources.misc.  The original charter called
>for moderation solely to reject non-source postings, nothing more; the intent
>was to provide net.sources without the noise.  This changed rather quickly,
>as Brandon adopted a policy of letting the group be controlled more by its users
>(submitters, readers, archivers) than by "moderative fiat", to coin a
>phrase.  The policy worked quite well, but caused the newsgroup to drift
>closer to the style of a regular moderated sources group.  The advantages of
>posting here are that archiving is almost as widespread as that of
>comp.sources.unix, that anything that is source code can be posted, and that
>it's guaranteed not to be lost in "where are our Soviet friends?" postings;
>the disadvantages are that there is a delay caused by having to filter stuff
>through me, the moderator, and that submissions that aren't in the de-facto
>"standard" format will get held up while I make them so.
> 
>So which do you choose?  While there are no hard rules, there does seem to be
>an evolving rationale for the use of the groups:  tiny programs and beta-test
>copies of larger programs are often sent to alt.sources, small "released"
>programs or beta-test copies of major programs often go to comp.sources.misc,
>and released major programs usually go to comp.sources.unix.
> 
>There are, of course, other alternatives.  Games usually are sent to
>comp.sources.games regardless of their size, programs which are specific
>to a particular computer might be better off in a specialized sources group
>like comp.sources.sun, and X-Window based applications can be posted through
>comp.sources.x. However, it's up to the submitter to decide to which
>newsgroup a submission should be sent.
>
>--------------------
>Subject:  The structure of comp.sources.misc articles
>
>Each posting in comp.sources.misc 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.misc; sources
>and "information postings."  They can be distinguished by the subject
>line:
>	Subject:  v03INF1:  Introduction to comp.sources.misc
>
>This first word in the title identifies this as the first info posting of
>volume three.  Similarly, the subject line shown below:
>
>    Subject:  v014i082:  lc - Categorize and List Files In Columns, Part01/02
>
>identifies this as the 82nd source article in Volume 14.  In the above 
>example, the Part01/02 indicates that this is the first part of a two
>part posting.  All sources are broken up into pieces.  This is done so
>that there could 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.MISC, 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.misc.
>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, the
>',' is used to separate the part issue numbers. It is possible to mix both
>',' and '-' 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
>
>Prior to January 1, 1988, a different archive header system was used.  At the
>time, it was not expected that comp.sources.misc would be welded into the
>then-evolving standard for sources archiving.  (Read:  Brandon was still 
>trying to cling to the last remnants of the group's original charter....)  
>There was only one special header line, and it resided in the main header.  
>It looked like
>
>        X-Archive: yymm/nn
>
>where "yymm" was the year and month of the submission date and "nn" was 
>a sequence number.  Please keep this in mind when dealing with archive 
>submissions from 1987.
>
>-----------------
>Subject: Patches Handling
>
>Patches will be handled as swiftly as possible. Authors of sources posted
>to c.s.misc 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 interium.
>
>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.  Patches can be made with diff -c on 4.XBSD based 
>        machines and with diffc on others. Diffc can be found in 
>        volume 1 of comp.sources.unix archives. GNU diff can also be 
>        used to create context diffs.
>    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.misc.
>
>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
>"sources-misc@uunet.uu.net" or to "sources-misc@sparky.imd.sterling.com".
>
>Newsgroup-related mail that is *not* a submission should be sent to me at
>	sources-misc-request@uunet.uu.net 
>			or
>	sources-misc-request@sparky.imd.sterling.com.
>
>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.misc
>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.  ;-)
>
>First, uuencoded postings are frowned upon.  If at all possible, binary data
>files should be translated to an ASCII format that is usable by others.  If
>it's not possible, consider sending the machine-dependent parts of the
>posting to another newsgroup.  If all else fails, it will be accepted if it
>is not the only component of the submission; otherwise, it may be better to
>announce the availability of the item via anonymous FTP, UUCP, FTAM, etc
>
>A corollary of the above rule is that uuencoded (ABEd, btoa'd, BinHexed, ...)
>compressed (packed, ...) archives are not acceptable regardless of the
>compression and/or archiving method used.  Not everyone has ARC, PKZIP, ZOO,
>StuffIt, or even cpio or tar and the "compress" program.
>
>The second 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. 
>
>Third, a Subject: header should *always* be included in a submission.
>Certain large postings in the past have arrived sans Subject:; not only does
>this 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.  (Yes, I know about C news.  Do *you*
>know about RFC1033?)
>
>Please do not package executable programs and sources in the same
>submission.  Executable binary programs are inherently system-dependent, and
>therefore should be posted to a system-specific "binaries" group.  And, as a
>special case, Un*x executables should NEVER be posted to the Usenet.
>
>Please keep source filenames to 12 or fewer characters in length.
>Not everyone has long filenames... :-(
>
>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.  
>   5.  Any additional documentation (past the recommended man page) 
>       should be in PostScript format.  
>
>
>------------------------
>Subject: Special services 
>
>One way to solve the problem of an announcement not going out the same day as
>the posting it announces is to send the announcement to me -- under separate
>cover, please, it slows things down if I have to break a submission apart to
>get at the file -- with instructions as to where it should be posted, and I
>will insure that both go out the same day, if possible.  (If one of the other
>newsgroups is also moderated, there's not a whole lot I can do about it.) The
>same goes for binaries and/or other material associated with a source; send
>it under separate cover and tell me what to do with it, and I will try to
>arrange for them to all go out at the same time.
>
>To help avoid the longer delays and possible network difficulties between the
>main comp.sources.misc receiving address and sites in Australia,
>john@basser.cs.su.oz.au acts as a sub-moderator for our friends "down
>under".  It's not required to send sources to him, but the submission will be
>seen by your neighbors that much more quickly if it doesn't have to cross the
>ocean twice.  It also saves on the bills incurred by all that trans-oceanic
>data transfer, which might not matter to you but *does* matter to your site
>admin and to the Australian gateway maintainers.
>
>--------------------
>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.misc 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... :-)
>I am currently looking for archive sites outside the US.  If you can provide 
>access to your archives send me some email and I will get you some publicity...
>:-)  If you need automated tools to build and maintain your archives, I have 
>those too .. :-) If you need a tape of the archives to get you jump-started, 
>let me know.
>
>--------------------
>Subject: Accessing the archives
>
>The complete archives are fairly large; an average volume is 3.8 megabytes.
>
>There are several active archive sites around the net.  I am currently
>trying to locate archive sites in Europe, Asia and Australia.  If you 
>are interested please contact me.
>
>Some sites below will send tapes through the mail.  For those sites, send
>a 1/2" mag tape WITH RETURN POSTAGE and RETURN MAILER.  Tapes without
>postage or mailer will not be returned.  No other methods (COD, etc.) are
>available; please don't ask.
>
>There a couple sites that provide email access to their archives. Please
>use them when you need to locate a missing issue. Please don't ask me for 
>missing issues, unless you are sure you are reporting a net-wide problem of
>propagation. At the end are detailed instructions on how to access
>the archives.  More sites will be listed there in the future.
>
>I have access to archives here at Sterling. I do not have ftp or email
>archive access available at the present time.  I have as complete a 
>set of archives as I have found. I have all the issues listed in the indexes.
>If anyone has an article that was posted to the group that is not listed
>in the indexes, please send me the information and a copy of the article
>so that I can update the archive sites that I maintain.  Nothing from April 
>and May 1987 was ever archived to my knowledge. If I'm wrong, send them my
>way... I am willing to contribute a tape to a site on the internet that is 
>willing to make the complete archives available.  
>
>Submissions prior to July, 1987 have no auxiliary header information at all.
>At the time, the group's original charter was in full force, and archiving 
>was not considered to be important.  These articles may be assigned 
>auxiliary headers in the future, but for now ...
>
>--------------------
>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.misc 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:        schizo.samsung.com
>Contact:     Andy Rosen (rosen@samsung.com)
>Location:    Andover, MA
>Modems:      NA
>UUCP:        NA
>FTP:         Anonymous
>Mail Server: None
>Additional:  Files are stored by volume number, archive name and are
>             compressed.  Volumes 1 through 6 and 11 through 15 are present.
>             Examples:
>               /pub/usenet-archives/comp.sources.misc/volume15/fb/part01.Z
>               /pub/usenet-archives/comp.sources.misc/volume6/gone-2.0.Z
>
>
>Site:        slug.pws.bull.com [128.35.10.203]
>Contact:     Warren Lavallee <warren@pws.bull.com>
>Location:    Billerica, MA.  (NEARnet)
>Modems:      T2500
>UUCP:        anonymous UUCP NOT available.
>FTP:         anonymous ftp 24 hours day.  limit 6 users at a time
>Mail Server: NOT available
>Additional:  Due to internal restructuring, this site may not be
>             accessable some times over the next month.
>             Carry FULL comp.sources.* archives (since the
>             beginning).  Usenet archives are currently taking 170M.
>
>
>Site:         uunet.uu.net 
>Contact:      Kent Landfield (kent@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.misc, and 
>              I will be maintaining them.  Volumes 1 and 2 are not available, 
>              and some earlier versions of programs have been removed due to 
>              space considerations.  You can also use 1-900-GOT-SRCS to access 
>              this archive.
>
>
>            ************************
>                 U S A - CENTRAL 
>            ************************
>
>Site:         sparky
>Contact:      Kent Landfield (kent@sparky.imd.sterling.com)
>Location:     Omaha/Bellevue, NE
>Modems:       Telebit 
>UUCP:         On request
>FTP:          Not Yet..
>Mail server:  No
>Additional:   Tapes made on request
>
>
>Site:         sir-alan
>Contact:      mikes@iuvax.cs.indiana.edu (812-855-3974 days 812-333-6564 eves)
>Location:     Bloomington, IN
>Modems:       Telebit (812-333-0450)
>UUCP:         Anonymous uucp
>FTP:          Coming..
>Mail server:  No
>Additional:   Archive site for comp.sources.[games,misc,sun,unix,x], 
>              some alt.sources, XENIX(68K/286/386)
>              uucp-anon: ogin: nuucp password: anon-uucp
>              uucp-anon directory: /u/pdsrc, /u/pubdir, /u/uunet, 
>              help in /u/pubdir/HELP 
> 
>
>Site:         wuarchive.wustl.edu [128.252.135.4]
>Contact:      Wuarchive Maintainers <archives@wugate.wustl.edu>
>Location:     Saint Louis, Missouri.  Connected to MIDnet Regional.
>UUCP:         Subscription UUCP access available ($300.00/year flat fee)
>Modems:       Telebit Trailblazer Plus and T2500.
>FTP:          Anonymous FTP.  T1 connectivity - 24 hours/day, 7 days/week.
>Mail Server:  Not yet available.
>Additional:   Access during all hours is encouraged.  Plenty of available
>              bandwidth.  Wuarchive has everything! :-) :-)
>
>
>            *****************************
>                 U S A - SOUTHWESTERN 
>            *****************************
>
>Site:        asuvax!hrc
>Contact:     Dan Troxel hrc!dan, hrc!archives
>Location:    Phoenix, Arizona USA
>Modems:      Telebit Plus, Microcom AX/9624c
>UUCP:        N/A
>FTP:         N/A
>Mail Server: hrc!archives - ask for 'send help'.
>Additional:  hrc archives: alt.sources, comp.sources.unix, comp.sources.games,
>             comp.sources.misc, comp.sources.x, comp.sources.sun, gnu, news, 
>             you get the idea...
>
>The archive server is a mail-response program. That means that you mail it a
>request, and it mails back the response. Requests are processed once a night.
>
>The archive server has several commands. Each command must be the first word 
>on a line. The archive server reads your entire message before it does anything,
>so you can have several different commands in a single message. The archive
>server DOES NOT recognize the "Subject:" header line.
>       ^^^^ ^^^
>
>"send path" command: The "send path" command exists to help the server get
>   any requests to you accurately. You *MUST* include the full path to your 
>   site from the hrc box or your path relative from a "major" site on the 
>   very *FIRST* line. 
>
>   When you put in a "send path" command, everything that the server
>   mails to you will be mailed to that address, rather than to the
>   return address on your mail. For example, if you reside at
>
>       rutgers!jj
>
>   then to get mail from hrc to you, you would say
>
>       send path asuvax!noao!ncar!rutgers!jj
>
>   then all mail sent by the server will be sent to that address.
>
>"send help" command: The "send help" causes the server to
>   send you the help file.  This should be your first step in getting
>   a complete help file.
>
>The archives are organized into a series of directories and subdirectories.
>Each subdirectory has an index. The index will also give you the last date of 
>entry. This will help you to know when more files were entered into the 
>archive. To get a general list of where the indexes are, send the following 
>message containing the line:
>
>   send main.index
>
>When you get the index back, it will give you the names of all of the indexes
>and where to locate them. 
>
>
>            ************************
>                 U S A - WESTERN 
>            ************************
>
>Site:         aeras
>Contact:      Rob Simon (simon@aeras)
>Location:     San Jose, CA
>Modems:       1200, 2400, Telebit
>UUCP:         Anonymous 
>FTP:          None
>Mail server:  None
>Additional:   SnailMail tapes (Under duress)
>     Systems/L.sys information:
>     aeras Any 1200  4089439152 "" "" ogin:--ogin: uugarch word: freebee
>     aeras Any 19200 4089439246 "" "" ogin:--ogin: uugarch word: freebee
>     aeras Any 2400  4089439396 "" "" ogin:--ogin: uugarch word: freebee
>          
>     Suggested places to get additional information:
>         /u3/archive/sources/LISTING
>     LISTING contains the names of all the programs stored in the 
>     archives, and the sizes.  Note: all archives have probably been 
>     stored in compressed form, with 12 bit compression (for machines 
>     that can't handle 16 bit).  All multiple file programs have been 
>     stored in separate directories, then compressed.
>     
>     More information about the files stored in a particular volume are 
>     kept in files called LOGFILE. Such as:
>         /u3/archive/sources/x/vol1/LOGFILE
>     would be the one to get to examine the exact contents of volume 1
>     of the x section.  Additional information from files:  sample command 
>     to recover files:
>         uucp aeras!/u3/archive/sources/games/vol1/LOGFILE /tmp/.
>     Special note:  wild cards have been proven to not be reliable, so 
>                    to assure success they are not recommended tools.
>
>
>Site:        lll-winken.llnl.gov (128.11514.1)
>Contact:     Joe Carlson (carlson@lll-winken.llnl.gov)
>Location:    San Francisco, CA
>Modems:      Not Available
>UUCP:        Not Available
>FTP:         Anonymous FTP
>Mail Server: Account address of the automated mail server if available.
>Additional:  Articles are stored by X-Archive: index in subdirectories of 
>             comp.sources.misc/volN.  Note that these archives start from
>             9/87; anything from April to August isn't available.  
>  *NOTICE*:  lll-winken is not permitting anonymous FTP for the time being.  
>             The archives are temporarily available on polaris.llnl.gov,
>             128.115.14.19.  
>
>
>            ************************
>                    Australia
>            ************************
>
>
>Site:        ftp.Adelaide.EDU.AU [129.127.40.3]
>Contact:     Mark Prior <mrp@ITD.Adelaide.EDU.AU>
>Location:    The University of Adelaide
>             Adelaide, AUSTRALIA
>Modems:      N/A
>UUCP:        N/A
>FTP:         Anonymous ftp, ftp.Adelaide.EDU.AU [129.127.40.3]
>Mail Server: N/A
>Additional:  Also available via ACSnet fetchfile (sirius.ua.oz)
>
>             The comp.sources.misc archive is in the subdirectory
>             pub/sources/misc and is archived in compressed form by
>             issue number (subdirectories for each volume). The
>             file INDEX in the pub/soures/misc directory lists the
>             issues available.
>
>             We will also make tapes (1600/6250bpi) or QIC-11/24 if
>             you supply the tape AND a return mailer. No promises
>             for speed for this though.
>
>
>            ************************
>                    France   
>            ************************
>
>Site:        irisa.irisa.fr 
>Contact:     Didier Lamballais (lamballais@irisa.fr)
>             Raymond Trepos    (trepos@irisa.fr)
>Location:    Institut de Recherche en Informatique et Systemes Aleatoires
>	     Campus universitaire de Beaulieu
>	     35042 Rennes Cedex
>	     FRANCE
>UUCP:        Not Available
>Modems:      Not Available
>FTP:         Anonymous FTP (login: ftp or anonymous, Password: your e-mail address)
>Mail Server: No mail Server
>Additional:  Additional information pertaining to accessing the archive.
>	     List of archived newsgroups :
>	     alt.sources, comp.binaries.atari.st, comp.binaries.ibm.pc,
>	     comp.binaries.mac, comp.sources.atari.st, comp.sources.games,
>	     comp.sources.mac, comp.sources.misc, comp.sources.sun,
>	     comp.sources.unix, comp.sources.x, comp.sys.sun
>	     under "News" directory.
>	     Some local stuff and RFCs are also available.
>
>-- 
>Kent Landfield                   INTERNET: kent@sparky.IMD.Sterling.COM
>Sterling Software, IMD           UUCP:     uunet!sparky!kent
>Phone:    (402) 291-8300         FAX:      (402) 291-4362
>Please send comp.sources.misc-related mail to kent@uunet.uu.net.


-- 
Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC
UUCP: ...dukcds!wolves!ggw   ...mcnc!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu     ggw%wolves@mcnc.mcnc.org
[The line eater is a boojum snark! ]           <standard disclaimers apply>

allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/05/91)

As quoted from <1991Jan4.014843.1298@wolves.uucp> by ggw%wolves@cs.duke.edu (Gregory G. Woodbury):
+---------------
| kent@sparky.IMD.Sterling.COM (Kent Landfield) writes:
| >Archive-name: intro16
|               ^^^^^^^^^^  and here is the nit!
| 
| All the other postings "Archive-Name:" headers are of the form
| 
| 	directory/part
| 
| EXCEPT FOR THESE DARN INTROS!
+---------------

My version would have been volume16/v16welcome, followed by
volume16/v16index/part01 ... part04.

However, the person you're complaining about may know more about archiving
than anyone else on the net.

BTW, any particular reason why you quoted the *entire* welcome message?

++Brandon
-- 
Me: Brandon S. Allbery			    VHF/UHF: KB8JRR on 220, 2m, 440
Internet: allbery@NCoast.ORG		    Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR			    AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

ggw%wolves@cs.duke.edu (Gregory G. Woodbury) (01/06/91)

In article <1991Jan5.015342.19460@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes:
>As quoted from <1991Jan4.014843.1298@wolves.uucp> by ggw%wolves@cs.duke.edu (Gregory G. Woodbury):
>
>BTW, any particular reason why you quoted the *entire* welcome message?

No, no particular reason.... I like looking like a fool... :-)
<note note - joke!  humor impaired persons stop now!>

I made a mistake while in a very confusing situation at home and forgot
to delete the rest of the text in the file before sending the article
when I got back to writing it an hour later.

Sorry for the wasted bandwidth.
-- 
Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC
UUCP: ...dukcds!wolves!ggw   ...mcnc!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu     ggw%wolves@mcnc.mcnc.org
[The line eater is a boojum snark! ]           <standard disclaimers apply>

kent@sparky.IMD.Sterling.COM (Kent Landfield) (01/07/91)

In article <1991Jan4.014843.1298@wolves.uucp> by ggw%wolves@cs.duke.edu (Gregory G. Woodbury) writes:
> In article <1991Jan3.063119.4373@sparky.IMD.Sterling.COM>
> kent@sparky.IMD.Sterling.COM (Kent Landfield) writes:
> >Posting-number: Volume 16, Info 1
> >Archive-name: intro16
              ^^^^^^^^^^  and here is the nit!
> All the other postings "Archive-Name:" headers are of the form
> 	directory/part
> EXCEPT FOR THESE DARN INTROS!
> This needlessly complicates the scripts used to stash articles for
> archiving.  Additionally, it clutters up the top level of the archive
> directory until someone goes in and cleans it up by hand.

In article <1991Jan5.015342.19460@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes:
# My version would have been volume16/v16welcome, followed by
# volume16/v16index/part01 ... part04.
# However, the person you're complaining about may know more about archiving
# than anyone else on the net.

Let's not go overboard here.. :-) :-)  Greg brings up a problem and I
was the cause of it. Brandon placed the indexes in subdirectories very
nicely. Greg's archiving scripts were apparently caught off guard when
I changed where comp.sources.misc placed the initial INFormational postings.
To all the sites that may have been caught by this, sorry.  

Greg's nit was directed towards the *initial* INF postings but the problem 
will exist for all INF postings.  Say I post a notice of a new archive 
site prior to a new volume's INF postings. Where do I put that ?  If 
archivers were caught off guard with the initial INF posting, they are
also going to have trouble when I post other INFormational posting 
during the course of the volume's postings. *WARNING Will Robinson*.. :-)

While developing rkive I researched each comp.sources newsgroup archives
to examine how the moderators were utilizing the Archive-name: auxiliary
header. For most source groups, the INF postings have been placed in the 
top level of the volumes's archive directory with source posting located 
in subdirectories from there (at least in the later volumes :-) ).  To 
this point, comp.sources.misc was an exception. 

Greg writes:
> I would like to suggest that the volume introductions and informational
> postings all get assigned a directory of "volNNN/xxxxxx"  where the
> xxxxx becomes something like "intro1", "intro2", index01, index02...
> and the info postings get info.01, etc....

OK, a standard naming convention for the directory that stores the INF postings
based on volume, but don't we already have that ?  This type of usage takes 
these files out of the volume's base directory but it clouds the separation 
between source and INF postings. When source gets put in subdirectories and 
*only* INF postings are placed directly in the volume directory, there is a 
clean and visible separation.  I too have viewed the base directory of each 
volume as the place where the moderators should store the postings that are 
non-source related and only informational in scope.  In this manner, a user 
is able to immediately locate all INFormational postings for a volume without 
having to search through (or cd to) subdirectories to find or read them. This 
was the rationale for the recent change in comp.sources.misc.  A secondary 
consideration was an attempt to standardize the location where all INF postings
would reside so that c.s.m need not be an exception. 

Greg writes:
> Or am I totally missing out on "the official way to archive" these
> postings?

The part of the INF posting in most source groups describing the format and 
use the Archive-name: auxiliary header line does not deal with INF postings.
The description makes it sound like *all* posted articles will be placed
in a subdirectory somewhere under the volume directory even though that 
has not been the practice except in c.s.m.  I will correct this in the next 
volume's initial INF postings.  

Worst case Greg, you could always try rkive... :-) (Sorry, couldn't resist ;-))

			-Kent+
-- 
Kent Landfield                   INTERNET: kent@sparky.IMD.Sterling.COM
Sterling Software, IMD           UUCP:     uunet!sparky!kent
Phone:    (402) 291-8300         FAX:      (402) 291-4362
Please send comp.sources.misc-related mail to kent@uunet.uu.net.

allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/08/91)

As quoted from <1991Jan6.050257.23506@wolves.uucp> by ggw%wolves@cs.duke.edu (Gregory G. Woodbury):
+---------------
| In article <1991Jan5.015342.19460@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes:
| >BTW, any particular reason why you quoted the *entire* welcome message?
| 
| I made a mistake while in a very confusing situation at home and forgot
+---------------

Apology accepted.

I want to make a small correction of my own:  I claimed that the Welcome!
message would have gone out as volume16/v16welcome.  In fact, the "volume16/"
is not sent out, and to avoid having to muck around with two different patch
schemes I decided to make *everything* multipart:  it would in fact have been
"v16welcome/part01", and the archive list "v16index/part01", etc.  (I
misremembered because I didn't do those; I let a program do them for me.  Much
easier to talk to this:

	(prompt with many options)? s
	Newsgroup: <cr>
	Is this an Administrivia posting (N)? y
	Archive-name: v16welcome

and let the "csmsend" program figure out how to talk to inews and store the
compressed archive entry and update archive-name and archive contents files.
I mean, what else is being a programmer good for?  ;-)

++Brandon
-- 
Me: Brandon S. Allbery			    VHF/UHF: KB8JRR on 220, 2m, 440
Internet: allbery@NCoast.ORG		    Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR			    AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/11/91)

As quoted from <1991Jan7.064842.4337@sparky.IMD.Sterling.COM> by kent@sparky.IMD.Sterling.COM (Kent Landfield):
+---------------
| While developing rkive I researched each comp.sources newsgroup archives
| to examine how the moderators were utilizing the Archive-name: auxiliary
| header. For most source groups, the INF postings have been placed in the 
| top level of the volumes's archive directory with source posting located 
| in subdirectories from there (at least in the later volumes :-) ).  To 
| this point, comp.sources.misc was an exception. 
+---------------

I received a number of requests from archivers to make INF postings compatible
with other postings with respect to the Archive-name headers and archive
storage.  I guess they weren't running Rkive... de gustibus non est
disputandem, and I'm not in the business of writing archivers, so I went ahead
and changed it.  (In fact, at the time INF postings ("Administrivia") were
special-cased, so the fix was simply to remove the special-casing from the
code to my poster.)

I understand your desire to put info postings in a special area, but by and
large I only had two types of info postings:  the introduction to each volume,
which had fixed names (vNNwelcome, vNNindex) and special postings which by and
large didn't need to be archived at all, although they were assigned archive
names for completeness.  (A list of pending submissions is pretty meaningless
after they have all been sent out.)

++Brandon
-- 
Me: Brandon S. Allbery			    VHF/UHF: KB8JRR on 220, 2m, 440
Internet: allbery@NCoast.ORG		    Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR			    AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY