Usenet 1994 October

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / misc / volume26 / intro26 < prev next >

Wrap

Text File | 1991-11-16 | 50KB | 1,046 lines

Newsgroups: comp.sources.misc From: kent@sparky.imd.sterling.com (Kent Landfield) Subject: v26INF1: Introduction to comp.sources.misc Message-ID: <1991Nov17.062439.3486@sparky.imd.sterling.com> X-Md4-Signature: dc1ff943682f0ec8b56e0b2a656e1208 Date: Sun, 17 Nov 1991 06:24:39 GMT Approved: kent@sparky.imd.sterling.com Submitted-by: kent@sparky.imd.sterling.com (Kent Landfield) Posting-number: Volume 26, Info 1 Archive-name: intro26 Now that was *another* quick volume... Keep 'em coming gang! :-) Since my posting to comp.sources.d about the suggested improvements, I have received 9 responses via email. This is not really that great a number :-) but I thought that I would pass along the tone of the responses. 1. I should post this introductory message in digest format as specified in RFC 1153. This would not change any of the other INFormational postings, just the introduction. Responses have been positive but on the verge of not really caring either way. 2. I should start posting 125 articles per volume instead of the normal 100 (to 104) articles. Same type of responses as the first suggestion... 3. I should post a maximum limit of 800K worth of articles in any given 24 hour period. This would increase the amount of articles posted per day in an effort to get more articles out when they are available. Everyone seems to be in favor of larger daily throughput iff the flow can be maintained. That is not up to me, that is up to the contributing community. But, judging from the speed in which the last two volumes were produced, along with the current inbound queue, I don't see any immediate problem with lack of things to post. *Please* take the time to send me your response. I do value your opinions and need to hear how you feel I should proceed... Thanks. On a different note... I would like to thank Rich Salz for all of his volunteer efforts as moderator of comp.sources.unix. Rich's influences have been felt far beyond c.s.unix. He fostered the way in which sources are distributed and archived on the net and we have all benefited from that... I would also like to thank him for all the help he has given me through the years. First for answering my questions while I was developing rkive and then when I took over comp.sources.misc. He really *has* made a difference. Thanks Rich! ==== This is the first of six 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, fourth and fifth postings together comprise the index of previously posted software. The sixth article is a cross-index of patches that have been posted to this newsgroup. As always, I am 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 group is run in a generally informal manner. *Any* program source code will be accepted. 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. 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. The initial moderator of comp.sources.misc was Brandon Allbery. 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 non-source. I am striving to get things out as quickly as possible. Testing of the source is not done. I will, however, assure that postings are in shar format and that shar'ed submissions can be unshar'ed correctly. If a patch is submitted, I assure that the patch can be applied to the sources it is to patch. If the submission is something that needs testing, it probably should be sent to comp.sources.unix or comp.sources.reviewed instead. (Send submissions to comp-sources-unix@<backbone> or to comp-sources-reviewed@<backbone> in that case.) -------------------- Subject: Deciding where to post your software There are four 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. Second is comp.sources.reviewed. It is using a Peer Review process to accept or reject submissions. Similar to the process used for academic journals, submissions are sent to a moderator who then sends the sources to Peer Review volunteers for evaluation. The Reviewers try to provide a timely evaluation of the software by compiling and running it on their machine. If the Moderator and Peer Reviewers judge a submission to be acceptable, the sources are posted along with the written comments provided by the Reviewers. If a submission is not found to be acceptable, the author is provided with the Reviewers' comments, and they have the option of addressing those comments and submitting the sources again. The benefits of this group are that your software will be thoroughly tested by multiple reviewers on multiple systems prior to it being posted to the world. 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. (It is suggested that you add an "Archive-name:" to your postings so as to help out those who do archive the group.) You're free to just pipe a source file to inews if the fit takes you (not that I recommend it). 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. 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 grew as a policy was adopted of letting the group be controlled more by its users (submitters, readers, archivers) than by "moderative fiat". 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 non-source, discussion postings; the disadvantages are that there is a slight delay caused by having to filter stuff through the moderator. 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: if your software is in need of beta-testing and it is not quite ready for mainstream archiving, post it to alt.sources. After the beta period is over, submit it to the appropriate comp.sources.whichever group for worldwide distribution and archiving. In general, 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 an specialized sources group like comp.sources.sun or comp.sources.amiga, and X-Window based applications can be posted through comp.sources.x. Released, major programs usually go to comp.sources.unix, and comp.sources.misc is used for the rest. Remember though, it's up to you to decide to which newsgroup a your submission should be posted to. -------------------- 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 "informational 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. The first few lines of an article are auxiliary headers that look like this: Submitted-by: kent@sparky.IMD.Sterling.COM (Kent Landfield) Posting-number: Volume 14, Issue 82 Archive-name: lc/part01 The "Submitted-by" line in each issue is the author of the program. IF YOU HAVE COMMENTS ABOUT AN ISSUE 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. All source postings will be treated as multi-part postings have been done in the past. All source postings will be stored in a subdirectory within the volume directory. This gives me a place to store patches as well as allows me to have more informative archive names without having to worry how many spaces the part numbering, patch indicator or compression suffix will take up. Postings will have names that look like this: Source posting Archive-name: lc/part01 Patch posting Archive-name: lc/patch01 Note that the part number and patch number will be zero padded for convenience sake as was requested by several people. Also, note that the "part number" given in the title will be used to give the reader an indication of the total number of parts that make up the complete set of sources. The example below shows that this is part 21 of a 23 part submission. v17i102: calentool - day/week/month/year-at-a-glance SunView tool, Part21/23 Informational (INF) postings such as this posting will not be stored in a subdirectory as are the source postings. INF postings will have archive names such as indx22v1-7 and patchlog22. From an archiving perspective, archive names for all INFormational postings will be specified so as to store the INF postings directly in the volume's base directory. Archive names for source postings will be specified so as to store the sources in subdirectories within the volume's base directory. 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 or Patch-To: rkive: Volume 22, Issue 122,125-127 If a new release is posted instead of a large set of patches, the new posting will contain a Supersedes: header line with a format similar to the Patch-To: header. Supersedes: syntax Supersedes: package-name: Volume X, Issue x[-y,z] Supersedes: example Supersedes: rkive: Volume 22, Issue 122-127 The Supersedes: line is helpful for cleaning archives by providing a pointer to previous versions that the archive administrators can then remove from their archives. The Environment: auxiliary header line is included to give you a quick indication which resources are required to use a particular issue. In a newsgroup not restricted to one type of operating system, one type of machine or one type of architecture there is a need for this type of information in the header. The intent is to provide you more external information about the package contained within the posting. This allows you to determine if the package has special requirements that may prevent you from using it. It is extremely irritating to take the time to unpack something just to find out that you can't use it. The news Keyword: line has been used to a certain extent for this, but if news articles are saved with 'w' rather than 's' from "rn" then the news headers don't get saved with the article. Environment: syntax Environment: Keyword [, keyword ..] Environment: example Environment: SunView, XView, X11R4, termcap The keywords usage is case insensitive. There is also a NOT indicator (e.g. !AIX) so that the moderator can specify that the package runs on everything "but" the specified keyword. The following is a list of keywords used within articles that have been posted to c.s.misc and their meanings. Keywords are added to this list on a first-use basis. Operating Systems: AIX - should operate on any AIX AIX3.1 - should operate on AIX Version 3.1 AMIGA - should operate on AMIGA OS ATARI - should operate on an Atari ST BSD - should operate on any BSD based unix COHERENT - should operate on Mark Williams Coherent OS DOS - should operate on DOS (oops) ISC-UNIX - should operate on ISC UNIX ISC - should operate on ISC UNIX (oops) MS-DOS - should operate on MSDOS OS/2 - should operate on IBM's OS/2 OSF/1 - should operate on OSF/1 SCO - should operate on SCO UNIX SCOXENIX - should operate on SCO XENIX SUNOS - should operate on SUNOS SYSV - should operate on System 5 SYSVR2 - should operate on System 5.2 SYSVR3 - should operate on System 5.3 SYSVR4 - should operate on System 5.4 VMS - should operate on VMS UNIX - should operate on any unix system... (right...) ULTRIX - should operate on Ultrix XENIX - should operate on XENIX OSs Language Support: (C is the default so not specified) ANSI-C - Requires ANSI compatible C compiler AWK - pattern scanning and processing language C++ - Requires C++ Programming language Flex - fast lexical analyzer generator Fortran - Written in Fortran Icon - Written in the Icon Programming Language INET - Requires BSD networking support LaTex - Requires the LaTex support MIPS - Mips C compiler Pascal - Requires a pascal compiler Perl - Practical Extraction and Report Language Pro*C - Requires Oracle Pro*C compiler TurboC - Requires Turbo C Windowing Support: Curses - Requires the curses library Sunview - Requires the Xview library Xlib - Requires the X Windows library Xview - Requires the Xview library System Support: System Utilities needed Cnews - USENET network news Csh - The C-Shell command interpreter C-shell - The C-Shell command interpreter (oops) DBX - BSD based source-level debugger getopt - parse command options in shell scripts MMDF - MMDF mail transport Oracle - Oracle Database pathalias - mail routing tool Sendmail - BSD based mail transport Smail - Smail3 mail transport tput - Initialize a terminal or query the terminfo database Emacs - GNU Emacs Functionality Support: System supported functionality symlink - System supports symbolic links INET - Requires BSD based networking facilities Hardware Tested on: SGI - Runs on Silicon Graphics systems DEC - Runs on DEC Risc Workstations Cray2 - Runs on a Cray2 supercomputer with UniCos Alliant - Runs on Alliant minisupercomputers Convex - Runs on Convex minisupercomputers Amdahl - Runs on Amdahl mainframes Sun - Runs on Sun Microsystems Workstations Mac - Runs on Mac PC - Runs on PCs or PC compatibles running DOS MIDI - You will need a MIDI to run this. HPLJ - HP Laserjet II or III printer or compatible CDROM - Requires a cdrom player. General Notes: !16BIT - Don't try to to run on a 16 bit machine (8088,186,286) 32BIT - Requires 32 Bit Architecture As you can probably see from my mounting mistakes, I have not yet automated [dummy-proofed :-)] the process of keyword selection within my posting software. Its coming... It really is. :-) 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. 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: 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. I have changed my policy of notification when sources are submitted to comp.sources.misc. In the past I have not notified everyone that their submissions were received. This has caused some problems that could have been avoided if both parties knew how to deal with the other. When you submit a package to comp.sources.misc I will respond letting you know that I have received it. If you do not hear from me in 72 hours, there may be a problem! I hope that by making everyone aware of this new policy, the newsgroup will get a better throughput as authors aren't waiting for me to respond when I do not know to respond... 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 heavily 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, *please* send me a Subject: to be used in posting your 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 you have to live with what I make up... :-) Fourth, *please* send me an archive-name or package name that you want the submission archived by. If you do not send me one then I get to name your sources in the archives... Do you see a pattern forming here... :-) Fifth, I need Environment: header information. If your submission has limitations, such as it does not run on SYSV or limited to a specific version of SUNOS, or whatever the conditions, *PLEASE* inform me so that it can be included in the Environment: header line. This way people who are not able to run your submission will not take the time to ftp or unpack it. I will try to determine the Environment: information if you do not supply any but if you want it right... If the submission is a complete reposting of a previous posted package, let me know that the posting is superseding your previous submission. Each of the postings should contain a "blurb" that describes what the posting is/does/contains. This should only be a paragraph or two. When you submit your sources, please include the blurb on the first part. If you do not write it yourself, I will have to grab it out of the submission somewhere. 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... :-( I have been receiving a number of messages with uucp addresses that are not reachable. Please specify a domain based address if possible. If you do not know what your domain based address is, please ask the administrator of your site or that of your upstream news feed. 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. Other considerations: The posting software I use reads the submission and prompts me for all the information needed to post. It uses information in the header supplied by you as the default information. The Subject: line is usually munged. The auxiliary headers supplied in the submission are used where appropriate. The following headers are passed through the software untouched. Keywords:, Organization:, Reply-To: and Summary: If you supplied them, they are put into the posted article. Again, Please let me know what should go in the Environment: line. If you don't take the time to do that I have to try to determine what is accurate. Sometimes that's hard to do without full blown testing. Archive-name:, Subject:, and Environment: are the three pieces of information that I really need. Otherwise I get to make up what is supplied there. Don't complain to me if I get it wrong and you didn't take the time to send me the correct info in the first place... If you did send me the information and I got it wrong, give it to me with both barrels... ----------------- 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 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. 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: 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. Please supply 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. -------------------- 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 should 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. That just forces a delay in the right person getting them as I will forward them on to the author. 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: Newsgroup Status Information. You should subscribe to comp.sources.d. In some newsgroups, postings such as "I will be out of town..." and "What's in the queue to post..." have been posted as INF postings with an Archive-name: of /dev/null or .junk. I will not post these types of messages to c.s.misc due to the limited amount of time that information of this type is useful. I will post these kinds of messages to comp.sources.d as the need arises. In this manner, the informational c.s.d postings can expire as they should and will not be archived taking up disk space forever. -------------------- Subject: Accessing the archives The complete archives are fairly large; an average volume is four megabytes. There are several active archive sites around the net. I am currently trying to locate archive sites in Europe, and Asia. If you are interested *please* contact me. Some sites below will send tapes through the mail. For those sites, send the appropriate type of tape media 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. You will need to contact the individual archive sites to determine if they can support your type of media. 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. Coming RSN... I have as complete a set of archives as I have found. I have all the issues listed in the indexes except for the first volume. If you have articles from volume 1 please send me a list of articles so I can see if there are some I do not have. 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 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. **** Work-in-progress: **** **** Volume 1 and 2 articles are currently being assigned auxiliary headers. **** I am planning on making the corrected articles available to archive **** sites and anyone else who wish them when I have completed the task. **** If you want to have me notify you when I am done, send me some mail. -------------------- 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 UUCP; 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. As an example, to receive the index from the comp.sources.misc archives on uunet, send the following one line as the body of a message to uunet!netlib. send index from comp.sources.misc IMPORTANT TO REMEMBER: Mail Based Archive Servers (MBAS) are there for the convenience of the community and are *easily* abused. Please do not request to have a MBAS send you GCC or X11R4. A good deal of this traffic goes through intermediate sites that have not advertised this service. You would be taking resources away that are not yours to take... This type of irresponsibility will do nothing but irritate the sites that feed you and may jeopardize your facilities in the process... -------------------- 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: 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. PLEASE NOTE: Mail Based Archive Servers (MBAS) are there for the convenience of the community but are too easily abused. Because of this, I can not, in good conscience, list archive sites whose *sole* access is mail based. If you can't supply anonymous ftp as a secondary method for accessing your archives then consider uucp. It is easy enough to set up a uucp account for archive access with the appropriate security to protect your other system resources. -------------------- 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. NA - Not Available ************************ U S A - EASTERN ************************ Site: bhjat Contact: Burt Janz (bhjat!bhj) Location: Nashua, NH UUCP: Anonymous uucp (login: nuucp password: nuucp) Modems: 2400 Baud N81 - (603) 889-6154 FTP: N/A Mail Server: Not yet available. Additional: Index location: /usr5/archives/ls-lR.Z Archiving c.s.games-misc-unix-x, alt.sources, comp.sys.handhelds 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: NA FTP: anonymous ftp 24 hours day. limit 6 users at a time Mail Server: NA Additional: Due to internal restructuring, this site may not be accessible 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 and 1-900-GOT-SRCS FTP: anonymous ftp Mail server: netlib@uunet Additional: UUNET is keeping archives in ~ftp/comp.sources.misc, and I will be maintaining them. Volume 1 as well as shareware which has been posted to the group are not available from uunet. Volume 1 will be put back up in the near future. In the mean time, if you need any of those issues please send me some mail and I will arrange to get them to you. For more information concerning the archives on uunet, send an email message netlib@uunet.uu.net with the following as the body of the message: send index from comp.sources.misc 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: NA Mail server: NA 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: NA 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: NA Additional: Access during all hours is encouraged. Plenty of available bandwidth. Wuarchive has everything! :-) :-) ************************ U S A - WESTERN ************************ Site: aeras Contact: Rob Simon (simon@aeras) Location: San Jose, CA Modems: 1200, 2400, Telebit UUCP: Anonymous FTP: NA Mail server: NA 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: NA UUCP: NA 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: NA UUCP: NA FTP: Anonymous ftp, ftp.Adelaide.EDU.AU [129.127.40.3] Mail Server: NA 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. ************************ Canada ************************ Site: array.UUCP Contact: Rob Marchand, rob@array.UUCP || ...uunet!attcan!lsuc!array!rob Location: Toronto, Ontario, Canada Modems: 2400 baud, perhaps TB in the future (hopefully :-) UUCP: On Request. FTP: NA Mail Server: NA Additional: I have most stuff for comp.sources.unix, comp.sources.misc, comp.sources.bugs and alt.sources. ************************ 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: NA Modems: NA FTP: Anonymous FTP (login: ftp or anonymous, Password: your e-mail address) Mail Server: NA 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.