Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!beartrk!ceilidh!dnichols
From: dnichols@ceilidh.beartrack.com (DoN Nichols)
Newsgroups: comp.sys.3b1
Subject: Re: OSU archives need an active maintainer
Message-ID: <1991Mar26.154037.27816@ceilidh.beartrack.com>
Date: 26 Mar 91 15:40:37 GMT
References: <1991Mar17.195839.7034@athena.mit.edu> <5968@awdprime.UUCP> <1372@galaxia.Newport.RI.US>
Organization: D and D Data, Vienna, VA.
Lines: 67

In article <1372@galaxia.Newport.RI.US> dave@galaxia.Newport.RI.US (David H. Brierley) writes:

	[ ... ]
>
>Either I've gone off the deep end or I've figured out how to squeeze 36
>hours out of each day.  :)

	Congratulations - either way :-)   (really - thanks!)

	[ ... ]

>                     I have also been considering making binary copies of the
>postings to comp.sources.3b1 available.

	Useful to those who do not yet have a development system, or for
those programs that are too large to compile within a limited disk space.
Generally, I prefer to have the option to customize the code somewhat before
commiting to use.  An example is the csh(1) source, which defines SHELL as
being something like '/ucb/bin/chs'.  I'd just as soon not have to create
ANOTHER bin directory, and add it to my path.  Working from the source
allows you to tune little awkwardnesses like this.  As long as you follow
the other suggestion you put forward of making separate directories for the
binary-only items, it is fine.

>                                         Another thing that I am seriously
>considering is breaking the archive up into sub-directories, one for binaries,
>one for source, and one for documents.  If you have any major opinions about
>this, either pro or con, please let me know.

	This makes sense.  One other thing to avoid, if possible, is falling
prey to the BSD filename disease, since the archives seem to be residing on
a BSD machine.  Yes, I know how nice it is to have unlimited (for practical
purposes) filenames available when trying to have descriptive names for the
files, but remember that they have to fit, UNIQUELY, into the 14-char
filenames on the target machines.  When doing a mget via ftp, you may have
files overwriting each other if the names are not unique within the first 14
characters.  Uucp is even worse, since at least, ftp allows you to
interactively rename files if you don't use mget.  (It has been a while
since I used uucp for this, so there may be a way that I don't remember.)
Another related problem are the files which are fifteen or sixteen chars
long, causing the '.Z' to be stripped off, confusing uncompress, unless you
use it as a filter.  (I think that the -z option of gnu tar is O.K. here,
but In't remember having tested it.)

	Of course, even worse are the programs from comp.sources.unix which
I have received in the past, which contained within the SHAR files names
which were a perfect match within the first fourteen chars, or even worse,
tar files with the same problem. (At least, with shar files, you can edit the
files to change the names, and re-extract. :-) Well, I now have a BSD4.2
machine in my collection, so I can open things out with that system, run a
program to rename the files for a 14-char filesystem, and re-tar.  (Sorry, I
got carried away here.  THESE programs should not have THIS problem, at
least, since they were SHARed or TARed on a unix-pc.)

   [ ... ]

>%% Can I be excused, my brain is full. **

	How about "My DISK is full", now :-)

	Thanks again
		DoN.
-- 
Donald Nichols (DoN.)		| Voice (Days):	(703) 664-1585
D&D Data			| Voice (Eves):	(703) 938-4564
Disclaimer: from here - None	| Email:     <dnichols@ceilidh.beartrack.com>
	--- Black Holes are where God is dividing by zero ---