Xref: utzoo comp.sys.ibm.pc:21110 comp.binaries.ibm.pc.d:1316 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!orstcs!cutsys!cutter From: cutter@cutsys.UUCP (Bernie Hoffstadt ) Newsgroups: comp.sys.ibm.pc,comp.binaries.ibm.pc.d Subject: Re: DESCRIBE.TXT Message-ID: <302@cutsys.UUCP> Date: 11 Nov 88 17:14:23 GMT References: <7377@dasys1.UUCP> <8828@smoke.BRL.MIL> <3026@ttrdc.UUCP> Reply-To: cutter@cutsys.UUCP (Bernie Hoffstadt (753-1646)) Organization: Garfield's Litterbox Lines: 36 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