Source Code 1994 March/Source_Code_CD-ROM_Walnut_Creek_March_1994.iso/compsrcs/3b1/volume02/info1

Internet Message Format | 1992-03-16 | 17.3 KB

Path: comp-sources-3b1
From: [e-mail] (David H. Brierley)
Subject:  v02INF1:  Introduction to comp.sources.3b1
Newsgroups: comp.sources.3b1
Approved: [e-mail]
X-Checksum-Snefru: 526a7b50 aeb7019e 09636c1e 4c36f801

Submitted-by: [e-mail] (David H. Brierley)
Posting-number: Volume 2, Info 1
Archive-name: info1

Welcome to comp.sources.3b1.  This message contains information about the
structure of the newsgroup, archive sites, and other junk.  This group is
modeled after the newsgroup comp.sources.misc with the difference being that
this group is intended for programs that are specific to the AT&T 3B1
computer.  This computer is known by several other names as well, including:
AT&T Unix-pc, AT&T PC7300, AT&T Unix-pc/7300, Convergent Technologies S/50,
and Convergent Technologies Safari.

This information message was shamelessly stolen from the comp.sources.misc
newsgroup.  Thanks to Rich Salz for writing the software used for these
postings and the original version of this message, and thanks to those who
came after Rich for their contributions.  This message is probably extreme
overkill for this newsgroup but I figured that since all I had to do was
edit the old one I could afford to go wild.

I am always looking for suggestions on how to improve the usefulness of the
newsgroup. *Please* do not hesitate to send suggestions to
[e-mail].

Dave.

--------------------
Subject:  Introduction

Comp.sources.3b1 is intended for programs which are specific to the AT&T 3B1
computer. This group will be run in an informal fashion.  In general, any
program source code which is pertinent to the AT&T 3B1 will be accepted, but
discussion and "sources wanted" requests will be discarded with a message back
to the sender advising him/her to post to the correct newsgroup.  Programs
which are not specific to the 3B1 are probably better off being sent to
comp.sources.misc or comp.sources.unix but they can be posted here if you are
insistent.

As stated above, the primary reason a submission will be rejected is if it is
a non-source.  I, as the moderator, am striving to get things out as quickly
as possible while not posting non-sources; testing is not done.  If it's
something that's worth testing, it probably belongs in comp.sources.unix
instead.  (Send submissions to comp-sources-unix@<backbone> in that case.)
Testing may be done in the future.

--------------------
Subject:  The structure of comp.sources.3b1 articles

Each posting in comp.sources.3b1 is called an "issue"; there are roughly 100
issues to a volume.  The division is arbitrary, and has varied greatly in the
past.  There are two types of articles in comp.sources.3b1; sources and
"information postings."  They can be distinguished by the subject line:

   Subject:  v01INF1:  Introduction to comp.sources.3b1

This first word in the title identifies this as the first info posting of
volume one.  Similarly, the subject line shown below:

   Subject:  v01i001: xtclient: use a 3b1 as a layers terminal, part01/04

identifies this as the 1st source article in Volume 1.  In the above example,
the Part01/04 indicates that this is the first part of a four part posting.
All sources are broken up into pieces.  This is done so that there will be a
proper storage directory when patches are issued.

The first few lines of an article are auxiliary headers that look like this:

   Submitted-by: [e-mail]
   Posting-number: Volume 7, Issue 82
   Archive-name: os2-login/part01

The "Submitted-by" is the author of the program.  IF YOU HAVE COMMENTS ABOUT
THE SOURCES PUBLISHED IN COMP.SOURCES.3B1, THIS IS THE PERSON TO CONTACT.
When possible, this address is in domain form, otherwise it is a UUCP bang
path relative to some major site such as "uunet."

The second line repeats the volume/issue information for the aide of NOTES
sites and automatic archiving programs such as rkive.

The Archive-name is the "official" name of this source in the archive.  Large
postings will have names that look like this:

   Archive-name: tipx/part01

Please try to use this name when requesting that sources be mailed to you.
Also, note that the "part number" given in the title, and the archive name
given in the auxiliary header need not be identical.

Official patches will be posted as "archname/patchNN".  Single-part
submissions are treated as multi-part submissions for this purpose, with a
single "part01" component.

To support the tracking of patches the Patch-To: line is used in c.s.3b1.  The
Patch-To: line exists for articles that are patches to previously posted
software. The Patch-To: line only appears in articles that are posted,
"Official", patches. The initial postings do not contain the Patch-To:
auxiliary header line.

Patch-To: syntax

   Patch-To: package-name: Volume X, Issue x[-y,z]

Patch-To: examples. These are examples and do not reflect the accurate
volume/issue numbering for rkive.

In the first example, the article that contains the following line is a patch
to a single part posting.

   Patch-To: rkive: Volume 22, Issue 122

This example shows that the 122-124 indicates the patch applies to a multi-
part posting. The '-' is used to mean "article A through article B,
inclusive..

   Patch-To: rkive: Volume 22, Issue 122-124

If a patch applies to multiple part postings that are not consecutive, a comma
is used to separate the part issue numbers. It is possible to mix both commas
and dashes on a single Patch-To: line.

   Patch-To: rkive: Volume 22, Issue 122,125,126,127
   Patch-To: rkive: Volume 22, Issue 122,125-127


--------------------
Subject:  Patches Handling

Patches will be handled as swiftly as possible. Authors of sources posted to
c.s.3b1 should send all patches to me so that I can post them back through the
newsgroup in order that the patches can be archived. This has not been done in
the past in other sources groups and has lead to lost patches. If the patches
must get out *real* fast, post them to comp.sources.bugs and send me a copy at
the same time so that they will be available when they are needed in the
future. Again, patches will receive priority processing so make sure I get
them...

I would prefer not to post patches that are not sent by the author of the
original posting unless special arrangements have been made with the author.
Please send your unofficial patches to the author so that the author can
incorporate them into their postings baseline.  Unofficial patches can be
posted to comp.sources.bugs as a method of letting the community use the fix
or enhancement during the interim.

It is up to the author to determine if there have been major enough changes to
warrant a complete reposting. This may be necessary if the size of the patches
exceeds the size of the source but in most cases only patches are posted.
Total repostings should be treated as an initial posting. What follows
pertains to patches...

  1.  When patches are submitted, they should be in context diff format.

  2.  A patch to patchlevel.h should be done to reflect that the patch has
      been applied if a patchlevel.h existed in the initial posting. If one
      was not included initially, maybe now is a good time to consider
      including one... :-)

  3.  Include information about which previously posted issues the patch
      pertains to if they were initially posted to c.s.3b1.

For more information on patch see patch.man in util/patch/patch.man in the X11
Release 4 distribution or in volume7 of the comp.sources.unix archives.

--------------------
Subject:  Guidelines for submitting source for publication

Items intended for posting and problem notes should be sent to one of the
following:

   [e-mail]
   comp-sources-3b1@<news backbone site>
   [e-mail]

Newsgroup-related mail that is *not* a submission should be sent to me at one
of the following:

   [e-mail]
   [e-mail]

If you want verification of arrival, say so in a cover note, or at the
beginning of your submission, if it is small.  I will try to do this by
default but if you want it guaranteed, ask...

To make life easier for both myself and the users of the comp.sources.3b1
newsgroup, I request that all submissions follow the following guidelines.
Not following these guidelines may result in longer delays, since some things
*must* be fixed for news to accept the submission, and others fixed so that I
can spend time processing submissions rather than responding to flames.  ;-)

The first rule is that "shell archives" as created by "shar", "cshar",
"bundle", etc. be used to package files.  Preferably, use cshar:  it guards
against mangling by older news programs, Bitnet mailers, etc.  I must repack
non-shar'ed submissions so that they have a better chance of surviving older
mail/news systems and inter-network gateways.

Second, a Subject: header should *always* be included in a submission.  When a
posting arrives without a Subject: line, not only does it force me to make one
up for the archive list, but (more importantly) inews, the driving program for
the Usenet news system, will not accept articles which lack a subject line.

Please do not package executable programs and sources in the same submission.
If you have a program that you absolutely *must* distribute in binary form I
can arrange for it to be placed in the att7300 archive on osu-cis but it
should not be posted to a sources newsgroup.

Other nice things to consider/supply when submitting sources...

  1.  A Makefile.

  2.  A manual page is highly recommended for any substantial sized
      submissions.

  3.  A README file is also highly desirable. This should contain a brief
      description of what the posting is and any special considerations in
      building it. The README should also contain a list of authors and the
      distribution and copying policy.

  4.  A patchlevel.h -- This file can be used to keep track of how many
      official patches have been applied.

--------------------
Subject:  Reporting and tracking bugs.

You should subscribe to comp.sources.bugs.

Sometimes, when new versions of previously-published software is available,
just patches are put out, usually in the form of shar files containing input
for the "patch" program, new files, etc.  Sometimes complete new versions are
put out.  Which method is used depends on the poster and the moderator.  Minor
updates must be in patch form and update the patchlevel.h file.  Major updates
should follow the guidelines for initial postings.

To report bugs, contact the person listed in the Submitted-by header.  Often
there is a contact address in a README file, too.  I do not maintain the
sources I moderate, so don't send your bug reports to me.  Likewise, I
normally do not post patches for a package from anyone except the author. If
you have patches you would like to see included in the package, send them to
the person listed in the Submitted-by header.

--------------------
Subject:  Becoming an archive site

If you collect comp.sources.3b1 postings and are willing and able to make your
collection available to other people, please let me know.  Benefits include
the undying gratitude of your colleagues, and a promise from me to try to make
sure you never lose an article whether you use rkive or not.  If you can
provide access to your archives send me some email and I will get you some
publicity.

--------------------
Subject:  Archive access via ftp

If an archive site provides "anonymous FTP" access, sites directly on the
Internet (that is, sites possessing an IP address, which looks like four small
numbers separated with periods) can use the "ftp" program to get at sources.
Sites which aren't on the Internet (more properly, the NSFnet) can not use ftp
to retrieve this information.  And no, having the ftp program does not mean
that you can access NSFnet:  there are many systems which use TCP/IP over
local networks only, and at least one brand of system which has a program
called "ftp" that has nothing to do with the Internet at all.

You should check with a local system administrator to find out the details of
using ftp.  On most systems and to most archive sites, the following will
work:  type the command "ftp system.domain" (example:  "ftp uunet.uu.net" --
case does not matter), enter "anonymous" when it asks for a user name, and
enter *your* Internet address for the password.  If "ftp" says that the system
doesn't exist, check your spelling -- if the system name is spelled correctly,
look for an IP address for the archive site and badger your system
administrator to install a version of ftp which knows about nameservers.  You
should also be warned that some systems (like uunet) will not accept FTP
connections from sites not registered with a nameserver.

Once you are logged in to the archive system, you will get a prompt that looks
like "ftp>".  (It may not be identical, since it is possible to change the ftp
prompt with a command in many versions of ftp.)  At this point, you can use
"cd" to change directories, "ls" or "dir" to list files, and "get" to retrieve
them.  For sources archives, it is not necessary to worry about file types
unless the files are compressed; in that case, you must use the "binary"
command for Unix or VMS hosts and "tenex" on Tenex (TOPS-10, TENEX, TOPS-
20/TWENEX) hosts.  *** Not switching the file type can result in a garbled
file, especially on Tenex hosts, which do not store binary data the same way
as Unix hosts. ***  To disconnect from the archive site, enter the "bye"
command.

--------------------
Subject:  Archive access via uucp

UUCP archives aren't quite as standardized as FTP archives; check the archive
list for the user name and password to use, and ask your system administrator
to arrange to be able to poll the archive site.  (If s/he/it refuses, you are
stuck.)

The "uucp" command is used to request files from a UUCP archive.  Unlike FTP,
UUCP does not (usually) do the transfer immediately; this is because most UUCP
sites must be called over phone lines, so long-distance calls will usually be
made in the early morning hours.

Since you can't look around in the archives, you must know the pathname of the
article to be retrieved.  Most archives have an index file available via FTP;
check the archive list in the next posting.  It's a good idea to retrieve this
file before getting anything from the archive, since things can move around
without warning.

The command to retrieve a submission looks like

   uucp -r archivesite!path/to/file

"archivesite" is the name of the archive site, and "path/to/file" is the
pathname listed in the archive index for that site.  Please be warned that for
security reasons, it is not usually possible to specify wildcards (?, *, [],
or ~name) in the pathname.  Also, while more recent versions of uucp allow a
uucp command to traverse multiple systems (uucp -r systemA!systemB!file), for
security reasons this is usually disabled.  In both cases you won't find out
until after the archive site has been called.

--------------------
Subject:  Archive access via email

Some archive sites have mail servers that will accept mail from you and mail
back files from the archive.  There are no standards here; however, it's
usually safe to mail a message containing the single word "help" to the mail
server.  Check the archive list for more information.

--------------------
Subject:  Extracting a retrieved archive member

If the article came from an archive site, it may be compressed; if it was sent
by a mail server, it may also be uuencoded.  Compressed files have an
extension of ".Z".  Uuencoded files can be recognized by a line saying "begin
666 filename", followed by lines of what looks like random gobbledygook.  (If
a mail server splits a file into multiple parts, you may just have the
gobbledygook.  In this case, the server will include a message saying which
part of the file it is, and will tell you how to combine them.)

To extract a uuencoded file, give the command "uudecode filename".  This will
create a (binary, usually compressed) file in the current directory.

To extract a compressed file, give the command "uncompress filename".  The
".Z" extension will be removed from the file.  The original, compressed file
will be removed as part of this operation.

After doing this, you should be left with a news article exactly as it is
stored in the news spool directories.  This file will contain a news header, a
description (usually), and a "shell archive" ("shar").  Move to an empty
directory (important!) and unpack the archive.  Some systems have a command
"unshar" to unpack these files; if yours does, use it.  Otherwise, you can use
an editor to remove the header, then just say "sh filename".  I use a small
(one line) shell script:

   sed '1,/^[#:]/d' $1 | sh

which will handle anything (I hope!) in the comp.sources.3b1 archives.  I do
attempt to confirm that a shell archive contains nothing dangerous, but if you
unpack as root and the archive removes your /etc directory or something
equally unpleasant, I don't want to hear about it.  Unpack shell archives as
an unprivileged user.

Once you've unpacked the archive, you're on your own.  Keep the header from
the submission handy, in case you can't figure out what's going on; the
address in the "Submitted-by:" line can be used to contact the author of the
program.
--
David H. Brierley
Home: [e-mail]; Work: [e-mail]
Send comp.sources.3b1 submissions to [e-mail]
%% Can I be excused, my brain is full. **