[comp.sys.ibm.pc] DESCRIBE.TXT

nelson@sun.soe.clarkson.edu (Russ Nelson) (10/28/88)

I am going to start putting a file into all of the .arc files that I maintain
that describes the package.  The first line will contain the "short"
description, which will always be less than 45 characters.  The remainder
of the file will be a verbose description of the package, but will always
be less than ten lines long.  The name of the file will always be DESCRIBE.TXT.
The description will be of benefits to the user, not features of the package.

I would appreciate any help I can get in this effort.  For example, if you
have posted something to comp.binaries.ibm.pc, please write the DESCRIBE.TXT
file for it, and I will retroactively stick the description into the .ARC
file.  Furthermore, if you have a favorite package I would enjoy receiving
a description of it.

This will have obvious benefits for both sysops and users.  Users who upload
will not have to describe their files, and sysops will have a ready-made
description.
-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])
To surrender is to remain in the hands of barbarians for the rest of my life.
To fight is to leave my bones exposed in the desert waste.

ads4@tank.uchicago.edu (adam david sah) (10/31/88)

Don't include the filename DESCRIBE.TXT as a standard filename into the ARChive!!!!! If you do that, and someone has more than one ARChive in a directory and tries to unpackage them simultaneously, there will be a collision of names and one of them will have to go.

This situation arrises when I download a stack of files from a bulletin board, and every one of them had a "README.DOC" or "READ.ME" or ....

Why not set the standard to be the filename (which is much less likely to collide) and the extension to be kept constant. Example: FILENAME.DES or .DSC (both short for description...)

The point is somewhat serious, since I, for one, like to test out all new software together, so that I lower the chances of any problems (i.e. Trojans, etc) and can keep some order, without having to leave permanent "\TEST" subdirectories lying around.

Please no flames. If anyone has any better ideas or just wants to ignore this- by all means...

-A.Sah'88
SysOp, The Art of Science BBs  (312)752-6104

nelson@sun.soe.clarkson.edu (Russ Nelson) (10/31/88)

In article <592@tank.uchicago.edu> ads4@tank.uchicago.edu (adam david sah) writes:

   Don't include the filename DESCRIBE.TXT as a standard filename ...
   a collision of names and one of them will have to go. ...

   Why not set the standard to be the filename (which is much less
   likely to collide) and the extension to be kept constant. Example:
   FILENAME.DES or .DSC (both short for description...)

   -A.Sah'88
   SysOp, The Art of Science BBs  (312)752-6104

Well, since the whole idea is to make life easier for SysOps, and here's
one SysOp who think that DESCRIBE.TXT will make it harder, I'm willing
to change my mind.  Are there any other sysops who think would prefer
	archive-name.DSC
to
	DESCRIBE.TXT
?
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
To surrender is to remain in the hands of barbarians for the rest of my life.
To fight is to leave my bones exposed in the desert waste.

srt@maui.cs.ucla.edu (Scott Turner) (11/01/88)

Using <archive-name>.dsc would make it easier to write a "man" type command as well.
 
    Scott R. Turner
    UCLA Computer Science     "Does school ever end?"
    Domain: srt@cs.ucla.edu

joshua@uop.edu (Ed Bates) (11/01/88)

I agree with the "NO!" that is.  I like the idea of having a
description file, but the naming should be unique.  I would
much rather have a <filename>.RME and a <filename>.DSC for the
"READ.ME" and description files.  That way you know which
supportive file belongs to which package.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Edwin J. Bates			University of the Pacific
Academic Computer Specialist	Computer Services, 877 W. Stadium Dr.
(Jack-Of-All-Computers)		Stockton, CA	(pretty close to Sacramento)
209-946-2251			95211		(somewhat near San Francisco)

tneff@dasys1.UUCP (Tom Neff) (11/02/88)

Any sysop dumb enough to cumulatively de-ARC one package after another
into the same directory rather than checking them out one at a time,
deserves whatever he gets.  README is an excellent convention, used by
pd programmers and commercial vendors alike.

nelson@sun.soe.clarkson.edu (Russ Nelson) (11/03/88)

   Any sysop dumb enough to cumulatively de-ARC one package after another
   into the same directory rather than checking them out one at a time,
   deserves whatever he gets.  
How about "pkxarc *.arc *.dsc", which gives a real quick look at all of
the archive files in the subdirectory?

   ... README is an excellent convention, used by pd programmers and
   commercial vendors alike.

Wrong, at least for my purposes.  There is usually no attempt in a
README file to be succint, nor is there any easy way for a sysop to
distill a README file into a 40 column description.  With a .dsc file,
the sysop can merely do a 'head -1' on it to get the 40 column description.

README is insufficient to convince lusers why they would want to bother
with a package.  I want something where my lusers can do a quick scan of
the 40 column descriptions and decide if they want to read the ten line
description.  Heck, I'll probably even create a local group called, say,
comp.pc.dsc, and post description files there:

	tail +2 $1 | inews -t `head -1 $1` -n comp.pc.dsc -d local

Wasn't I being clear enough?
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
To surrender is to remain in the hands of barbarians for the rest of my life.
To fight is to leave my bones exposed in the desert waste.

ads4@tank.uchicago.edu (adam david sah) (11/04/88)

In article <7377@dasys1.UUCP> tneff@dasys1.UUCP (Tom Neff) writes:
>Any sysop dumb enough to cumulatively de-ARC one package after another
>into the same directory rather than checking them out one at a time,
>deserves whatever he gets.  README is an excellent convention, used by
>pd programmers and commercial vendors alike.

Who died and left you God? I do that al the time, since it is NOT practical to start unARCing things "as-you-go". I usually like to sit down and try it all out at once (it isn't hard to tell which thing came from which package...

Furthermore, even if your point HAD some validity, it loses that to the fact that some of these files are left lying around AFTER all is said and done... and what about THOSE??? Some README.DOCs/READ.MEs/README.s etc give VERY IMPORTANT INFORMATION about the file and its usage... renaming those is silly, too, when they shouldn't be given that name in the first place (in our hypothetical model)

SHEESH!!!! It's just as easy to add an ".RME" or a ".DSC" to a filename as it is to give it the usual READ.ME which tells you NOTHING (it also doesn't tell you which prg it came from... after all is said and done!)

-A.Sah'88
SysOp, The Art of Science BBs  (312)752-6104

ads4@tank.uchicago.edu (adam david sah) (11/04/88)

you mentioned a lot about the mainframe environment of the nets. I am talking for the pc's themselves! See my prev. msg, but suffice it to say that now the arguement goes even further. I say we start a convention!!!
(standard, that is- leave the conventions for the Democrats and Republicans...)

-A.Sah'88
SysOp, The Art of Science BBs  (312)752-6104

tneff@dasys1.UUCP (Tom Neff) (11/04/88)

In article <NELSON.88Nov2233024@sun.soe.clarkson.edu> nelson@clutx.clarkson.edu writes:
>How about "pkxarc *.arc *.dsc", which gives a real quick look at all of
>the archive files in the subdirectory?

How about "zoo lc *" which does the same thing for ZOO files?  You put
in the comments.  Sounds like you're trying to reinvent ZOO features in
an ARC context.  If you have enough control over your archive system to
disrupt distribution packages by inserting alien files in other
people's ARCs, why not just convert them to ZOOs where you have the
complete freedom to include quick & easy descriptions.

Even in arc-land, how about "arce * readme /p | more", which pages you
through the readme files?  (I don't know whether the odious Katzware
shares this basic functionality.)

>                              ... There is usually no attempt in a
>README file to be succint, nor is there any easy way for a sysop to
>distill a README file into a 40 column description.  With a .dsc file,
>the sysop can merely do a 'head -1' on it to get the 40 column description.

Fine, sounds reasonable enough, tantamount to a BBS download directory.
Of course you could just give the folks a descriptive catalog text file
to scan.  Too simple?  Or, as I mention above, there are ZOO comments.

>README is insufficient to convince lusers why they would want to bother
                                    ^^^^^^
>with a package.  I want something where my lusers can do a quick scan ...
                                            ^^^^^^
To paraphrase the famous Dorothy Parker review of Milne: Tonstant Newsweader
fwowed up.  Gawd but I hate this attitude.  If there were not specific
technical issues alive here we would be in alt.flame as of that line.
Let it pass.

>Wasn't I being clear enough?

No, but now you are.  You can get what you want by using a better package
than ARC; the namespace issue with *.DSC vs README is nonexistent because
collisions only happen if the file handling is inept; the BBS-style
descriptive catalog is a user-friendly thing to want to build, but there
are easier ways than poking your own cribsheet into everyone else's
envelope.

nelson@sun.soe.clarkson.edu (Russ Nelson) (11/05/88)

In article <7409@dasys1.UUCP> tneff@dasys1.UUCP (Tom Neff) writes:

   In article <NELSON.88Nov2233024@sun.soe.clarkson.edu> nelson@clutx.clarkson.edu writes:
   >How about "pkxarc *.arc *.dsc", which gives a real quick look at all of
   >the archive files in the subdirectory?

   How about "zoo lc *" which does the same thing for ZOO files?  You put
   in the comments. ...
1) Because you only get the one-line comment, and
2) Because you can't use a text editor on the comment.

   Even in arc-land, how about "arce * readme /p | more", which pages you
   through the readme files?  (I don't know whether the odious Katzware
   shares this basic functionality.)
Because, as I said before, README can be several line, several paragraphs,
or several pages.  No consistency.

   >README is insufficient to convince lusers why they would want to bother
				       ^^^^^^
   >with a package.  I want something where my lusers can do a quick scan ...
					       ^^^^^^
I meant Real Users.  Apologies if any were offended.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
To surrender is to remain in the hands of barbarians for the rest of my life.
To fight is to leave my bones exposed in the desert waste.

mju@m-net.UUCP (Marc Unangst) (11/07/88)

In article <7409@dasys1.UUCP> tneff@dasys1.UUCP (Tom Neff) writes:
>
>How about "zoo lc *" which does the same thing for ZOO files?  You put
>in the comments.  Sounds like you're trying to reinvent ZOO features in
>an ARC context.  If you have enough control over your archive system to
>disrupt distribution packages by inserting alien files in other
>people's ARCs, why not just convert them to ZOOs where you have the
>complete freedom to include quick & easy descriptions.
>to scan.  Too simple?  Or, as I mention above, there are ZOO comments.

PKARC v3.5 and up has file and archive comments, too.  One of the
prime reasons that ZOO will probably never gain wide acceptance
is the fact that it isn't backward-compatable with PKARC.  People
have to convert all their archives to ZOO.  For a BBS with several
megabytes of files, this could take a very long while.  Perhaps
if a person wrote a program to automatically re-pack all of a
BBS's files with ZOO, it would help the changeover.  The sysop
would take the board down for a day, run ARC2ZOO, and then
put it back up.
-- 
"Don't find a fault. | Marc Unangst
Find a remedy."      | mju@m-net.ann-arbor.mi.us  ...!uunet!umix!m-net!mju
  -Henry Ford        |

waters@dover.uucp (Mike Waters) (11/08/88)

In article <NELSON.88Nov2233024@sun.soe.clarkson.edu> nelson@clutx.clarkson.edu writes:
>
>   Any sysop dumb enough to cumulatively de-ARC one package after another
>   into the same directory rather than checking them out one at a time,
>   deserves whatever he gets.  
>How about "pkxarc *.arc *.dsc", which gives a real quick look at all of
>the archive files in the subdirectory?


 In addition, this practice leaves you open to all kinds of trojans and
viruses. Personally I *always* de-arc a new program onto a floppy with
the hard disk disabled (or something fakey there that detects attempts
to write - HARDWARE not software).

Its not foolproof, but lets not get the idea that last weeks Arpanet
virus (really a worm) couldn't happen on ANY machine or network. UNIX
just
happens to be very convenient.


-- 
Mike Waters                 (for your EDIFication)
Motorola SMART CAD Group - EDIF (ANSI/EIA std. 548) support
Mesa, AZ   ...!sun!sunburn!dover!waters
          OR   moto@cad.Berkley.EDU

w8sdz@smoke.BRL.MIL (Keith B. Petersen ) (11/09/88)

Instead of DESCRIBE.TXT how about archivename.INF ?  This serves the
purpose of indicatings it's an "information" file.  It also serves
another very useful purpose - giving the original name of the
distributed archive, which is very useful in cases where the person who
uploaded the file mistyped or misnamed it.  It also helps for those
files which come from CIS where their operating system limits the name
to SIX.THREE instead of the usual EIGHT.THREE characters.
-- 
Keith Petersen
Maintainer of the CP/M & MSDOS archives at WSMR-SIMTEL20.ARMY.MIL [26.0.0.74]
Arpa: W8SDZ@WSMR-SIMTEL20.ARMY.MIL
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

msc@ttrdc.UUCP (Michael Cross ) (11/11/88)

[ ... discussion about using filename.INF deleted]

We use the extension RDM for this purpose.  I have seen RME posted as another
suggestion.  They both mean the same thing: Read Me.  We have packages
here at work that use the INF extension already (I think it might be
DCAs IRMA package).  The first thing I do when I see a README file is to
rename it so that it stays grouped with the EXE and DOC files.

>Mike

-- 
Michael S. Cross  (..!att!ttrdc!msc)  (312)-982-2018
AT&T Bell Laboratories Area 61
5555 Touhy Ave., Skokie, IL  60077
________________________To Live is to risk Dying______________________________

cutter@cutsys.UUCP (Bernie Hoffstadt ) (11/12/88)

	There has been a lot of discussion on what the filename format
of text information files should be; READ.ME, DESCRIBE.TXT, NAME.INF,
NAME.RME, etc...

	There is a consideration I haven't seen discussed yet on the
*merits* of a hard coded filename (i.e. README) versus the less collision
prone ARNAME.INF ...  This would mostly concern only the lazy (efficient? ;-)
or those using automated batch processes.  The thing I have noticed about
arhives is that though they are usually named fairly consistently, it's
not always that you can guess exactly what the name of the program
within is.  For example, an archive with the name zoo211.arc; 8 out of
10 ibm.pc readers can correctly name the program as zoo, but what about
ker_scp1.arc? (this is just a name I pulled randomly from my archive index).
The same would go for a NAME.INF.  Unless you knew exactly what NAME was,
you'd have to do a listing of the archive first to see what to extract.
Like I said, this will only bother lazy people, but it would also make
batch scripts harder to write, as they would have to be able to figure
out what the NAME was without the benefit of human ingenuity.

	Now the NAME.INF convention could be that the NAME should be the
same as the NAME.ARC (without the .ARC).  Still there exists the possibility,
though much less likely, that there will be some error causing a discrepancy
between the two.  Anyway, it's something to be pondered.

P.S.  I archive my archives to floppy disks, and I keep an index of what's
on each disk.  Each disk has it's copy of it's index, and I have named it
such that it's always the first thing to come off the floppy, and is always
the same.  So if something happens to my master index, it's a simple matter
to write a script that rebuilds it quickly just by me putting the disks
in one after another.

-- 
Bernie Hoffstadt   (503) 752-5929 * Internet: cutter%cutsys.UUCP@CS.ORST.EDU
1437 N.W. 9th st.   -or- 753-1646 *   -or-    cutter@jacobs.CS.ORST.EDU
Corvallis, Oregon  97330  **** UUCP: {tektronix,hp-pcd}!orstcs!cutsys!cutter 

thaler@speedy.cs.wisc.edu (Maurice Thaler) (11/14/88)

The ARC to ZOO converter has existed for quite a while in the form of
ATOZ . The fact is you could easily write a batch file to do it also. 

bobmon@iuvax.cs.indiana.edu (RAMontante) (11/14/88)

mju@m-net.UUCP (Marc Unangst) writes:
>PKARC v3.5 and up has file and archive comments, too.	[...]

ZOO's comments are longer.  Unlimited length, I suppose, although I've
never tried it to see...  The Katz programs had to fit the comments
into space left by SEA's format definition, constraining them to 32
characters or so.

>	[...]	  Perhaps
>if a person wrote a program to automatically re-pack all of a
>BBS's files with ZOO, it would help the changeover.  The sysop
>would take the board down for a day, run ARC2ZOO, and then
>put it back up.

Rahul wrote and released ATOZ, which invokes yer favorite external
de-archiver to convert from the-archive-format-of-your-choice to ZOO
format.  The documentation mentions PKXARC, ARC, ARCE, and LUE as
examples.  The copy I have is v1.12, and is public domain.
-- 
--  bob,mon			(bobmon@iuvax.cs.indiana.edu)
-- "I thought it must be one of the prime numbers of the Zeeman Series.
    *I* haven't changed."