From ucs_kas@SHSU.EDU Thu May 28 17:12:42 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01381; Thu, 28 May 92 17:12:37 MDT Message-Id: <9205282312.AA01381@math.utah.edu> Received: by SHSU.edu (MX V3.1B) id 30590; Thu, 28 May 1992 16:26:34 CDT Date: Thu, 28 May 1992 16:26:34 CDT From: MX mailing list processor To: beebe@math.utah.edu Subject: Subscription to mailing list TWG You have been added to mailing list: TWG@SHSU.BITNET (TWG@SHSU.edu). This list is intended to assist the TeX Users Group's Technical Working Group (TWG) on Archive Guidelines (WG-92-05). Very likely, you were added to this list without prior consent. If this is the case and you elect to not participate, please contact George Greenwade (all addresses and numbers listed below) prior to signing off so he may twist your arm and explain the reason you were added. It is not necessarily intended that you serve on the TWG; more than likely, your professional guidance, insight, and input is what is sought. Further administrative requests regarding this list should be sent in the body of a mail message to LISTSERV@SHSU.BITNET (LISTSERV@SHSU.edu) -- or to -- TWG-Request@SHSU.edu The following commands can be handled automatically by the list processor: SIGNOFF TWG - to remove yourself from the list SET TWG NOMAIL - to remain on the list but not receive mail SET TWG MAIL - to resume receiving mail from the list SET TWG CONCEAL - to conceal your address from REVIEW commands SET TWG NOCONCEAL - to reveal your address in REVIEW commands SET TWG REPRO - to receive from the list posts you made to it SET TWG NOREPRO - to not receive from the list posts you made to it REVIEW TWG - to get a list of subscribers QUERY TWG - to get the status of your entry on the list LIST - to get a list of mailing lists served by this host HELP - to receive a help file Please do NOT send administrative messages to the list address (TWG@SHSU.BITNET or TWG@SHSU.edu) as posts to this address are distributed to all subscribers of the list. By default, new subscribers are set to MAIL, NOCONCEAL, REPRO. Please note that all posts to TWG should have the list address in the Reply-To: field. This is negotiable among list members and I am certainly willing to change this, although I believe it will better foster the discussions which I hope to arise. -------------------- About TWG Archives -------------------- TWG archives are maintained at Sam Houston State University and will be available via SHSU's file server, FILESERV@SHSU.BITNET (FILESERV@SHSU.edu) for mail retrieval, as well as via anonymous ftp from Niord.SHSU.edu (192.92.115.8). Please note that the archives and files are supported by FILEserv, while list-related commands are supported by LISTserv. For FILESERV, the filename structure is TWG.yyyy-mm, where "yyyy" represents the year and "mm" represents the numeric equivalent of the month. For example, the archives of TWG for May, 1992, would be TWG.1992-05. To retrieve TWG archives (via mail) for May, 1992, include the command: SENDME TWG.1992-05 in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). You may send FILESERV multiple commands so long as each resides on a unique line of the MAIL message. If you are interested in available FILESERV commands, include the command HELP in the body of a mail message to it. For anonymous ftp retrieval from Niord, the archives for TWG are retained in the directory [FILESERV.TWG] using the same filename syntax as above. A very important file for your consideration is the file [FILESERV.TWG]TWG.MANDATE (SENDME TWG.MANDATE to FILESERV will retrieve this). Although it dates to March, 1992, I have been investigating some background material so I could be at speed on some of the technical aspects I know this group will very likely confront. I will make every effort to place all TWG-related files in the directory [FILESERV.TWG] as TWG.something_relevant so they may be retrieved via mail, as well as minimizing ftp users from having to wonder around the various directories on Niord. If you have any documents which you believe should be placed in this directory, please contact me so that arrangements can be made to get the files to SHSU. If you have any questions or comments about this list, or are in need of assistance, please do not hesitate to contact the list owner directly at any of the addresses provided below. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% (This message was generated automatically.) From ITeX-Mgr@SHSU.edu Mon Jun 1 20:07:34 1992 Flags: 000000000011 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04900; Mon, 1 Jun 92 20:07:30 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 5446; Mon, 01 Jun 1992 16:39:26 CDT Date: Mon, 01 Jun 1992 16:39:12 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: twg@SHSU.edu Message-Id: <0095B752.46D8C3A0.5446@SHSU.edu> Subject: The purpose of this list By now, each of you should have received notification of being unilaterally placed on the TWG list. I thank each of you for your patience with me in doing something quasi-illegal (placing you on a list without prior consent) and something which is somewhat pompous (thinking you will casually go along with me). As noted in the subscription notification, each of you were selected because of your expertise in various areas. Some of the expertise I will bother you about (unless you want out, which I will certainly accept and understand) is very narrow in focus, others have a broader expertise (certainly much broader than mine); some of you are presently archivers, others are not; some are active long-time members and officers of TUG; other not. In essence, there is no one overriding qualification to have been placed on this list beyond a trust that you care in this project and you have the competence to really assist in some aspect of it. This list is not meant to replace tex-archive; rather, it is intended to serve as a central repository of ideas for TeX Archive Guideline materials. By coordinating this list out of my site, I will be able to have fast and accurate access to postings and the archives which develop. I hope to somehow consolidate these ideas into something digestible for TUG to consider. A very interesting facet that I have come across in researching what guidelines already exists is that ftp-based and mail-based archiving, by and large, is a very localized issue, even though these local archives commonly serve universal audiences. Some level of consistency between sites is probably desirable for all archives on all topics; a high level of consistency between sites with as vast, dynamic, and large a collection as the TeX project, its ancillaries, and related products is a very likely a necessary (if not sufficient) condition for continued growth, use, and support. Additionally, with a clearly defined objective, local political support of archives may be easier to gain. Therefore, the mission of this WG may be viewed on a larger plane, possibly extending to a model of archiving which can be globally followed. I am starting with the notion that any guidelines developed by the WG are fluid. That is, the initial guidelines, however rough they might be, are always subject to change. This allows for tomorrow's technologies to be implemented as they develop. As few as 13 years ago, the concept of directly tying in to another machine on another continent and transferring data at T1 speed was read about in Scientific American; today, we live with it and accept it as common practice (and complain when we come across a 9600 baud link; oh, for the days of tape streamers). I do not wish to create a set of guidelines which constrict anyone to only today's technologies as I can only envision what terrabyte machines internationally connected on fiber optics may allow us to achieve. If you have not retrieved the mandate of WG-92-05, the basics which require discussion include: Mandate: The purpose of this Technical Working Group is to develop guidelines for the effective management and utilization of major TeX archives, and to initiate communication among the maintainers of the existing archives for the purpose of coordination and synchronization. Areas to be considered include, but are not limited to: - what physical resources are needed - what kind of management support is desireable - what personnel resources are necessary and how should they be organized - breadth and depth of coverage, general and specific subject archives - strategies for organizing and managing the archive holdings - strategies for archive synchronization - dissemination strategies of archive contents - should there be "official" archives To be quite honest, I am not sure precisely where to begin. I have no idea of exactly how large some of the larger archives presently are, how much they plan to expand, and what hardware contraints they must impose; any comments? Management and personnel, in general, will probably always be local in nature. I would almost posit that, if a good mirroring scheme were worked out, management and personnel would almost be non-issues (so long as each site operated within a set of known and accessible guidelines). This, then, leads to the general vs. specific archive. Clearly, large archives (Aston, Stuttgart, ymir) are desired (SHSU hopes to join these ranks as soon as we can get some form of agreement out of this group on how to do it). Also clearly, specific archives, possibly to include one and only one package, can also be desired. Again, mirroring become an issue. Mirroring is an obvious way to get parallel structures in place. Alternately, with some work and agreements, remote NFS mounts might be considered, as might something in the WAIS design. I believe it would be far preferable not to reinvent a sufficient mechanism. Beginning with mirroring, the mirroring software on Unix (the Perl script which Joachim pointed me to) is quite nice. It is capable of complex U*ix to U*ix retrievals. Bringing VMS into this picture at all, from what I can tell, is out of the question in its present design. Maybe Rainer's efforts will accommodate this. I will note, though, that I was able to find a VMS port of Perl on the net (look in the [.PERL] directory on Niord.SHSU.edu). I know nothing of Perl, but Ken Adelman at TGV (the MultiNet folks) has retrieved it from our site and claims it is a good porting for most things. Unfortunately, the mirroring script doesn't want to work with it. I believe that some consistent form of organizing the holdings has been tentatively agreed upon, based on prior posts to tex-archive. I have no bias here, so long as it is a logical and understood design. I know that ymir is moving to U*ix soon, so precisely how the directories are structured is probably something of a non-issue at the moment. As I said, we expect to add everything we can get our hands on, so the existing structure at SHSU is nothing to be concerned about. However, there are differences between, say, Stuttgart and Aston. I assume these to be stable platforms at the moment. How troublesome would it be to change either or both to some new standard? Also, some form of possible standardization in headers, as proposed by David Jones and as already seen in a few files, is probably desirable. Who is to be responsible for these? If an author does not provide them, are they not archived? Also, what about postings to sources such as comp.text.tex, INFO-TeX, UKTeX and TeXhax, etc.? Who is to handle these (if anyone) with respect to not only headers, but mere extraction? Moreover, how is something like David's work in progress to be coordinated as versions, packages, operating systems, etc., change? That is a task I would hate to think is manual. The departure of ymir will leave SHSU and Aston as the only active VMS sites I am aware of in the archiving game (I am sure there are others, though). The conversion of ymir to U*ix, as well as our bringing 2.4 gig on-line at pip.SHSU.edu for archival purposes will broaden the U*ix-based archives. We plan on supporting both VMS and Unix, by the way, each with at least 2 gig, assuming this is adequate. Possibly we will somehow mirror Aston and there will be a VMS standard with U*ix having a different standard (I certainly hope this is NOT the case). I have earlier proposed ZIP archives; Rainer has pointed out ZOO as preferable, which is a debate in and of itself. Whatever does come of this, I hope that file structures can at least be common. This brings my meandering message to an end. Future messages will attempt to be more on-point; this is nothing more than some random thoughts at this point. What I hope is achieved by it was to get the breadth of this project to each of you, spawn some seeds for thought, and provide you some insight on topics to be considered. I believe that each of you can see at least one point in at least one of the preceding areas of concern where you have insights to share. As a group, I hope we can all learn together to achieve at least a base standard which can evolve gracefully. Wherever you care to begin, please feel free to do so. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% By the way, the present members are listed below. If I have left anyone you believe ought to be involved out, please let me know. -- GDG "George D. Greenwade" "Nelson Beebe" "Barbara Beeton" "Karl Berry" "Michael Ferguson" "Alan J. Hoenig" "Don Hosek" "David M. Jones" "David A. Osborne" "Jon Radel" "Rainer Schoepf" "Joachim Schrod" "Phil Taylor" From ITeX-Mgr@SHSU.edu Tue Jun 2 07:39:10 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09349; Tue, 2 Jun 92 07:39:05 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from theory.lcs.mit.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 02 Jun 1992 08:13:54 CDT Received: from GYRFALCON.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA26778; Tue, 02 Jun 92 09:13:16 EDT From: dmjones@theory.lcs.mit.edu (David M. Jones) Reply-To: TWG@SHSU.edu Received: by gyrfalcon.lcs.mit.edu (5.65c/TOC-1.2C) id AA03035; Tue, 02 Jun 92 09:08:58 EDT Date: Tue, 02 Jun 92 09:08:58 EDT Message-Id: <199206021308.AA03035@gyrfalcon.lcs.mit.edu> To: TWG@SHSU.edu In-Reply-To: "George D. Greenwade"'s message of Mon, 01 Jun 1992 16:39:12 CDT <0095B752.46D8C3A0.5446@SHSU.edu> Subject: The purpose of this list >Also, some form of possible standardization in headers, as proposed by >David Jones and as already seen in a few files, is probably desirable. Who >is to be responsible for these? If an author does not provide them, are >they not archived? Also, what about postings to sources such as >comp.text.tex, INFO-TeX, UKTeX and TeXhax, etc.? Who is to handle these >(if anyone) with respect to not only headers, but mere extraction? >Moreover, how is something like David's work in progress to be coordinated >as versions, packages, operating systems, etc., change? That is a task I >would hate to think is manual. Just so there's no confusion, let me hasten to point out that the headers I'm promoting in conjunction with my TeX Macro Index are indeed Nelson Beebe's headers. As Karl Berry already pointed out, if everyone put these headers on their macro files, much of the work for my Index could be done automatically (though there are still a few fuzzy things that would have to be done by hand). Incidentally, I'm currently sending mail to all the authors listed in the Index asking them to proofread the entries I have under their name. As part of this message, I'm encouraging people to adopt these headers. Some of you have already received such messages; most of the rest will receive them shortly. So far reactions have been favorable: no-one has refused to use the headers. On the other hand, I've only gotten responses to 8 messages out of the 22 that I sent out last Friday. On the subject of how my Index and Nelson's file headers can be coordinated with the Archives, here's a low-tech solution that might be worth considering: Whenever someone submits a file to the archive, send a formletter back urging them to add headers to their file and to send me an Index entry for the package. Assuming that some sort of acknowledgement is routinely sent back already, this shouldn't require too much extra work. This isn't very elegant but it has the advantage that it can be implemented immediately. Of course, I'd be happy to hear about better ideas. Oh, and before I forget, there's one thing we have to keep in mind when discussing the headers and how they relate to my Index and the TeX Archives: The headers are meant to be used for essentially any text file. So, we should make sure that we don't try to restrict them so far that they become useful only for TeX macros. Cheers, David. From beebe Tue Jun 2 08:42:47 1992 Flags: 000000000001 Return-Path: Received: from solitude.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09771; Tue, 2 Jun 92 08:42:26 MDT Date: Tue, 2 Jun 92 08:42:26 MDT From: Nelson H. F. Beebe To: TWG@SHSU.edu Cc: beebe, TWG X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Re: The purpose of this list In-Reply-To: Your message of Tue, 2 JUN 92 14:17:28 BST Message-Id: Phil Taylor observers that the filehdr package is editor specific. This is indeed so. However, the design is such that it can be straightforwardly replicated in other programmable editors, such as jove, brief, and epsilon. For those who prefer less powerful editors, it is easy to keep a template around that can be inserted into the editor buffer and filled in manually. The GNU Emacs filehdr package makes this easy to do, because it can supply more of the fields automatically, greatly ease their updating. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Tue Jun 2 05:19:46 1992 Flags: 000000000011 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09001; Tue, 2 Jun 92 05:19:44 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 02 Jun 1992 06:16:59 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA10462; Tue, 2 Jun 1992 07:16:50 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA00562; Tue, 2 Jun 92 07:16:49 EDT Date: Tue, 2 Jun 92 07:16:49 EDT From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <9206021116.AA00562@claude.cs.umb.edu> To: TWG@SHSU.edu Subject: Re: The purpose of this list George et al., Just a quick response to one part of your note, about file headers: Nelson Beebe started (several years ago, I think) a project for standardizing header information. It's not TeX-specific, but many TeX-related files are using it now: the AMS, me, him, ... ? You can get it by ftp from math.utah.edu:pub/tex/bib/filehdr.tar.z (I think that's the path...). If all macro writers did this, that would be more than enough information for David's Indexing project. K From ITeX-Mgr@SHSU.edu Tue Jun 2 07:27:10 1992 Flags: 000000000011 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09303; Tue, 2 Jun 92 07:27:08 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 02 Jun 1992 08:17:35 CDT Via: vax.rhbnc.ac.uk; Tue, 2 Jun 1992 14:15:25 +0100 Date: Tue, 2 JUN 92 14:17:28 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: Re: The purpose of this list Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <20204872_000769D0.0095B807A33180A0$17_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) >>> Nelson Beebe started (several years ago, I think) a project for >>> standardizing header information. It's not TeX-specific, but >>> many TeX-related files are using it now: the AMS, me, him, ... ? >>> You can get it by ftp from math.utah.edu:pub/tex/bib/filehdr.tar.z >>> (I think that's the path...). >>> If all macro writers did this, that would be more than enough information >>> for David's Indexing project. Agreed it's not TeX-specific, but the mechanics of it are editor-specific. You can hardly expect everyone in the world to use the same editor, just so that they can generate headers for an indexing project :-! Philip Taylor, RHBNC From beebe Tue Jun 2 07:39:38 1992 Flags: 000000000001 Return-Path: Received: from solitude.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09372; Tue, 2 Jun 92 07:39:17 MDT Date: Tue, 2 Jun 92 07:39:17 MDT From: Nelson H. F. Beebe To: TWG@SHSU.edu Cc: beebe X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Re: The purpose of this list In-Reply-To: Your message of Mon, 01 Jun 1992 16:39:12 CDT Message-Id: I think it would be helpful if someone from each archive site were to give a diskuse listing indicating the storage currently needed, with possibly some remarks on the growth rate. Disks are becoming cheaper ($1795 for 1.2GB SCSI is the lowest I've seen recently), and a larger number of sites might be interested in providing mirrors of major archives if they had a clearer idea of the space requirements. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Tue Jun 2 07:56:21 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09461; Tue, 2 Jun 92 07:56:16 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 02 Jun 1992 08:39:32 CDT Received: from solitude.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09372; Tue, 2 Jun 92 07:39:17 MDT Date: Tue, 2 Jun 92 07:39:17 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Re: The purpose of this list In-Reply-To: Your message of Mon, 01 Jun 1992 16:39:12 CDT Message-Id: I think it would be helpful if someone from each archive site were to give a diskuse listing indicating the storage currently needed, with possibly some remarks on the growth rate. Disks are becoming cheaper ($1795 for 1.2GB SCSI is the lowest I've seen recently), and a larger number of sites might be interested in providing mirrors of major archives if they had a clearer idea of the space requirements. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From beebe Tue Jun 2 08:39:00 1992 Flags: 000000000001 Return-Path: Received: from solitude.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09725; Tue, 2 Jun 92 08:38:27 MDT Date: Tue, 2 Jun 92 08:38:27 MDT From: Nelson H. F. Beebe To: TWG@SHSU.edu Cc: beebe X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 In-Reply-To: Your message of Tue, 2 Jun 92 07:16:49 EDT Subject: Standard file headers for archive files Message-Id: My filehdr package is found on ftp.math.utah.edu in ~ftp/pub/tex/bib/filehdr-1.19.tar.z (a compressed tar file). The contents (recorded in filehdr-1.19.tar-lst) are currently: drwxr-sr-x beebe/staff 0 Jun 2 08:28 1992 filehdr-1.19/ -rw-r--r-- beebe/staff 2597 Jun 2 08:28 1992 filehdr-1.19/Makefile -rw-r--r-- beebe/staff 3428 Dec 12 15:32 1991 filehdr-1.19/filehdr.bib -rw-r--r-- beebe/staff 57976 May 29 10:27 1992 filehdr-1.19/filehdr.el -rw-r--r-- beebe/staff 73392 Jun 2 08:17 1992 filehdr-1.19/filehdr.info -rw-r--r-- beebe/staff 81833 May 29 12:11 1992 filehdr-1.19/filehdr.ltx -rw-r--r-- beebe/staff 676 May 29 11:32 1992 filehdr-1.19/filehdr.spell-okay -rwxr-xr-x beebe/staff 642 Dec 15 00:19 1991 filehdr-1.19/makeinfo -rw-r--r-- beebe/staff 4668 Dec 15 00:14 1991 filehdr-1.19/rcs.sty Following the GNU Project practice, the tar file contains the version number, and when unbundled on UNIX, it will unbundle into a directory tagged by the version number. I expect to add a zip and/or zoo file version of the archive as well, and the .spell-okay file will probably be renamed with a shorter extension. This distribution includes the GNU Emacs filehdr.el code, LaTeXinfo documentation in filehdr.ltx, on-line Emacs info documentation in filehdr.info, and a Makefile. filehdr.info is supplied so that it is not necessary to have LaTeXinfo installed to create the info documentation. While largely stable, this package is undergoing small evolutionary changes as I get more feedback from users. The version number is currently 1.19, but can be expected increase in the future. This package is freely available under the terms of the GNU Public License. To use it, you will also require the checksum utility found in ~ftp/pub/tex/pub/checksum/checksum.tar.z. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Tue Jun 2 09:08:53 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09904; Tue, 2 Jun 92 09:08:48 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 02 Jun 1992 09:42:40 CDT Received: from solitude.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09771; Tue, 2 Jun 92 08:42:26 MDT Date: Tue, 2 Jun 92 08:42:26 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Cc: beebe@math.utah.edu, TWG X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Re: The purpose of this list In-Reply-To: Your message of Tue, 2 JUN 92 14:17:28 BST Message-Id: Phil Taylor observers that the filehdr package is editor specific. This is indeed so. However, the design is such that it can be straightforwardly replicated in other programmable editors, such as jove, brief, and epsilon. For those who prefer less powerful editors, it is easy to keep a template around that can be inserted into the editor buffer and filled in manually. The GNU Emacs filehdr package makes this easy to do, because it can supply more of the fields automatically, greatly ease their updating. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Tue Jun 2 09:11:49 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09943; Tue, 2 Jun 92 09:11:39 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 02 Jun 1992 09:42:40 CDT Received: from solitude.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09771; Tue, 2 Jun 92 08:42:26 MDT Date: Tue, 2 Jun 92 08:42:26 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Cc: beebe@math.utah.edu, TWG X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Re: The purpose of this list In-Reply-To: Your message of Tue, 2 JUN 92 14:17:28 BST Message-Id: Phil Taylor observers that the filehdr package is editor specific. This is indeed so. However, the design is such that it can be straightforwardly replicated in other programmable editors, such as jove, brief, and epsilon. For those who prefer less powerful editors, it is easy to keep a template around that can be inserted into the editor buffer and filled in manually. The GNU Emacs filehdr package makes this easy to do, because it can supply more of the fields automatically, greatly ease their updating. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Tue Jun 2 09:13:46 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09959; Tue, 2 Jun 92 09:13:37 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from VAX01.AMS.COM by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 02 Jun 1992 09:15:22 CDT Received: from MATH.AMS.COM by MATH.AMS.COM (PMDF #041B2) id <01GKQHEDIUJKEMWRP3@MATH.AMS.COM>; Tue, 2 Jun 1992 10:14:20 EST Date: 02 Jun 1992 10:14:19 -0400 (EDT) From: bbeeton Reply-To: TWG@SHSU.edu Subject: standardizing header information In-Reply-To: <20204872_000769D0.0095B807A33180A0$17_1@UK.AC.RHBNC.VAX> To: TWG@SHSU.edu Cc: P.Taylor%Vax.Rhbnc.Ac.Uk@NSFnet-Relay.AC.UK Message-Id: <707494459.203074.BNB@MATH.AMS.COM> Content-Transfer-Encoding: 7BIT Mail-System-Version: phil taylor points out that the mechanics of nelson beebe's headers are editor-specific. well, nelson has automated the process of building them via emacs, but it's definitely not necessary to use this technique to install such headers. most of the tex staff here at ams don't use emacs, but eve (i'm not among them). but we still put headers of the suggested form onto the macro, documentation, etc., files distributed by ams. (not .tfm or .*pk files, of course; perhaps some "standard" identification mechanism could be devised for those?) it's quite easy, really -- just copy a header from an existing file (we "bootstrapped" ours from one of nelson's texbook* files) and edit in suitable changes. okay, the checksum won't be fully realized, but there's a recognized alternate form containing the number of lines in the file. this isn't at all difficult, and is well worth the time spent. perhaps a small library of models/outlines could be installed at the various archives, and cited in the acknowledgement to authors submitting new items to the archives. and if some standard submission procedure is agreed on, i'd be delighted if someone would write it up for tugboat. -- bb From ITeX-Mgr@SHSU.edu Tue Jun 2 09:24:34 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10075; Tue, 2 Jun 92 09:24:25 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 02 Jun 1992 09:38:45 CDT Received: from solitude.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09725; Tue, 2 Jun 92 08:38:27 MDT Date: Tue, 2 Jun 92 08:38:27 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 In-Reply-To: Your message of Tue, 2 Jun 92 07:16:49 EDT Subject: Standard file headers for archive files Message-Id: My filehdr package is found on ftp.math.utah.edu in ~ftp/pub/tex/bib/filehdr-1.19.tar.z (a compressed tar file). The contents (recorded in filehdr-1.19.tar-lst) are currently: drwxr-sr-x beebe/staff 0 Jun 2 08:28 1992 filehdr-1.19/ -rw-r--r-- beebe/staff 2597 Jun 2 08:28 1992 filehdr-1.19/Makefile -rw-r--r-- beebe/staff 3428 Dec 12 15:32 1991 filehdr-1.19/filehdr.bib -rw-r--r-- beebe/staff 57976 May 29 10:27 1992 filehdr-1.19/filehdr.el -rw-r--r-- beebe/staff 73392 Jun 2 08:17 1992 filehdr-1.19/filehdr.info -rw-r--r-- beebe/staff 81833 May 29 12:11 1992 filehdr-1.19/filehdr.ltx -rw-r--r-- beebe/staff 676 May 29 11:32 1992 filehdr-1.19/filehdr.spell-okay -rwxr-xr-x beebe/staff 642 Dec 15 00:19 1991 filehdr-1.19/makeinfo -rw-r--r-- beebe/staff 4668 Dec 15 00:14 1991 filehdr-1.19/rcs.sty Following the GNU Project practice, the tar file contains the version number, and when unbundled on UNIX, it will unbundle into a directory tagged by the version number. I expect to add a zip and/or zoo file version of the archive as well, and the .spell-okay file will probably be renamed with a shorter extension. This distribution includes the GNU Emacs filehdr.el code, LaTeXinfo documentation in filehdr.ltx, on-line Emacs info documentation in filehdr.info, and a Makefile. filehdr.info is supplied so that it is not necessary to have LaTeXinfo installed to create the info documentation. While largely stable, this package is undergoing small evolutionary changes as I get more feedback from users. The version number is currently 1.19, but can be expected increase in the future. This package is freely available under the terms of the GNU Public License. To use it, you will also require the checksum utility found in ~ftp/pub/tex/pub/checksum/checksum.tar.z. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From beebe Tue Jun 2 12:15:30 1992 Flags: 000000000001 Return-Path: Received: from solitude.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11648; Tue, 2 Jun 92 12:15:09 MDT Date: Tue, 2 Jun 92 12:15:09 MDT From: Nelson H. F. Beebe To: TWG@SHSU.edu Cc: beebe X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Portability of the checksum program Message-Id: The checksum program used by the file header package is highly portable, and can be made to run on almost any system with a C compiler. The distribution contains sources, plus an IBM PC executable. It will certainly build on VAX VMS; if there is a demand for it, I could put a VMS .exe file in the archive. checksum was carefully designed by Robert Solovay to produce the same results across different systems; in particular, its CRC-16 checksum is independent of the line terminator used (LF, CR, CR-LF, or other). The code is written in CWeb, but the C sources are included in the distribution so that one need not have CWeb installed to compile checksum. What is not yet in place is the automatic invocation of checksum by update-checksum in the GNU Emacs code; this requires the Emacs function call-process-region, which may not work on VAX VMS (interprocess communication in the VMS version of GNU Emacs is the one weak spot where facilities available under UNIX may not be completely working). I've been too busy myself to try it out on VMS, but perhaps one of the readers of this list would like to make the experiment. Consequently, for the time being, on VAX VMS, update-checksum just invokes the update-simple-checksum function, which produces a count of words, lines, and characters, like the UNIX wc utility. update-simple-checksum is written entirely in Emacs Lisp, so it works fine everywhere. Finally, I would like to point out that the complete GNU Emacs system has been ported to MS DOS, at least for those with 386 and 486 processors, and has been available since January 1992. Thus, both filehdr.el and my latex.el can be used on (large) IBM PC machines too. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Tue Jun 2 13:19:17 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12223; Tue, 2 Jun 92 13:18:56 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 02 Jun 1992 13:15:19 CDT Received: from solitude.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11648; Tue, 2 Jun 92 12:15:09 MDT Date: Tue, 2 Jun 92 12:15:09 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Portability of the checksum program Message-Id: The checksum program used by the file header package is highly portable, and can be made to run on almost any system with a C compiler. The distribution contains sources, plus an IBM PC executable. It will certainly build on VAX VMS; if there is a demand for it, I could put a VMS .exe file in the archive. checksum was carefully designed by Robert Solovay to produce the same results across different systems; in particular, its CRC-16 checksum is independent of the line terminator used (LF, CR, CR-LF, or other). The code is written in CWeb, but the C sources are included in the distribution so that one need not have CWeb installed to compile checksum. What is not yet in place is the automatic invocation of checksum by update-checksum in the GNU Emacs code; this requires the Emacs function call-process-region, which may not work on VAX VMS (interprocess communication in the VMS version of GNU Emacs is the one weak spot where facilities available under UNIX may not be completely working). I've been too busy myself to try it out on VMS, but perhaps one of the readers of this list would like to make the experiment. Consequently, for the time being, on VAX VMS, update-checksum just invokes the update-simple-checksum function, which produces a count of words, lines, and characters, like the UNIX wc utility. update-simple-checksum is written entirely in Emacs Lisp, so it works fine everywhere. Finally, I would like to point out that the complete GNU Emacs system has been ported to MS DOS, at least for those with 386 and 486 processors, and has been available since January 1992. Thus, both filehdr.el and my latex.el can be used on (large) IBM PC machines too. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Wed Jun 3 15:22:32 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24380; Wed, 3 Jun 92 15:22:24 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.EDU (MX V3.1B) with SMTP; Wed, 03 Jun 1992 15:14:51 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA05785; Wed, 3 Jun 1992 16:14:35 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA01823; Wed, 3 Jun 92 16:14:33 EDT Date: Wed, 3 Jun 92 16:14:33 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9206032014.AA01823@claude.cs.umb.edu> To: TWG@SHSU.edu In-Reply-To: Nelson H. F. Beebe's message of Tue, 2 Jun 92 07:39:17 MDT Subject: The purpose of this list Reply-To: TWG@SHSU.edu I think it would be helpful if someone from each archive site were to give a diskuse listing indicating the storage currently needed I don't know if you really want to know about ftp.cs.umb.edu, but here's the info. I'm quite interested in knowing about how much space is in use at real archive sites. Here is output from GNU du, showing use (by kbytes) in the tex/ FTP directory. 93 ./impatient/ 178 ./fontname-1.1/ 440 ./eplain-2.1/doc/ 98 ./eplain-2.1/test/ 237 ./eplain-2.1/ 8568 ./ As you can see, it's minimal. Almost half of the 8.5MB total is psfonts.tar, and another 25% or so is the web files. Here is a list of all the files over 200K: -rw-rw-r-- 1 karl wheel 246909 Apr 12 17:03 charter.tar.Z -rw-rw-r-- 1 karl wheel 253029 Apr 12 17:03 utopia.tar.Z -rw-rw-r-- 1 karl wheel 297645 Mar 26 06:40 eplain-2.1.tar.Z -rw-rw-r-- 1 karl wheel 302498 Dec 4 1991 kmusictex.tar.Z -rw-rw-rw- 1 karl wheel 410969 Jun 3 08:35 dvips-5.487l.tar.Z -rw-rw-rw- 1 karl wheel 637347 May 20 17:15 web2c-5.851c.tar.Z -rw-rw-rw- 1 karl tex 1627087 May 14 20:05 web-5.851c.tar.Z -rw-rw-r-- 1 karl wheel 4311040 May 14 19:06 psfonts.tar with possibly some remarks on the growth rate Minimal. The only things on ftp.cs.umb.edu are the things I maintain myself (aside from a few tiny things people have sent me), and I'm already at (over, really) my limit! K From ITeX-Mgr@SHSU.edu Sun Jun 7 17:11:29 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21676; Sun, 7 Jun 92 17:11:14 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 27039; Sun, 07 Jun 1992 18:08:37 CDT Date: Sun, 07 Jun 1992 18:08:34 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: twg@SHSU.edu Message-Id: <0095BC15.C108C400.27039@SHSU.edu> Subject: Standardized directory structure, reprise In looking back over a few posts from tex-archive (early April, 1992) regarding a common directory structure, I noticed a few things. Since this is within the scope of archiving and those commenting on tex-archive are on TWG, please allow me to make a few comments on this and to propose a directory scheme for consideration. First, I believe that, if mirroring is to be successful, the major archives involved in the mirroring (i.e., those which seek to be comprehensive) need to follow a common design. This is for user friendliness, if nothing else. Assuming rusinfo, ymir, shsu, and aston are the four major archives, the directory layout shouldn't matter to the user which machine they are on -- I would think a desirable goal would be to simply have differences in operating system be enough. Certainly, I am seeking input on this from those of you out there. Second, I believe that, in the absence of a dedicated TeX archive machine (we don't plan on using our machines exclusively for TeX, although it will be our largest collection; I assume the other sites are similarly situated), I propose that a common top-level directory be used for the archive. My preference would be for /TeX-archive or/TeX-mirror ([.TEX-ARCHIVE] or [.TEX-MIRROR] on VMS) as it identifies that this is a TeX archive. I dislike tex as the home name as it is unclear what is exactly there. Possibly this is device dependent at each site. Again, comments, please. Third, after looking over the prior tex-archive posts (these can be made available to anyone who wants them; there were four of consequence which I found), allow me to propose the following directory structure: /TeX-archive FILES.TXT -- (ls -lR or dir/size/date/wid=(file=30) [...] - type listing) FILES.ZIP -- FILES.TXT in zip format INDEX.TXT -- this file README.xxx -- README in various languages (xxx=language; .ENG=English, .GER=German, .ITA=Italian, etc.) TEX-FAQ.TXT -- c.t.t's FAQ -- let's provide the FAQ up front and not in a lower directory TEX-FAQ.SUPP -- TeX-FAQ-Supplement; see above TEX-MACRO.INDEX -- David's macro index now in the works UPDATE30.TXT -- new files in the past 30 days UPDATE7.TXT -- new files in the past 7 days Within this top-level directory, the following directories (with some comments on them): /TeX-archive/archive-tools Archiving tools, to include ZIP, UNZIP, FILEHDR, UU*CODE, VV*CODE (when available), others; each in its own subdir. /TeX-archive/conversion Converters for xxx2TeX, such as RTF2TeX, word2TeX, etc.; each in its own subdir. /TeX-archive/drivers {\em Original} sources for xxx2DVI drivers; each in its own subdir. Operating system-specific ports appear in /TeX-archive/systems/"OS"/drivers (where "OS" is the specific operating system. /TeX-archive/extensions /AMS /REVTEX /eplain /lamstex /text1 /bibtex others; each in its own subdir. LaTeX is the only one I exclude as it has a (potentially) broader set. This is for all extensions layered on top of TeX. /TeX-archive/fonts /AMSfonts /mf /pk (subdirs. based on pk size?) /PS (PostScript?) /tfm /utilities (font utilities; each in its own subdir.) /vf /TeX-archive/graphics /eepic /epic /pictex /xypic Graphic tools/interfaces for TeX; each in its own subdir. /TeX-archive/hints ASCII files on a variety of topics, including - using the archives - submitting to the archives - standard headers; point to /TeX-archive/archive-tools/filehdr - mirroring network; use closest site - comp.text.tex and various mailing lists available /TeX-archive/indexing Indexing tools; each in its own subdir. /TeX-archive/Knuth-books /metafontbook (files used with) /texbook (files used with) /TeX-archive/languages babel, japanese TeX, arabtex, hyphenation, etc.; all language-specific aspects; each in its own subdir. /TeX-archive/latex-style /base (minimally required; Lamport/Mittelbach/Schoepf files) /supported /unsupported with extended packages; each in its own subdir. of each /TeX-archive/periodicals /texhax each year; each in its own subdir. /texmag each volume; each in its own subdir. /textugnews or /ttn each volume; each in its own subdir. /uktex each year; each in its own subdir. /tugboat contents files /ctt (compressed comp.text.tex archives??) each year; each in its own subdir. /TeX-archive/systems /amiga /atari /mac /msdos /vax-vms /unix other systems; each in its own subdir. This will expand to all system-specific files, following when possible the design of the top-level /TeX-archive directory, such as TeX-archive/drivers above /TeX-archive/TeX-macro /base /supported /unsupported (as in latex-style above) /TeX-archive/tutorials /essential /gentle other tutorial-type documentation; seek course outlines as well for a good overview of teaching/learning TeX and its ancillaries /TeX-archive/users-groups /DANTE /TUG users groups; each in its own subdir. /TeX-archive/web-sources /cweb /mf /spiderweb /tex Web sources for various aspects. Could this be a workable and agreeable arrangement? I know that for other sites, this may be a somewhat monumental task, but it's a beginning on what I believe could be a very beneficial "coming in line" for the major archives. It has been mentioned that a variety of /mirrors/e-math.ams.com /mirrors/rusinfo.rus.uni-stuttgart.de /mirrors/tex.ac.uk etc., could be developed. This is a less than optimal solution as the user is still faced with who has what where. I believe that if we could mirror those sites into an agreed-to area, end users would be much better off. Moreover, if an agreed-to structure existed, it might be feasible to use /TeX-archive for non-comprehensive archiving sites as a device/directory specification (ftp.cs.umb.edu, could use pub/TeX-archive instead of pub/tex, for example) and /TeX-mirror could be used by the comprehensive mirroring sites (i.e., replace/ TeX-archive in the design above to /TeX-mirror). I think with a little leadership on what is expected to be where under what name, everyone will be better off. Clearly, I have overlooked some aspect in my design, this is where we need further guidance and some compromise between us. I am clearly soliciting flames, but flames are used in forging iron. The directory structure guidelines, once propogated, especially if followed by a few leading sites, can be an iron of great use. The logic I am trying to follow is (a) minimal subdirectories at the top level with (b) immediate user help and advice at the very top level which is (c) usable on all archive machines, regardless of size of collection. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Mon Jun 8 10:48:24 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25490; Mon, 8 Jun 92 10:48:20 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Mon, 08 Jun 1992 11:32:33 CDT Received: from solitude.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25392; Mon, 8 Jun 92 10:32:27 MDT Date: Mon, 8 Jun 92 10:32:27 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Re: Standardized directory structure, reprise In-Reply-To: Your message of Sun, 07 Jun 1992 18:08:34 CDT Message-Id: One small change that I would recommend making is the uniform use of lower-case letters in directory names. Mixed letter case is a pain, and causes difficulties in moving trees to non-UNIX systems. All unicase systems that I know of accept filenames in lower-case letters, so there should be no difficulty in remapping a UNIX tree onto those systems if care is taken in the naming of files (letter case, length, and number of periods). ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Tue Jun 9 04:00:52 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01997; Tue, 9 Jun 92 04:00:49 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 09 Jun 1992 04:56:52 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA07694; Tue, 9 Jun 1992 05:56:50 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA05004; Tue, 9 Jun 92 05:56:49 EDT Date: Tue, 9 Jun 92 05:56:49 EDT From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <9206090956.AA05004@claude.cs.umb.edu> To: TWG@SHSU.edu Subject: filenames in TeX archive George, I don't think a long filename scheme like you suggest can be used, because then people can't just transfer the files to DOS (or, in some cases, to a Unix with the 14-char limit on filenames). I think that would be a big lose. You have to get the additional information via directories, or in auxiliary indexes, or something. K From ITeX-Mgr@SHSU.edu Tue Jun 9 09:02:17 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03467; Tue, 9 Jun 92 09:02:12 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from VAX01.AMS.COM by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 09 Jun 1992 09:48:25 CDT Received: from MATH.AMS.COM by MATH.AMS.COM (PMDF #041B2) id <01GL0AM40X28EMWYTW@MATH.AMS.COM>; Tue, 9 Jun 1992 10:47:40 EST Date: 09 Jun 1992 10:47:39 -0400 (EDT) From: bbeeton Reply-To: TWG@SHSU.edu Subject: Re: Standardised directory structure / filenames In-Reply-To: <21A024BA_0018E1D8.0095BD8701049580$20_1@UK.AC.RHBNC.VAX> To: TWG@SHSU.edu Message-Id: <708101259.707372.BNB@MATH.AMS.COM> Content-Transfer-Encoding: 7BIT Mail-System-Version: [re what is `the root' of a file system] phil has pointed out that, for a system that is not dedicated to a tex archive, it would be reasonable to hang a tex-archive branch at some point appropriate for the system in question. with that interpretation, i withdraw my objection. i still wonder, however, how easy it will be for users of the archives to find out the route to this root; i guess it'll boil down to supplying good documentation. [re bug and errata files] i guess my situation is a bit unique in this area, being as i am the messenger from knuth to the tex implementors when new versions are released. but i find that having all this information together, as at labrea, allows me to find in one fell swoop everything i need to know about what has changed in the tex *system*, and what will likely have to be changed when putting a new version into production here. (that is, can we get away with updating only tex itself, or do we also have to install new fonts, and if the latter, is it necessary to update metafont because font updates were necessary because of a mf bug, etc., etc.) it might make sense to put this collection in a sub-node of documentation rather than scatter it. but if this view is in the minority, i'd learn to live with whatever is decided. [re version numbers] although i sympathize fully with the idea of making the version number of some program the last segment (in vms the "actual" version number), how does anyone propose to deal with the version numbers of tex and mf, converging as they do to pi and e? (i don't know about the rest of you guys, but i think that if we had to here, we could still put our hands on (archived) versions of tex from 0.999999 . and to be able to do that, it's quite necessary to, and we do, have the version numbers as part of the file names.) 3.141 --> 30141 is already the last version of tex that will fit into a 32767 limitation according to the technique proposed. or am i misunderstanding, and this becomes part of the main filename segment, as tex-3_141...? if so, then what would constitute the terminal version number? can someone provide an example where both version numbers are necessary or meaningful? -- bb From ITeX-Mgr@SHSU.edu Tue Jun 9 09:25:19 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03666; Tue, 9 Jun 92 09:25:16 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 1405; Tue, 09 Jun 1992 09:22:55 CDT Date: Tue, 09 Jun 1992 09:22:39 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095BD5E.9D867D20.1405@SHSU.edu> Subject: RE: Standardised directory structure / filenames On Tue, 9 JUN 92 14:11:47 BST, Philip Taylor posted a message I am in basic agreement with. I now see how we can use VMS filenames consistently; hopefully, some form of parsing to support this can be developed; if not manual handling is something we'll just have to do. Anyway, there is still one point I have some concern about (and this will, in all probability, be my last statement on this as I can live with the opinions of those of you kind enough to be following this): ||[reverse-sort-by-date of Files.Txt] ||>>> What I implied (not so well, though). I would leave these to 30 and 7 ||>>> days, respectively, though to reduce the file size for transfer ||>>> purposes. || But they age, and by day-31 all information is lost. If you keep a || Files.Txt/sorted-by-directory-and-name, and a || Files.Txt/reverse-sorted-by-age, then the information is never lost, and is || available in the two most convenient forms. (But I might add a third: || Files.Txt/sorted-by-name, to allow rapid location of something you are sure || is there, but don't know where it lives). If these all are available in || ZIPped form (see withdrawal of objection, above!), then size and speed of || transfer are improved, and the necessity for partial subsets is (IMHO) || eliminated. For users with unlimited disk space, this may be fine. The FILES.xxx file(s), if they are of the entire directory tree, will be *large* files. Your point that the 7 and 30 day files are dynamic is well-taken; however, the main FILES.xxx file(s) are also dynamic. The main FILES.xxx file(s) will not lose information, but be properly updated for the entire collection at each site (which ought to be parallel, for the most part anyway). Each day, the 7 and 30 day files will be outdated with some information lost (and added); each day, the main FILES.xxx file(s) will be outdated, but no information is lost, if you want access to it. The way I handle my ADDITIONS package, adding the 7 day and 30 day lookup only requires a few additional seconds of CPU and two lines of DCL code, which is not costly, even though Niord now runs at an average of 82% CPU use across the 24-hour day. The 7 and 30 day files are much smaller and provide information about only the most recent updates -- information which users are probably after. I don't have the file any longer, but (as I recall) the tex.ac.uk file listing was something like 2,000 VMS blocks -- about 1 meg! The "cost" in terms of disk space of retrieving the main FILES.xxx file(s) may be prohibitive, especially for users with limited disk space (particularly if they want all three variants). Fortunately, I essentially have system privs, as well as two devices on the VAXcluster and one on the HP which are mine and only mine, for a total access of somewhere around 13 gig at any point in time (and I do have things on virtually every drive -- that's why I can't leave SHSU; what other school would be so generous? 8-)). For me to bring in a 2,000+ block (~1 meg) file is painless; for many users it is not (for me to dedicate 1 meg on my PC's 40 meg hard drive would be something I would seriously hesitate to do, even though the comprehensive information would be there). As I said, I won't harp on this point any further, but for size reasons at retrieving sites and end users alone, I urge you to reassess your position. I promise to gracefully live with whatever Phil and the others recommend on this. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Tue Jun 9 09:42:36 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03818; Tue, 9 Jun 92 09:42:32 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 09 Jun 1992 10:37:29 CDT Via: vax.rhbnc.ac.uk; Tue, 9 Jun 1992 16:36:02 +0100 Date: Tue, 9 JUN 92 16:35:53 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: Nelson's macro markup schema Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <21A0225E_00164558.0095BD9B21E4A1A0$30_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: $TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) Following the earlier discussion as to whether we should recommend universal adoption of Nelson's macro markup schema (`NMMS') to simply and unify the creation of a TeX macro index, I had some private discussions with Barbara concerning suggested improvements to his system. What follows is intended to represent the synthesis of our views, 'though doubtless Barbara will correct me if I have misrepresented her position in any way... I have taken as example the Beebe/Taylor `Path.Sty' header, and re-expressed it in an alternative form. Let me say straight away that there are some points over which we have not reached total agreement: for example, Barbara believes that the `BibTeX'-style headers which Nelson pioneered are unexceptionable; I cannot see the point in coercing into a BibTeX style something which is clearly not a bibliographic entry (although I can certainly accept the `why re-invent the wheel' argument). My reason for rejecting the BibTeX style is the excessive punctuation overhead, which whilst trivial for the EMACS user (since it is put in automatically), is a real hassle for those who will have to add their headers by hand. I also object to `unnecessary' punctuation (why the `@'? why the string quotes?). I also have no sympathy for mailers so brain-damaged that they cannot cope with a line that is exactly 80 characters long without wrapping it! The rationale behind the proposed system is: 1) to re-order Nelson's elements into a more coherent order (`name' is crucial, and should appear as soon as the schema is known; `version' clearly applies to the code, not the to author which it follows in Nelson's version); 2) to add new fields which Barabara and I feel are useful (document schema, document type, compatibility, assumed, files input; 3) to remove the embedded description of the CRC field and add a keyword to the header; 4) to make the description more readable, by extending its measure; 5) miscellaneous cosmetic improvements. Philip Taylor, RHBNC. -------- %%% Document schema: TeX header markup V1.0 (02-JUN-1992) %%% Name: Path.TeX %%% Version: 3.03 %%% Timestamp: 18 December 1991 17:47:20 MST %%% Encoding: ISO/ASCII %%% Document type: TeX macro %%% Compatibility: Plain TeX, AMSTeX, LaTeX %%% Keywords: file name, filename, path name, pathname, %%% discretionary, discretionaries %%% Supported: yes %%% Assumed: (e.g. NFSS: required, but not \input) %%% Files input: %%% Checksum: 41143 321 1758 13526 (Solovay) %%% Author: Philip Taylor %%% Address: The Computer Centre %%% RHBNC, University of London %%% Egham Hill %%% Egham, Surrey TW20 0EX, ENGLAND %%% Telephone: +44 784 443172 %%% Fax: +44 784 434348 %%% E-mail: P.Taylor@Vax.Rhbnc.Ac.Uk (Internet) %%% Description: %%% %%% Computer filenames, host names, and e-mail addresses tend to be long %%% strings that cause line breaking problems for TeX. Sometimes rather long %%% strings are encountered; here are two examples: %%% %%% %%% %%% EndDescription: From ITeX-Mgr@SHSU.edu Tue Jun 9 11:31:36 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04665; Tue, 9 Jun 92 11:31:32 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 09 Jun 1992 12:19:55 CDT Via: vax.rhbnc.ac.uk; Tue, 9 Jun 1992 18:19:45 +0100 Date: Tue, 9 JUN 92 18:19:36 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: Re: Nelson's macro markup schema Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <21A02C89_000773B8.0095BDA99FB13040$17_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) >>> i think i didn't make clear to phil the reason for the extra >>> punctuation and delimiters -- to simplify parsing. i think it's >>> not impossible to envision a situation in which some of the suggested >>> tags occur in the descriptive text of a header, even to being followed >>> by a colon. i suppose that can be overcome by requiring that the tags >>> be fixed in position and order. however, i find the notion of >>> positional inflexibility as onerous as phil finds extra punctuation. Point taken. I modelled my syntax on RFC-822, which is known to be parseable, extending it by (a) allowing LWSP within keywords; (b) allowing as an RHS production to imply augmented syntax. ** P. From ITeX-Mgr@SHSU.edu Tue Jun 9 11:39:22 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04775; Tue, 9 Jun 92 11:39:20 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 2317; Tue, 09 Jun 1992 12:35:30 CDT Date: Tue, 09 Jun 1992 12:35:19 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095BD79.87C1B840.2317@SHSU.edu> Subject: Re: Standardised directory structure / filenames On Tue, 9 JUN 92 16:53:54 BST, "Phil Taylor" posted: > I take Barbara's point... I withdraw my own proposal. There is also an > objection that, if the (VMS) archive is partially maintained by other than > the (TeX) archiver, the VMS version numbers could change unintentionally. > Perhaps better to ignore them. ** Phil. Quick question to Rainer (or anyone else working on the mirroring): Since this is basically a filename parsing issue, what strategy (if any) are you considering employing? Assuming that a Unix can access a VMS site (I'll not ask about VMS as the mirror'er), if a standardized approach to parsing existed, could the Unix site both put the files on the VMS host and get the new files from it? --George From ITeX-Mgr@SHSU.edu Tue Jun 9 12:09:45 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05051; Tue, 9 Jun 92 12:09:41 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from theory.lcs.mit.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 09 Jun 1992 13:06:16 CDT Received: from GYRFALCON.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA28603; Tue, 09 Jun 92 14:01:58 EDT From: dmjones@theory.lcs.mit.edu (David M. Jones) Reply-To: TWG@SHSU.edu Received: by gyrfalcon.lcs.mit.edu (5.65c/TOC-1.2C) id AA07797; Tue, 09 Jun 92 13:57:34 EDT Date: Tue, 09 Jun 92 13:57:34 EDT Message-Id: <199206091757.AA07797@gyrfalcon.lcs.mit.edu> To: TWG@SHSU.edu In-Reply-To: CHAA006@VAX.RHBNC.AC.UK's message of Tue, 9 JUN 92 16:35:53 BST <21A0225E_00164558.0095BD9B21E4A1A0$30_1@UK.AC.RHBNC.VAX> Subject: Nelson's macro markup schema Although normally I'd let Nelson defend his header proposal (since he's in a better position than I to do so), there are a few parts of Phil's message that I want to comment on. >Following the earlier discussion as to whether we should recommend >universal adoption of Nelson's macro markup schema (`NMMS') to simply >and unify the creation of a TeX macro index, This is the first and most important comment: We should not recommend adoption of Nelson's scheme solely to facilitate creation of the TeX macro index. It's true that I'm promoting the headers in conjunction with the Index and I hope that eventually the headers will make the Index simpler to maintain. However, the linkage between the two packages is largely accidental. As Nelson's proposal makes clear, the scope of the headers goes far beyond TeX macro files. The headers are meant to apply to any text file which might be shared between machines. It would be a colossal mistake to make any changes to the headers that would limit their usefulness to TeX macros. >[..] Barbara believes >that the `BibTeX'-style headers which Nelson pioneered are >unexceptionable; I cannot see the point in coercing into a BibTeX >style something which is clearly not a bibliographic entry (although >I can certainly accept the `why re-invent the wheel' argument). The main reason, as I see it, for a BibTeX-style syntax is ease of parsing (Barbara has already pointed this out). If the headers were meant to be read only by humans, I would agree with Phil's objections. However, they are explicitly meant to be machine-parseable. To that end, they must have a uniform and unambiguous syntax. >My >reason for rejecting the BibTeX style is the excessive punctuation >overhead, which whilst trivial for the EMACS user (since it is put in >automatically), is a real hassle for those who will have to add their >headers by hand. If your editor is at all programmable, or at least allows you to define abbreviations, there is no reason for you to ever have to type in the entire template by hand. Nelson has already mentioned the need to write packages similar to filehdr.el for other editors. Maybe it would also be a good idea to write a minimal header-generator in CWEB to complement the checksum program? (Maybe this should even be an option to the checksum program?) > I also object to `unnecessary' punctuation (why the `@'? Actually, the @-sign is explicity stated in the proposal to be optional. However, this leads to a potential problem in parsing, namely detecting the presence of a header. It might be a good idea to surround the header by , tags in some appropriately unambiguous syntax. >why the string quotes?). Ease of parsing again. Personally, I prefer braces, which at least have some handedness. Any header-parsing software should be very forgiving in this regard. (Again, Nelson makes this clear in the proposal.) I also have no sympathy for mailers >so brain-damaged that they cannot cope with a line that is exactly 80 >characters long without wrapping it! Neither do I, but if I want my messages to survive intact, I keep the lines less than 80 characters. >The rationale behind the proposed system is: 1) to re-order Nelson's >elements into a more coherent order (`name' is crucial, and should >appear as soon as the schema is known; `version' clearly applies to >the code, not the to author which it follows in Nelson's version); The order of the field names is specifically stated to be irrelevent, except in the case of duplicates, where the later instance wins. On the other hand, it certainly makes sense to discuss what the "canonical" order should be for the sake of user-friendliness. > 2) to add new fields which Barabara and I feel are useful (document >schema, document type, compatibility, assumed, files input; This is definitely an important issue. The list of field names mentioned in the documentation isn't meant to be complete. On the other hand, if we are ever going to realize the goal of having programs that can parse the headers intelligently, as opposed to merely reordering them, there has to be some sort of standard set of recognized fields. The list of canonical fields will probably depend on the type of file, though. > 3) to remove the embedded description of the CRC field and add a >keyword to the header; Although nothing in the standard requires that this description be there, it might be a good idea to keep it around for a while to help spread the word about the headers and checksum. Cheers, David. From ITeX-Mgr@SHSU.edu Mon Jun 8 04:58:35 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24008; Mon, 8 Jun 92 04:58:30 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Mon, 08 Jun 1992 05:57:42 CDT Via: vax.rhbnc.ac.uk; Mon, 8 Jun 1992 11:57:22 +0100 Date: Mon, 8 JUN 92 11:57:13 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: RE: Standardized directory structure, reprise Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <21A00C86_00154B10.0095BCAB0A44D380$17_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) [There is far too much detail for me to be able to respond immediately; what follows are just what I regard as the `critical areas'] ** Phil. -------- >>> Second, I believe that, in the absence of a dedicated TeX archive machine >>> (we don't plan on using our machines exclusively for TeX, although it will >>> be our largest collection; I assume the other sites are similarly >>> situated), TeX.Ac.Uk is a dedicated TeX archive machine. >>> I propose that a common top-level directory be used for the >>> archive. My preference would be for /TeX-archive or/TeX-mirror >>> ([.TEX-ARCHIVE] or [.TEX-MIRROR] on VMS) as it identifies that this is a The VMS equivalents are [TeX-archive] & [TeX-mirror]; no leading period. /TeX-Archive: FILES.TXT -- (ls -lR or dir/size/date/wid=(file=30) [...] - type listing) >>> FILES.ZIP -- FILES.TXT in zip format Not convinced we need both plain text and compressed forms INDEX.TXT -- this file README.xxx -- README in various languages (xxx=language; .ENG=English, .GER=German, .ITA=Italian, etc.) >>> TEX-FAQ.TXT -- c.t.t's FAQ -- let's provide the FAQ up front and not in a >>> lower directory >>> TEX-FAQ.SUPP -- TeX-FAQ-Supplement; see above >>> TEX-MACRO.INDEX -- David's macro index now in the works Definitely think these should be in a subsidiary directory: [.Documentation] >>> UPDATE30.TXT -- new files in the past 30 days >>> UPDATE7.TXT -- new files in the past 7 days I'd replace both of these with a reverse-sort-by-date of Files.Txt. Within this top-level directory, the following directories (with some comments on them): /TeX-archive/archive-tools Archiving tools, to include ZIP, UNZIP, FILEHDR, UU*CODE, VV*CODE (when available), others; each in its own subdir. /TeX-archive/conversion Converters for xxx2TeX, such as RTF2TeX, word2TeX, etc.; each in its own subdir. /TeX-archive/drivers {\em Original} sources for xxx2DVI drivers; each in its own subdir. Operating system-specific ports appear in /TeX-archive/systems/"OS"/drivers (where "OS" is the specific operating system. /TeX-archive/extensions /AMS /REVTEX /eplain /lamstex /text1 >>> Bibtex I don't see Bibtex as an extension at all, but as an independent adjunct. >>> others; each in its own subdir. LaTeX is the only one I exclude as it has >>> a (potentially) broader set. This is for all extensions layered on top of >>> TeX. Don't think LaTeX should be singled out for special treatment; destroys orthogonality. >>> /TeX-archive/fonts >>> /AMSfonts >>> /gf >>> /pk (subdirs. based on pk size?) >>> /PS (PostScript?) >>> /tfm >>> /utilities (font utilities; each in its own subdir.) >>> /vf I think this is a hotch-potch; /fonts: yes; /fonts/: no. We need more structure here. Is there a tacit attempt to restrict hierarchy levels to two ? /TeX-archive/graphics /eepic /epic /pictex /xypic Graphic tools/interfaces for TeX; each in its own subdir. >>> /TeX-archive/hints >>> ASCII files on a variety of topics, including >>> - using the archives >>> - submitting to the archives >>> - standard headers; point to /TeX-archive/archive-tools/filehdr >>> - mirroring network; use closest site >>> - comp.text.tex and various mailing lists available This is where the FAQs should go. /TeX-archive/indexing Indexing tools; each in its own subdir. >>> /TeX-archive/Knuth-books >>> /metafontbook (files used with) >>> /texbook (files used with) Why not `/Books', and add other p/d m/c-readable TeX-related books here. >>> /TeX-archive/languages >>> babel, japanese TeX, arabtex, hyphenation, etc.; all language-specific >>> aspects; each in its own subdir. Bit worried about including hyphenation here ... /TeX-archive/latex-style /base (minimally required; Lamport/Mittelbach/Schoepf files) /supported /unsupported with extended packages; each in its own subdir. of each /TeX-archive/periodicals /texhax each year; each in its own subdir. /texmag each volume; each in its own subdir. /textugnews or /ttn each volume; each in its own subdir. /uktex each year; each in its own subdir. /tugboat contents files /ctt (compressed comp.text.tex archives??) each year; each in its own subdir. /TeX-archive/systems /amiga /atari /mac /msdos /vax-vms /unix other systems; each in its own subdir. This will expand to all system-specific files, following when possible the design of the top-level /TeX-archive directory, such as TeX-archive/drivers above /TeX-archive/TeX-macro /base /supported /unsupported (as in latex-style above) /TeX-archive/tutorials /essential /gentle other tutorial-type documentation; seek course outlines as well for a good overview of teaching/learning TeX and its ancillaries /TeX-archive/users-groups /DANTE /TUG users groups; each in its own subdir. /TeX-archive/web-sources /cweb /mf /spiderweb /tex Web sources for various aspects. Philip Taylor, RHBNC. From ITeX-Mgr@SHSU.edu Mon Jun 8 12:11:28 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26361; Mon, 8 Jun 92 12:11:20 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 29843; Mon, 08 Jun 1992 09:35:25 CDT Date: Mon, 08 Jun 1992 09:34:52 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095BC97.28147280.29843@SHSU.edu> Subject: RE: Standardized directory structure, reprise On Mon, 8 JUN 92 11:57:13 BST, Phil Taylor replied: || [There is far too much detail for me to be able to respond immediately; || what follows are just what I regard as the `critical areas'] ** Phil. Thanks for at least even considering a reply! As a fellow VMS site, but one which is much larger, older, and experienced than we are, I am especially interested in your response. While we will probably support both a VMS and a Unix archive, I have to know the dimensions, limitations, and problems you foresee on VMS. || TeX.Ac.Uk is a dedicated TeX archive machine. I *knew* that; sorry, a long Sunday in the office can make one forgetful. || >>> I propose that a common top-level directory be used for the || >>> archive. My preference would be for /TeX-archive or/TeX-mirror || >>> ([.TEX-ARCHIVE] or [.TEX-MIRROR] on VMS) || || The VMS equivalents are [TeX-archive] & [TeX-mirror]; no leading period. Correct. I was assuming an immediate directory structure within the default login directory for anonymous. For dedicated archives (as yours), this is correct; for non-dedicated archives (as ours), I would seriously hesitate to place a true top-level directory which is not apparent to the user, so [.xxx] would be appropriate. /TeX-Archive: FILES.TXT -- (ls -lR or dir/size/date/wid=(file=30) [...] - type listing) || >>> FILES.ZIP -- FILES.TXT in zip format || || Not convinced we need both plain text and compressed forms Sort of agree; this is simply in following with prior posts. The only benefit I can see is that a zipped file is much smaller, can be achieved somewhat effortlessly by the archive site, and creates less overhead for transfers. More appropriately, the VMS command I was after was dir/size/date/wid=(file=45)/nohead/notrail [...] If you have another VMS-type suggestion for this (or a program for doing so), please pass it along or tell me where to get it from. || >>> TEX-FAQ.TXT -- c.t.t's FAQ -- let's provide the FAQ up front and not || in a || >>> lower directory || >>> TEX-FAQ.SUPP -- TeX-FAQ-Supplement; see above || >>> TEX-MACRO.INDEX -- David's macro index now in the works || || Definitely think these should be in a subsidiary directory: [.Documentation] I can live with the FAQ's going into /documentation or /hints; I believe the macro index (macros are what most people will be after) ought to be an up-front file, though. Also, I prefer the /hints directory specification as it is a little clearer to the user, IMO. || >>> UPDATE30.TXT -- new files in the past 30 days || >>> UPDATE7.TXT -- new files in the past 7 days || || I'd replace both of these with a reverse-sort-by-date of Files.Txt. What I implied (not so well, though). I would leave these to 30 and 7 days, respectively, though to reduce the file size for transfer purposes. Possibly Rainer can give some insight as to what the mirror software might require along these lines? || /TeX-archive/extensions || /AMS || /REVTEX || /eplain || /lamstex || /text1 || >>> Bibtex || || I don't see Bibtex as an extension at all, but as an independent adjunct. Agreed. However, the adjunct might need to be in /TeX-archive/bibliography (or /TeX-archive/biblio-tools) with /bibtex as a subdir. within that hierarchy. The reason is parallel to the /indexing, wherein additional bibliographic tools can be placed. || >>> others; each in its own subdir. LaTeX is the only one I exclude as || it has || >>> a (potentially) broader set. This is for all extensions layered on || top of || >>> TeX. || || Don't think LaTeX should be singled out for special treatment; || destroys orthogonality. I can easily live with that. The reason was to create a parallel between /TeX-macro and /latex-style at the same level in the directory structure. While this impacts orthogonality, I believe it would be easier for the user to comprehend. Further comments, please?? || >>> /TeX-archive/fonts || >>> /AMSfonts || >>> /gf || >>> /pk (subdirs. based on pk size?) || >>> /PS (PostScript?) || >>> /tfm || >>> /utilities (font utilities; each in its own subdir.) || >>> /vf || || I think this is a hotch-potch; /fonts: yes; /fonts/: no. || We need more structure here. Is there a tacit attempt to restrict hierarchy || levels to two ? There is no attempt to restrict hierarchy to any number of levels; what I tried to do was create a simple top- and second-level directory tree which could be useful. I believe that putting the various font-types into their own branch of the tree would be beneficial. For example, I would love to be able to go to /fonts/pk/300 and find all xxxxxx.300pk files (or, alternately, /fonts/pk/cmr and find all cmrxxx.yyypk files); similarly for tfm, gf, PS, vf, etc. I must admit that this is one area where I have *very* limited expertise and am looking for guidance. || >>> /TeX-archive/hints || ... || This is where the FAQs should go. Agreed, but not the marco index for reasons given above. || >>> /TeX-archive/Knuth-books || >>> /metafontbook (files used with) || >>> /texbook (files used with) || || Why not `/Books', and add other p/d m/c-readable TeX-related books here. Good suggestion. Where else would something like the tex-by-example files go if not in this design? Thanks! Comments?? || >>> /TeX-archive/languages || >>> babel, japanese TeX, arabtex, hyphenation, etc.; all language-specific || >>> aspects; each in its own subdir. || || Bit worried about including hyphenation here ... Why? Hyphenation patterns are highly language-dependent. I can't see creating another high-level directory for something which is logically within the structure I have proposed. Again, I am open to further comments as this is not a clear issue. I know from past posts that others of you have prejudices in all directions of this. Please pass them along so we can air them out. I strongly believe that getting an agreed-to structure is imperative (maybe you don't; if so, please comment on this, as well -- Karl, Barbara and others: if a generally agreed to tree was available, might your site attempt to parallel it somewhat in your archives for your packages?). Regards and thanks, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Mon Jun 8 13:17:11 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26849; Mon, 8 Jun 92 13:17:07 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from VAX01.AMS.COM by Niord.SHSU.edu (MX V3.1B) with SMTP; Mon, 08 Jun 1992 13:35:53 CDT Received: from MATH.AMS.COM by MATH.AMS.COM (PMDF #041B2) id <01GKZ3IFP180EMWXBE@MATH.AMS.COM>; Mon, 8 Jun 1992 14:35:13 EST Date: 08 Jun 1992 14:35:12 -0400 (EDT) From: bbeeton Reply-To: TWG@SHSU.edu Subject: RE: Standardized directory structure, reprise In-Reply-To: <0095BC97.28147280.29843@SHSU.edu> To: TWG@SHSU.edu Message-Id: <708028512.342800.BNB@MATH.AMS.COM> Content-Transfer-Encoding: 7BIT Mail-System-Version: this is only an interim comment on the discussion about structuring archives. i've asked the folks in charge here to comment on the proposed structure and what it might imply for ams's e-math. i do know that the /ams/... structure is *not* the top level, and that this node is definitely not dedicated to tex, much less to a tex archive, so it is quite inappropriate for us to call the root /tex-archive . also, since we don't expect to be archiving anything here but what originates at ams, and we do try periodically to check the other archives to make sure they're up to date, i was cheered to see in george's list distinct areas for /amsfonts and /ams macros. of course having a totally parallel structure would make checking relatively easy for us, and would also mean that we could write one good set of documentation and have it apply to any "consenting" archive. however, exactly what adjustments we would consider making for the sake of uniformity and mirroring, especially if radical changes are involved, or mixing of ams items with others, i don't know without answers from management. one archive i think we can't expect to change is labrea. although a lot of people still think of this as the final authority, i believe it is now reliable only for items that originate with knuth. since aston and stuttgart, at least, have been coping with this for some time, i suggest that whatever techniques they use be shared with others, and this just be lived with. which reminds me, i don't remember seeing any obvious place for items like the trip and trap tests and the (extensive) collection of .bug and errata files from labrea. did i miss something? -- bb From ITeX-Mgr@SHSU.edu Mon Jun 8 13:35:36 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27072; Mon, 8 Jun 92 13:35:31 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 31251; Mon, 08 Jun 1992 14:03:02 CDT Date: Mon, 08 Jun 1992 14:02:38 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095BCBC.8FFA3220.31251@SHSU.edu> Subject: RE: Standardized directory structure, reprise On 08 Jun 1992 14:35:12 -0400 (EDT), bbeeton posted: > i've asked the folks in charge here to comment on the proposed structure > and what it might imply for ams's e-math. i do know that the /ams/... > structure is *not* the top level, and that this node is definitely not > dedicated to tex, much less to a tex archive, so it is quite inappropriate > for us to call the root /tex-archive . What would be a good top-level name which might be consistent? I believe that having something consistent among the archives as a top-level name is quasi-important, but I may be alone on this. > also, since we don't expect to be archiving anything here but what > originates at ams, and we do try periodically to check the other archives > to make sure they're up to date, i was cheered to see in george's list > distinct areas for /amsfonts and /ams macros. of course having a totally > parallel structure would make checking relatively easy for us, and would > also mean that we could write one good set of documentation and have it > apply to any "consenting" archive. This was specifically my intent. If the original author(s) had the ability to promulgate a common set of documentation, it would cut down on administrative details for other sites. A common (or at least well known) directory tree is necessary to achieve this, though. > which reminds me, i don't remember seeing any obvious place for items like > the trip and trap tests and the (extensive) collection of .bug and errata > files from labrea. did i miss something? Again, this may be my technical ignorance coming through, but I expected the trap/trip test suite to be in /tex-archive/web-sources and .bug/errata to be in /tex-archive/extensions as they typically impact all applications layered on top of TeX. --George From ITeX-Mgr@SHSU.edu Mon Jun 8 13:48:00 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27222; Mon, 8 Jun 92 13:47:55 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 31122; Mon, 08 Jun 1992 13:46:46 CDT Date: Mon, 08 Jun 1992 13:46:16 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095BCBA.4705F740.31122@SHSU.edu> Subject: Re: Standardized directory structure, reprise On Mon, 8 Jun 92 10:32:27 MDT, Nelson H. F. Beebe posted: > One small change that I would recommend making is the uniform use of > lower-case letters in directory names. Mixed letter case is a pain, and > causes difficulties in moving trees to non-UNIX systems. All unicase > systems that I know of accept filenames in lower-case letters, so there > should be no difficulty in remapping a UNIX tree onto those systems if care > is taken in the naming of files (letter case, length, and number of > periods). This was an issue I was meaning to take up later as I'm still not sure everyone can/will agree to a common directory structure. I agree with Nelson on this -- the casing of the directories should be consistent and I assume consistently lowercase is preferable. On a related topic, let me put on my fire retardant suit once again. I very much like the idea of containing version numbers in filenames. Unfortunately, where multiple periods are disallowed (i.e., VMS), this creates a problem, especially if we are seeking parallel within the various archives. Might it be possible (yes, I'm asking for flames) to use a single period on the significant extension and an underscore at other places where periods exist? What I propose is filename-version_revision.extension_additional, where - filename is the main filename, - followed by a hyphen, - followed by the root version number, - followed by an underscore, - followed by the revision number within the root version, - followed by the period, - followed by the major extension, - followed by an underscore (if necessary) - followed by any additional information (if necessary) This would minimize filename parsing (among other things), although I do admit that it takes away some features on U*ix machines, such as the secondary extension of .Z being an automatic, creating some additional mv commands. Comments? Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Tue Jun 9 07:50:04 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02805; Tue, 9 Jun 92 07:49:55 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 09 Jun 1992 08:13:36 CDT Via: vax.rhbnc.ac.uk; Tue, 9 Jun 1992 14:11:56 +0100 Date: Tue, 9 JUN 92 14:11:47 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: Standardised directory structure / filenames Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <21A024BA_0018E1D8.0095BD8701049580$20_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) [[GDG]] >>> I was assuming an immediate directory structure within the >>> default login directory for anonymous. For dedicated archives (as yours), >>> this is correct; for non-dedicated archives (as ours), I would seriously >>> hesitate to place a true top-level directory which is not apparent to the >>> user, so [.xxx] would be appropriate. Agreed: but then isn't the Unix equivalent equally without the leading slash? (I don't know anything about Unix, so you can safely ignore anything I say in that area!) [Zip files] >>> Sort of agree; this is simply in following with prior posts. The only >>> benefit I can see is that a zipped file is much smaller, can be achieved >>> somewhat effortlessly by the archive site, and creates less overhead for >>> transfers. More appropriately, the VMS command I was after was >>> dir/size/date/wid=(file=45)/nohead/notrail [...] >>> If you have another VMS-type suggestion for this (or a program for doing >>> so), please pass it along or tell me where to get it from. OK, I can see the point. Will think about the VMS incantation. >>> I can live with the FAQ's going into /documentation or /hints; I believe >>> the macro index (macros are what most people will be after) ought to be an >>> up-front file, though. Also, I prefer the /hints directory specification >>> as it is a little clearer to the user, IMO. [Macro index] Still think this is wrong: a `category error'. I would prefer a `How-to-find-it' file at the top level, which gives pointers to other documentation files, as well as giving a guide to the overall philosophy of the archive. [reverse-sort-by-date of Files.Txt] >>> What I implied (not so well, though). I would leave these to 30 and 7 >>> days, respectively, though to reduce the file size for transfer purposes. But they age, and by day-31 all information is lost. If you keep a Files.Txt/sorted-by-directory-and-name, and a Files.Txt/reverse-sorted-by-age, then the information is never lost, and is available in the two most convenient forms. (But I might add a third: Files.Txt/sorted-by-name, to allow rapid location of something you are sure is there, but don't know where it lives). If these all are available in ZIPped form (see withdrawal of objection, above!), then size and speed of transfer are improved, and the necessity for partial subsets is (IMHO) eliminated. [hotch-potch] >>> There is no attempt to restrict hierarchy to any number of levels; what I >>> tried to do was create a simple top- and second-level directory tree which >>> could be useful. I believe that putting the various font-types into their >>> own branch of the tree would be beneficial. For example, I would love to >>> be able to go to /fonts/pk/300 and find all xxxxxx.300pk files (or, >>> alternately, /fonts/pk/cmr and find all cmrxxx.yyypk files); similarly for >>> tfm, gf, PS, vf, etc. I must admit that this is one area where I have >>> *very* limited expertise and am looking for guidance. No, I wasn't very precise: I mant that some of the things you had at level-2 would of necessity have components which themselves appear in your model at level-2, and therefore one ends up with a graph rather than a tree. To be more precise:. /AMSfonts must surely have .pk, .gf, .tfm, etc., components, and therefore can't appear at the same level as .pk, ... [Worries about (placement of) hyphenation] >>> Why? Hyphenation patterns are highly language-dependent. I can't see >>> creating another high-level directory for something which is logically >>> within the structure I have proposed. Again, I am open to further comments >>> as this is not a clear issue. Don't know: I think a neuron (the neuron?) misfired. I completely withdraw that objection! [[BNB]] >>> i've asked the folks in charge here to comment on the proposed >>> structure and what it might imply for ams's e-math. i do know that >>> the /ams/... structure is *not* the top level, and that this node >>> is definitely not dedicated to tex, much less to a tex archive, >>> so it is quite inappropriate for us to call the root /tex-archive . It all depends what you mean by `the root', doesn't it? I think we're getting a bit confused here. If a site (other than a dedicated TeX archive) wishes to hang _a_ TeX archive off a ?file-system? (Un*x sp?), then presumably it can call the `root' of the TeX-archive branch `TeX-archive'; but the _real_ root will be ?/?, and there may be $n$ ($n \in \cal Z^+$} intervening nodes. Thus surely /.../.../.../TeX-archive is surely a valid production for any site, dedicated or not ? [[GDG]] >>> Again, this may be my technical ignorance coming through, but I expected >>> the trap/trip test suite to be in /tex-archive/web-sources and .bug/errata >>> to be in /tex-archive/extensions as they typically impact all applications >>> layered on top of TeX. Barbara is better placed then I to answer in re trip/trap (and perhaps one day someone will tell me why it is that one needs a _different_ TeX/MetaFont for trip/trap testing; what on earth is the point of validating anything other than the production code?), but I can't see .bug/errata as extensions at all! They are absolutely fundamental, and surely hang off the [.web.tex] and [.web.metafont] branches? >>> On a related topic, let me put on my fire retardant suit once again. I very >>> much like the idea of containing version numbers in filenames. >>> Unfortunately, where multiple periods are disallowed (i.e., VMS), this >>> creates a problem, especially if we are seeking parallel within the various >>> archives. Might it be possible (yes, I'm asking for flames) to use a >>> single period on the significant extension and an underscore at other >>> places where periods exist? Can't see the problem: VMS specifically _does_ allow a second period, where that period serves to delimit the version number; surely exactly what you want? (Provided you modify the proposed standard to make the final component the version number). Therefore: >>> filename-version_revision.extension_additional would become: ._. - filename is the main filename, - followed by a hyphen, - followed by the root version number, - followed by an underscore, - followed by the revision number within the root version, - followed by the period, - followed by the major extension, - followed by an underscore (if necessary) - followed by any additional information (if necessary) The reason for the is to improve visual separability of from ; thus, if one posits a maximum of five characters for a version number (say, up to 32767), one could have <1 or 2 digits>0<2 digits> representing 0. [[KB]] >>> I don't think a long filename scheme like you suggest can be >>> used, because then people can't just transfer the files to DOS >>> (or, in some cases, to a Unix with the 14-char limit on filenames). >>> I think that would be a big lose. You have to get the additional >>> information via directories, or in auxiliary indexes, or something. But what's the alternative; 8+3 cryptic names? Surely it's better to have canonical, inherently meaningful, names in the archives, and allow users of restricted files systems (of which I am one, so I am not positing anything that I'm not prepared to use myself) to map them as they will? Philip Taylor, RHBNC From ITeX-Mgr@SHSU.edu Tue Jun 9 12:30:22 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05207; Tue, 9 Jun 92 12:30:19 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from CBROWN.CLAREMONT.EDU by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 09 Jun 1992 13:28:13 CDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GL0C0XLTZ494DNLL@HMCVAX.CLAREMONT.EDU>; Tue, 9 Jun 1992 11:27 PST Date: Tue, 9 Jun 1992 11:27 PST From: Don Hosek Reply-To: TWG@SHSU.edu Subject: Re: Standardized directory structure, reprise To: TWG@SHSU.edu Message-Id: <01GL0C0XLTZ494DNLL@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"TWG@SHSU.edu" - FILES.TXT -- (ls -lR or dir/size/date/wid=(file=30) [...] - type listing) ->>> FILES.ZIP -- FILES.TXT in zip format -Not convinced we need both plain text and compressed forms files.txt as suggested would be pretty big. There's a reason that there's no such file on ymir. A compressed form has the difficulty in that there is no universal compression scheme (some come close, but close doesn't count). - INDEX.TXT -- this file - README.xxx -- README in various languages (xxx=language; .ENG=English, - .GER=German, .ITA=Italian, etc.) ->>> TEX-FAQ.TXT -- c.t.t's FAQ -- let's provide the FAQ up front and not in a ->>> lower directory ->>> TEX-FAQ.SUPP -- TeX-FAQ-Supplement; see above ->>> TEX-MACRO.INDEX -- David's macro index now in the works - -Definitely think these should be in a subsidiary directory: [.Documentation] Agreed. ->>> UPDATE30.TXT -- new files in the past 30 days ->>> UPDATE7.TXT -- new files in the past 7 days -I'd replace both of these with a reverse-sort-by-date of Files.Txt. I wouldn't. Creating that beast under VMS is not easy and as I mentioned before, the file is awfully big. -dh From ITeX-Mgr@SHSU.edu Tue Jun 9 22:48:59 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA08558; Tue, 9 Jun 92 22:48:55 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from uu.psi.com by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 09 Jun 1992 23:46:30 CDT Received: from radel.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) id AA28030; Wed, 10 Jun 92 00:33:23 -0400 Date: Tue, 9 Jun 92 23:39:17 EDT From: jon@radel.com (Jon Radel) Reply-To: TWG@SHSU.edu Subject: TeX CD-ROM Message-Id: <9206092339.0.UUL1.3#20406@radel.com> To: twg@shsu.edu, rab@allspice.Berkeley.EDU Cc: jon@radel.com And now for a completely different topic.... Since I'm sending this to two distinct addresses on the From: line, one of which is a mailing list, I thought I'd do quick introductions: rab@sprite.berkeley.edu is Bob Bruce of Walnut Creek CDROM, well known in USENET Archive circles for putting the Simtel-20 collection, etc. on CDROM. twg@shsu.edu is a working group on TeX archives put together by George Greenwade (bed_gdg@shsu.edu). I'm sending this here since this probably will get to most every TeX archive expert without too much overkill. ------ I happened to discuss in passing a CDROM of TeX material that Bob is planning to do later this year. I thought that the rest of you would both be interested in this project and, I hope, be willing to amplify and correct as needed my comments below. Bob mentioned that he was planning on getting Knuth's permission for this project. I mentioned that a) while thoughtful, I didn't think this strictly necessary and b) that last I heard, Knuth was deliberately unreachable by e-mail. ------ I also promised Bob that I'd pass along some information on the various archives involved. This is where I'd particulary welcome amplification. The big, general archives: Aston: tex.ac.aston Contact: abbottp@aston.ac.uk SHSU: niord.shsu.edu Contact: bed_gdg@shsu.edu Stuttgart: rusinfo.rus.uni-stuttgart.de Contact: texinfo1@rusvm1.rus.uni-stuttgart.de Ymir: ymir.claremont.edu Contact: dhosek@ymir.claremont.edu The above archives have collections that overlap to a great extent, but not completely. There is coordination between them, but none of them are mirrors of each other. This working group is dealing with some of these issues. Other archives: Clarkson: sun.soe.clarkson.edu Out-of-date AMS: e-math.ams.com Contact: tech-support@math.ams.com This archive is the home of AMS originated material. It should be found on the general archives. UNIX TeX: june.cs.washington.edu Contact: elisabet@max.acs.washington.edu The UNIX TeX distribution. They sell this material on tape in an attempt to raise operating funds, so far as I know. Labrea: labrea.stanford.edu The home of material that comes directly from Knuth and for dvips. Other material here should not be trusted to be the latest version (e.g., LaTeX). There are also a variety of sites that have machine specific TeX material for Macs (midway.uchicago.edu), Atari (ftp.uni-passau.de, dsrgsun.ces.cwru.edu, ifi.informatik.uni-stuttgart.de), and Amiga (ftp.informatik.rwth-aachen.de, ftp.uni-passau.de), for example. ------ The last question was about how much space the complete set of TeX material would take up. I know the question of how big the major archives were was raised on TWG; I don't recall an answer. Does it all fit on a single CDROM, is the real question, I suppose. Please note that Bob is not on the TWG mailing list, so your mailer will probably not send him a copy if you simply reply to this mail. Thank you. --Jon Radel uucp: {rutgers etc.}!uupsi!radel!jon P.O. Box 2276 domain: jon@radel.com <-best Reston, VA 22090-0276 jon%radel.com@uu.psi.com <-2nd best U.S.A. From ITeX-Mgr@SHSU.edu Wed Jun 10 12:50:45 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12805; Wed, 10 Jun 92 12:50:41 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 10 Jun 1992 13:36:34 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA24363; Wed, 10 Jun 1992 14:36:31 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA05900; Wed, 10 Jun 92 14:36:30 EDT Date: Wed, 10 Jun 92 14:36:30 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9206101836.AA05900@claude.cs.umb.edu> To: TWG@SHSU.edu In-Reply-To: CHAA006@VAX.RHBNC.AC.UK's message of Tue, 9 JUN 92 16:35:53 BST <21A0225E_00164558.0095BD9B21E4A1A0$30_1@UK.AC.RHBNC.VAX> Subject: Nelson's macro markup schema Reply-To: TWG@SHSU.edu coercing into a BibTeX style something which is clearly not a bibliographic entry Actually, I would consider such information as essentially being exactly a bibliographic entry! I also have no sympathy for mailers so brain-damaged that they cannot cope with a line that is exactly 80 characters long without wrapping it! It's the people using the mailers that need sympathy ... I've never had trouble with mailers that way, but Emacs doesn't deal with lines of exactly 80 characters well. So I appreciate it when people stick to <80, not <=80. to re-order Nelson's elements into a more coherent order For the human reader, I agree that ordering is important. Programs should be prepared to deal with anything, though. (I.e., an ordering should not be mandatory.) `version' clearly applies to the code, not the to author which it follows in Nelson's version I never thought of that before, but I like the idea of the author having different versions. I know I'm in still in alpha test ... :-) 2) to add new fields which Barabara and I feel are useful (document schema, document type, compatibility, assumed, files input; No argument with these, except possibly for the last. %%% Assumed: (e.g. NFSS: required, but not \input) %%% Files input: I think attributes for which there are no values should just be left out. %%% Description: ... %%% EndDescription: I'd prefer quotes. Shorter. David says: It might be a good idea to surround the header by , tags in some appropriately unambiguous syntax. Well, the braces delimit the header info. I think Phil's having the document type as another field, rather than the word before the braces, makes sense, though. From ITeX-Mgr@SHSU.edu Wed Jun 10 12:51:26 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12817; Wed, 10 Jun 92 12:51:20 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 10 Jun 1992 13:19:05 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA24170; Wed, 10 Jun 1992 14:18:57 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA05864; Wed, 10 Jun 92 14:18:55 EDT Date: Wed, 10 Jun 92 14:18:55 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9206101818.AA05864@claude.cs.umb.edu> To: TWG@SHSU.edu Cc: TWG@SHSU.edu In-Reply-To: "George D. Greenwade"'s message of Mon, 08 Jun 1992 09:34:52 CDT <0095BC97.28147280.29843@SHSU.edu> Subject: Standardized directory structure, reprise Reply-To: TWG@SHSU.edu A few comments on many of the messages that have been flowing past. I think this work will really help TeX users, BTW, once we achieve some kind of agreement. I believe the macro index (macros are what most people will be after) ought to be an up-front file, though. George, I'm not all sure that macros are what ``most people will be after''. I think consistency in placing all the README etc. files is desirable, at least initially. If users complain that they can't find this or that particular one, then a change could be considered at that point. But to start off, maybe a uniform structure? (Oops, I see Phil already beat me to this one.) For example, I would love to be able to go to /fonts/pk/300 and find all xxxxxx.300pk files Sorry, this won't work. Not all cmr10.300pk files are the same. (Consider write/white vs. write/black, for starters.) The mode name or some other characteristic of the MF mode has to be in there somewhere. (or, alternately, /fonts/pk/cmr and find all cmrxxx.yyypk files); I would suggest the fonts/ directory have subdirectories by typeface name: /fonts/cm, /fonts/pandora, etc. Then subdirectories tfm, pk, vf, etc. Or perhaps by vendor first: /fonts/ams/euler, fonts/free/cm, /fonts/adobe/ptm, etc. In the motherhood-and-apple-pie category, if the directory structures used for the archives could also be used for installation, wouldn't that be cool? (For fonts, macros, whatever.) Karl -- if a generally agreed to tree was available, might your site attempt to parallel it somewhat in your archives for your packages?). I don't see why not. What would be a good top-level name which might be consistent? (Phil says) But what's the alternative; 8+3 cryptic names? Yes, that's the alternative. Example of problem with having long names in the archives: LaTeX had only a few files which didn't work with 8+3: titlepage.sty, lcircle10, lcirclew10. As a result, I've seen (and received) many questions asking what to do about them. It's obviously up to authors of individual packages to deal with their own filenames. I trust we-as-archivers aren't going to start renaming the files in the distributions. Or is this what is being discussed? But we-as-archivers are obviously responsible for the directory structure and whatever files we ourselves create, and I think those should be as portable as possible. (see motherhood and apple pie, above.) Surely it's better to have canonical, inherently meaningful, names in the archives, and allow users of restricted files systems (of which I am one, so I am not positing anything that I'm not prepared to use myself) to map them as they will? Continuation of the same point -- the whole problem, IMHO, with ``mapping them as they will'' is that inevitably different people will map them differently, and so TeX documents will be unnecessarily unportable. (barbara say) it's quite necessary to, and we do, have the version numbers as part of the file names.) [for tex 0.99999 etc.] Couldn't the different versions be in different directories? that having something consistent among the archives as a top-level name is quasi-important, but I may be alone on this. No, I too think a consistent top-level name is important. That is where archives differ most widely now, in fact, in my experience. It may not be administratively feasible for the archive to always be at the root of the anonymous ftp tree, though. I see this as less important than having the top-level name be consistent, wherever it is. Again, this may be my technical ignorance coming through, but I expected the trap/trip test suite to be in /tex-archive/web-sources Huh? Maybe as a subdirectory of tex/ and mf/, or is that what you meant? But then again, if we on the DVI list ever get our act together, someday there will be tests for the various DVI standards. I guess that could be a subdir of the DVI standard directory, whatever that is. and .bug/errata to be in /tex-archive/extensions as they typically impact all applications layered on top of TeX. (barbara) it might make sense to put this collection in a sub-node of documentation rather than scatter it. I agree with Barbara, having a tex-archive/documentation/errata or even just tex-archive/errata would be preferable. Agreed: but then isn't the Unix equivalent equally without the leading slash? Anonymous ftp to Unix systems makes `/' be whatever is specified in /etc/passwd. So ftp.cs.umb.edu:pub/tex and ftp.cs.umb.edu:/pub/tex get you to exactly the same place. Either will work. Or is this not what's in question here? From ITeX-Mgr@SHSU.edu Wed Jun 10 15:17:05 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14056; Wed, 10 Jun 92 15:16:59 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 10 Jun 1992 15:35:35 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA25828; Wed, 10 Jun 1992 16:35:23 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA08546; Wed, 10 Jun 92 16:35:22 EDT Date: Wed, 10 Jun 92 16:35:22 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9206102035.AA08546@claude.cs.umb.edu> To: twg@shsu.edu Subject: summary? Reply-To: TWG@SHSU.edu George, perhaps you or someone else could post a summary of the proposed archive structure now that we've all had fun with an initial round of comments? I've quite lost track of what's where. (This is independent of the file naming question. Content vs. form and all that.) K From ITeX-Mgr@SHSU.edu Wed Jun 10 17:15:09 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14876; Wed, 10 Jun 92 17:14:59 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 7283; Wed, 10 Jun 1992 18:00:56 CDT Date: Wed, 10 Jun 1992 17:59:54 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: info-tex@SHSU.edu Cc: twg@SHSU.edu Message-Id: <0095BE70.0A4079E0.7283@SHSU.edu> Subject: ZIP/UNZIP on FILESERV/Niord A quasi-TeX-related announcement: I have been playing with ZIP as a means of creating ftp'able archives on Niord. The ZIP/UNZIP suite I am using for this is the one developed by Info-Zip, which continues to support a developers list and bug report address at UCLA. The packages below are available and are compilable on nearly every architecture (in C) I have come across, with the exception of VM/CMS (they can have interactive LISTSERV; we've got ZIP!). I am aware that the VM/CMS project is now underway (in fact, I expect that any day now --scheduled for April 1992 -- an upgrade to ZIP will be announced; I'm tired of waiting, so the versions I now have are what will be made available). The UNZIP should be stable for a little while, although it is already in further development. As noted in the announcements attached, the ZIP/UNZIP package is largely compatible with Phil Katz's PK*ZIP suite for MS-DOS. However, emulation of PK*ZIP is but one goal of the Info-Zip project -- (*truly*) portable compressed archives, across a wide number of platforms, supporting recursive directories, filenames, file dates, protection codes, etc., is the major goal. Presently, this suite's major limitation (IMHO) is still in parsing multiple periods from U*ix to other platforms -- that, too, is among the current projects; significant progress in parsing has been achieved already, though. What I am most pleased with (as an archiver) is that it consistently outperforms compressed tar files in size reduction by 10-30%. As an everyday user, it is also nice to have around to save disk quota, when needed. Anyway, the announcements are attached. If you have ftp access at all, that would be far preferred (especially for UNZIP) as there are quite a few files. If you do or don't have ftp access, this is a utility which is worth the effort to get running! --George ******************************************************************************* ZIP --- The ZIP package includes the sources of the September 21, 1991 (version 1.0) of ZIP, a (somewhat) PKZIP-compatible utility which is useful for compressing and archiving files. Its compression performance in creating compressed recursive archives including directory trees which can later be fully recreated with prior file attributes and filedates consistently surpasses standard U*ix tar.Z formats. Moreover, these compressed ZIP files may be recreated on a number of systems, allowing more modularity and portability than compressed tar files. ZIP is distributed as C source code that can be compiled on a wide range of Unix machines, VAXes running VMS, and MSDOS machines using Microsoft or Borland C++, and OS/2 machines using Microsoft C. The UNZIP package also available at this site properly unzips files created by ZIP. Both ZIP and UNZIP are supported by the Info-Zip project, which continues to improve both products. Also included are two ancillary programs: ZipSplit and Ship. ZipSplit tries to split a big zip file into the smallest number of zip files less than a specified size. This is to aid in using zip to backup to floppies. Ship is a version of a program which may be used in place of UU*CODE. It's purpose is to facilitate sending zip files through the mail. It uses a more efficient coding scheme than uuencode (four bytes per five characters instead of three bytes per four characters) and includes a crc at the end of each file to check the veracity what was received. It can split its output to a specified size and recombine it automatically at the other end, verifying the sequence. It can also mail the parts to a specified address, with subject lines identifying the parts, instead of making a bunch of files that you're just going to mail and delete anyway. To retrieve the entire package of 43 files in 45 parts, include: SENDME ZIP in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). To retrieve a specific file, such as ZIP.README, include: SENDME ZIP.README in your mail to FILESERV. For anonymous ftp retrieval of this package, it is available on Niord.SHSU.edu (192.92.115.8) in the directory [.ZIP]. The sources are available in a VMS backup saveset (ZIP-1_0.BCK), a compressed U*ix tar file (ZIP-1_0.TAR_Z; to be saved as Zip-1.0.tar.Z), and in ZIP format (ZIP-1_0.ZIP). Files in this package: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- ZIP.CONTENTS 8 contents ZIP.CRYPT_H 3 crypt.h ZIP.DIR_OS2_C 12 dir_os2.c ZIP.DIR_OS2_H 5 dir_os2.h ZIP.DOTURBOC_BAT 2 doturboc.bat ZIP.FILEIO_C_1OF2 78 fileio.c (part 1 of 2) ZIP.FILEIO_C_2OF2 15 fileio.c (part 2 of 2) ZIP.GLOBALS_C 5 globals.c ZIP.HISTORY 75 history ZIP.IMPLODE_C 19 implode.c ZIP.IMPLODE_H 10 implode.h ZIP.IM_BITS_C 11 im_bits.c ZIP.IM_CTREE_C_1OF2 77 im_ctree.c (part 1 of 2) ZIP.IM_CTREE_C_2OF2 17 im_ctree.c (part 2 of 2) ZIP.IM_LMAT_C 57 im_lmat.c ZIP.IM_LM_ASM 21 im_lm.asm ZIP.INFOZIP_WHO 10 infozip.who ZIP.MAKECRC_C 6 makecrc.c ZIP.MAKEFILE 10 makefile ZIP.MAKEFILE_BOR 8 makefile.bor ZIP.MAKEFILE_MSC 8 makefile.msc ZIP.MAKEFILE_OS2 8 makefile.os2 ZIP.MAKEFILE_PWC 8 makefile.pwc ZIP.MAKEVMS_COM 6 makevms.com ZIP.MANIFEST 4 MANIFEST ZIP.README 3 README ZIP.REVISION_H 3 revision.h ZIP.SHIP_C 79 ship.c ZIP.SHIP_DEF 1 ship.def ZIP.SHRINK_C 22 shrink.c ZIP.TAILOR_H 7 tailor.h ZIP.TEMPF_C 10 tempf.c ZIP.TEMPF_H 5 tempf.h ZIP.UTIL_C 23 util.c ZIP.ZIPERR_H 6 ziperr.h ZIP.ZIPFILE_C 43 zipfile.c ZIP.ZIPNOTE_C 21 zipnote.c ZIP.ZIPSPLIT_C 35 zipsplit.c ZIP.ZIPUP_C 22 zipup.c ZIP.ZIP_1 45 zip.1 ZIP.ZIP_C 54 zip.c ZIP.ZIP_DEF 1 zip.def ZIP.ZIP_DOC 47 zip.doc ZIP.ZIP_H 17 zip.h ZIP.ZIP_PRJ 2 zip.prj Approximate total blocks in full ZIP package = 929 ******************************************************************************* UNZIP ----- The UNZIP package includes the sources of the March 20, 1992 (version 4.2) of UNZIP, a (somewhat) PKUNZIP-compatible utility which is useful for uncompressing files compressed with ZIP. This version of UNZIP has been ported to a wide array of Unix and other mainframes, minis, and micros (including VMS, OS/2, Minix, MSDOS, Amiga, Atari ST (for the most part), and Macintosh, in addition to nearly every flavor of Unix). Although highly compatible with Phil Katz's PKZIP and PKUNZIP utilities of MSDOS fame, the objective has been one of portability and other-than-MSDOS functionality. The ZIP package also available at this site properly compresses and archives files for later handling by ZIP. Both ZIP and UNZIP are supported by the Info-Zip project, which continues to improve both products. Also included is an ancillary programs: ZipInfo. ZipInfo lists technical information about a ZIP archive, including information file access permissions, encryption status, type of compression, version and operating system of compressing program, and the like. Also, the VMS distribution includes BILF, a utility to convert files to stream-LF format (option l) or to convert files to fixed-length 512-byte binary record format (option b). Due to the wide variety of machines supported and large size of the distribution, please note which file sets to properly retrieve. To retrieve the files necessary to compile UNZIP on your operating system, include the commands: SENDME UNZIP and, if necessary SENDME "Product set" where "Product set" is replaced with the operating system/language-specific product below (i.e., UNZIP_AMIGA, UNZIP_ATARI, UNZIP_MAC, UNZIP_MSDOS_BCC, UNZIP_MSDOS_TCC, UNZIP_OS2, or UNZIP_VMS). Note that the UNZIP package alone is the base required for all applications and may be adequate for most U*ix sites. The files noted below are available for anonymous ftp retrieval as a complete set from Niord.SHSU.edu (192.92.115.8) in the directory [.UNZIP]. The files available include a VMS backup saveset (UNZIP-4_2.BCK), a U*ix compressed tar file (UNZIP-4_2.TAR_Z; to be saved as Unzip-4.2.tar.Z), and in ZIP format (UNZIP-4_2.ZIP). Product set: UNZIP (base required for all systems; should be adequate for most U*ix applications) Files in UNZIP: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- UNZIP.BUGS 7 BUGS UNZIP.CONTENTS 10 Contents UNZIP.CONTRIBS 6 CONTRIBS UNZIP.COPYING 13 COPYING UNZIP.CRAY_DIF 2 cray.dif UNZIP.EXTRACT_C 65 extract.c UNZIP.FILE_IO_C 61 file_io.c UNZIP.HISTORY_420 10 History.420 UNZIP.MAKEFILE 45 Makefile UNZIP.MAKEFILE_CR 45 Makefile.cr UNZIP.MAPNAME_C 29 mapname.c UNZIP.MATCH_C 10 match.c UNZIP.MISC_C 49 misc.c UNZIP.README 14 README UNZIP.SHIP_C 80 ship.c UNZIP.UNIMPLOD_C 20 unimplod.c UNZIP.UNREDUCE_C 11 unreduce.c UNZIP.UNSHRINK_C 10 unshrink.c UNZIP.UNZIP_1 7 unzip.1 UNZIP.UNZIP_C_1OF2 76 unzip.c (part 1 of 2) UNZIP.UNZIP_C_2OF2 21 unzip.c (part 2 of 2) UNZIP.UNZIP_H 75 unzip.h UNZIP.UNZIP_MAN 8 unzip.man UNZIP.ZIPINFO_1 13 zipinfo.1 UNZIP.ZIPINFO_C_1OF2 76 zipinfo.c (part 1 of 2) UNZIP.ZIPINFO_C_2OF2 31 zipinfo.c (part 2 of 2) UNZIP.ZIPINFO_MAN 15 zipinfo.man UNZIP.ZIPRULES 11 ZipRules UNZIP.ZIP_H 2 zip.h Approximate total blocks in full UNZIP package = 822 =============================================================================== Product set: UNZIP_AMIGA (base required for AMIGA) Files in UNZIP_AMIGA: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- UNZIP_AMIGA.CONTENTS 4 Contents UNZIP_AMIGA.DMAKEFILE 2 DMakefile UNZIP_AMIGA.DMAKEFILE_CR 2 DMakefile.cr UNZIP_AMIGA.LMKFILE 4 lmkfile UNZIP_AMIGA.LMKFILE_CR 4 lmkfile.cr UNZIP_AMIGA.PATCH_PW 3 patch.pw UNZIP_AMIGA.README_PW 3 readme.pw UNZIP_AMIGA.STAT_C 8 stat.c UNZIP_AMIGA.UTIME_C 9 utime.c Approximate total blocks in full UNZIP_AMIGA package = 39 =============================================================================== Product set: UNZIP_ATARI (base required for Atari ST) Files in UNZIP_ATARI: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- UNZIP_ATARI.ATARIST_PAT 13 AtariST.pat UNZIP_ATARI.CONTENTS 4 Contents UNZIP_ATARI.MAKEFILE_ST 3 Makefile.st UNZIP_ATARI.MAKEIT 2 makeit UNZIP_ATARI.README_SRC 7 README.src UNZIP_ATARI.TC_CFG_UUE 8 tc.uue (UUDECODE to tc.cfg) UNZIP_ATARI.UNZIP_LNK 1 unzip.lnk UNZIP_ATARI.UNZIP_PRJ 2 unzip.prj Approximate total blocks in full UNZIP_ATARI package = 40 =============================================================================== Product set: UNZIP_MAC (base required for Macintosh) Files in UNZIP_MAC: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- UNZIP_MAC.CONTENTS 3 Contents UNZIP_MAC.MACFILE_C 9 macfile.c UNZIP_MAC.MACSTAT_C 13 macstat.c UNZIP_MAC.MACSTAT_H 3 macstat.h UNZIP_MAC.UNZIP_MAKE_AZTEC_UUE 4 unzip.make.aztec.uue (Aztec C) (UUDECODE to unzip.make.aztec) UNZIP_MAC.UNZIP_MAKE_MPW_UUE 4 unzip.make.mpw.uue (Mac Programmer's Workbench) (UUDECODE to unzip.make.mpw) Approximate total blocks in full UNZIP_MAC package = 40 =============================================================================== Product set: UNZIP_MSDOS_BCC (base required for MS-DOS/Borland C/C++) Files in UNZIP_MSDOS_BCC: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- UNZIP_MSDOS_BCC.CONTENTS 6 Contents UNZIP_MSDOS_BCC.MAKEFILE 8 makefile UNZIP_MSDOS_BCC.MAKEFILE_CR 8 makefile.cr UNZIP_MSDOS_BCC.MAKESHIP_BAT_UUE 1 makeship.uue (UUDECODE to makeship.bat) UNZIP_MSDOS_BCC.TCCONFIG_TC_UUE 6 tcconfig.uue (UUDECODE to tcconfig.tc) UNZIP_MSDOS_BCC.UNZ42_BC_DIF 2 unz42_bc.dif UNZIP_MSDOS_BCC.UNZIP_CR_DSK_UUE 4 unzip_cr.due (UUDECODE to unzip_cr.dsk) UNZIP_MSDOS_BCC.UNZIP_CR_MAK 4 unzip_cr.mak UNZIP_MSDOS_BCC.UNZIP_CR_PRJ_UUE 20 unzip_cr.pue (UUDECODE to unzip_cr.prj) UNZIP_MSDOS_BCC.UNZIP_DSK_UUE 3 unzip.due (UUDECODE to unzip.dsk) UNZIP_MSDOS_BCC.UNZIP_MAK 3 unzip.mak UNZIP_MSDOS_BCC.UNZIP_PRJ_UUE 20 unzip.pue (UUDECODE to unzip.prj) UNZIP_MSDOS_BCC.ZIPINFO_DSK_UUE 3 zipinfo.due (UUDECODE to zipinfo.dsk) UNZIP_MSDOS_BCC.ZIPINFO_MAK 3 zipinfo_mak UNZIP_MSDOS_BCC.ZIPINFO_PRJ_UUE 16 zipinfo.pue (UUDECODE to zipinfo.prj) Approximate total blocks in full UNZIP_MSDOS_BCC package = 107 =============================================================================== Product set: UNZIP_MSDOS_TCC (base required for MS-DOS/Turbo C++) Files in UNZIP_MSDOS_TCC: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- UNZIP_MSDOS_TCC.CONTENTS 6 Contents UNZIP_MSDOS_TCC.MAKEFILE 8 makefile UNZIP_MSDOS_TCC.MAKEFILE_CR 8 makefile.cr UNZIP_MSDOS_TCC.MAKESHIP_BAT 1 makeship.bat UNZIP_MSDOS_TCC.TCCONFIG_TC_UUE 6 tcconfig.uue (UUDECODE to tccongif.tc) UNZIP_MSDOS_TCC.UNZIP_CR_PRJ 1 unzip_cr.prj UNZIP_MSDOS_TCC.UNZIP_PRJ 1 unzip.prj UNZIP_MSDOS_TCC.ZIPINFO_PRJ 1 zipinfo.prj Approximate total blocks in full UNZIP_MSDOS_TCC package = 32 =============================================================================== Product set: UNZIP_OS2 (base required for OS/2) Files in UNZIP_OS2: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- UNZIP_OS2.CONTENTS 4 Contents UNZIP_OS2.DOSNAME_C 9 dosname.c UNZIP_OS2.SHIP_DEF 1 ship.def UNZIP_OS2.SHIP_DIF 10 ship.dif UNZIP_OS2.UNZIP_BAD 1 unzip.bad UNZIP_OS2.UNZIP_CS 1 unzip.cs UNZIP_OS2.UNZIP_DEF 1 unzip.def UNZIP_OS2.ZIPINFO_CS 1 zipinfo.cs UNZIP_OS2.ZIPINFO_DEF 1 zipinfo.def Approximate total blocks in full UNZIP_OS2 package = 29 =============================================================================== Product set: UNZIP_VMS (base required for VAX/VMS) Files in UNZIP_VMS: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- UNZIP_VMS.BILF_C 13 BILF.C UNZIP_VMS.BILF_EXE_UUE 17 BILF.UUE (UUDECODE to BILF.EXE) UNZIP_VMS.CONTENTS 4 CONTENTS UNZIP_VMS.DESCRIP_MMS_DECRYPT 5 DESCRIP.MMS_DECRYPT UNZIP_VMS.DESCRIP_MMS_NODECRYPT 5 DESCRIP.MMS_NODECRYPT UNZIP_VMS.FATDEF_H 5 FATDEF.H UNZIP_VMS.FCHDEF_H 4 FCHDEF.H UNZIP_VMS.FJNDEF_H 2 FJNDEF.H UNZIP_VMS.MAKE_BILF_COM 1 MAKE_BILF.COM UNZIP_VMS.MAKE_UNZIP_GCC_COM_DECRYPT 4 MAKE_UNZIP_GCC.COM_DECRYPT UNZIP_VMS.MAKE_UNZIP_GCC_COM_NODECRYPT 4 MAKE_UNZIP_GCC.COM_NODECRYPT 4 UNZIP_VMS.MAKE_UNZIP_VAXC_COM_NODECRYPT 4 MAKE_UNZIP_VAXC.COM_NODECRYPT UNZIP_VMS.MAKE_UNZIP_VAXC_COM_DECRYPT 3 MAKE_UNZIP_VAXC.COM_DECRYPT UNZIP_VMS.UNZIP_RNH 8 UNZIP.RNH UNZIP_VMS.VMSMUNCH_C 25 VMSMUNCH.C UNZIP_VMS.VMSMUNCH_H 2 VMSMUNCH.H UNZIP_VMS.VMSSHARE_OPT 1 VMSSHARE.OPT UNZIP_VMS.VMS_C 43 VMS.C UNZIP_VMS.VMS_NOTES 28 VMS.NOTES Approximate total blocks in full UNZIP_VMS package = 191 =============================================================================== From ITeX-Mgr@SHSU.edu Thu Jun 11 10:13:34 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19303; Thu, 11 Jun 92 10:13:29 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from theory.lcs.mit.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 11 Jun 1992 10:42:22 CDT Received: from GYRFALCON.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA18113; Thu, 11 Jun 92 11:42:14 EDT From: dmjones@theory.lcs.mit.edu (David M. Jones) Reply-To: TWG@SHSU.edu Received: by gyrfalcon.lcs.mit.edu (5.65c/TOC-1.2C) id AA08715; Thu, 11 Jun 92 11:37:48 EDT Date: Thu, 11 Jun 92 11:37:48 EDT Message-Id: <199206111537.AA08715@gyrfalcon.lcs.mit.edu> To: TWG@SHSU.edu In-Reply-To: Karl Berry's message of Wed, 10 Jun 92 14:36:30 EDT <9206101836.AA05900@claude.cs.umb.edu> Subject: Nelson's macro markup schema Just a quick clarification: >David says: > > It might be a good idea to > surround the header by , tags in some > appropriately unambiguous syntax. > >Well, the braces delimit the header info. Yes, but I'm not sure they qualify as unambiguous. For example, when reading a BibTeX .bib file which may or may not have a Beebe-style header, how do you tell the header from a genuine BibTeX entry? I can think of a number of heuristics, but none of them inspire much confidence. That's why I think something less ambiguous should be considered. Also, <{Begin,End}Header> tags would help remove some of the restrictions on the placement of the header information. (For example, one of my friends was complaining that he would use the headers, but only if he could place them at the end of the file rather than the beginning. I think this is a bit perverse, but we should probably be prepared to consider such eccentricities.) Cheers, David. From ITeX-Mgr@SHSU.edu Thu Jun 11 10:23:42 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19354; Thu, 11 Jun 92 10:23:38 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from uu.psi.com by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 11 Jun 1992 11:09:09 CDT Received: from radel.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) id AA01865; Thu, 11 Jun 92 11:40:01 -0400 Date: Thu, 11 Jun 92 11:04:19 EDT From: jon@radel.com (Jon Radel) Reply-To: TWG@SHSU.edu Subject: Re: ZIP/UNZIP on FILESERV/Niord Message-Id: <9206111104.0.UUL1.3#20406@radel.com> To: TWG@SHSU.edu Cc: jon@radel.com In-Reply-To: Your message of Wed, 10 Jun 1992 17:59:54 CDT And here I'd just switched over to ZOO as being a closer-to-platform-independent tool on my distribution disks. Do you have any comparative comments about ZIP vs. ZOO for use in the TeX archive? The one thing I've missed so far is a unarchiver that can do something sensible with text file end-of-line markers. TUG has just switched over to using 1.4MB HD 3.5" disks in DOS format as being the format of widest utility. Text files that are platform independent (macros, etc.), I've been putting together ZOO archives of files with UNIX NL characters. This means that SUN, NeXT, etc. users can use the files directly, but DOS users have to run the files through a NL->CR/LF converter after unarchiving. A archive program that could combine these steps would be helpful. --Jon Radel uucp: {rutgers etc.}!uupsi!radel!jon P.O. Box 2276 domain: jon@radel.com <-best Reston, VA 22090-0276 jon%radel.com@uu.psi.com <-2nd best U.S.A. From ITeX-Mgr@SHSU.edu Thu Jun 11 13:44:58 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20991; Thu, 11 Jun 92 13:44:55 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from theory.lcs.mit.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 11 Jun 1992 14:16:36 CDT Received: from GYRFALCON.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA20055; Thu, 11 Jun 92 15:16:17 EDT From: dmjones@theory.lcs.mit.edu (David M. Jones) Reply-To: TWG@SHSU.edu Received: by gyrfalcon.lcs.mit.edu (5.65c/TOC-1.2C) id AA09156; Thu, 11 Jun 92 15:11:52 EDT Date: Thu, 11 Jun 92 15:11:52 EDT Message-Id: <199206111911.AA09156@gyrfalcon.lcs.mit.edu> To: TWG@SHSU.edu In-Reply-To: Jon Radel's message of Thu, 11 Jun 92 11:04:19 EDT <9206111104.0.UUL1.3#20406@radel.com> Subject: ZIP/UNZIP on FILESERV/Niord >The one thing I've missed so far is a unarchiver that can do something >sensible with text file end-of-line markers. For what is worth, the man page for zoo 2.01 has a note saying that future versions of zoo will handle this automatically. zip already has an option to do the conversion. David M. Jones "Trifles! Trifles light as air!" dmjones@theory.lcs.mit.edu -- the Hystricide From ITeX-Mgr@SHSU.edu Thu Jun 11 14:00:18 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21134; Thu, 11 Jun 92 13:59:59 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 10225; Thu, 11 Jun 1992 14:16:11 CDT Date: Thu, 11 Jun 1992 14:16:04 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095BF19.F08ABEC0.10225@SHSU.edu> Subject: Re: ZIP/UNZIP on FILESERV/Niord On Thu, 11 Jun 92 11:04:19 EDT, Jon Radel posted: > And here I'd just switched over to ZOO as being a > closer-to-platform-independent tool on my distribution disks. Do you have > any comparative comments about ZIP vs. ZOO for use in the TeX archive? I know through private communication that Rainer is also in favor of ZOO, but I don't know if he is/was aware of the newer versions and developments with ZIP. One real strong dimension I like is the on-going group effort being pursued by the Info-Zip group. It's very similar to how TeX operates w.r.t. user interest and user support (but nowhere as vast as TUG, the international UG's, etc.). Since the announcement, I can't believe the FILESERV activity -- as busy as when I put up the latest version of LaTeX -- we've already handled over 1,600 file transfers since midnight! > The one thing I've missed so far is a unarchiver that can do something > sensible with text file end-of-line markers. TUG has just switched over to > using 1.4MB HD 3.5" disks in DOS format as being the format of widest > utility. Text files that are platform independent (macros, etc.), I've been > putting together ZOO archives of files with UNIX NL characters. This means > that SUN, NeXT, etc. users can use the files directly, but DOS users have > to run the files through a NL->CR/LF converter after unarchiving. A > archive program that could combine these steps would be helpful. Jon, you're gonna love this. Here is unzip's (4.2) help screen: $ UNZIP !!! Or unzip -h -- this is my user command -- GDG ******************************************************************************* UnZip: Zipfile Extract v4.2 of 20 March 1992; (c) 1989 S.H.Smith and others Versions 3.0 and later by Info-ZIP. Bug reports ONLY to zip-bugs@cs.ucla.edu Usage: unzip [ -options[modifiers] ] file[.zip] [filespec...] -x extract files (default) -l list files (short format) -c extract files to stdout/screen (CRT) -v list files (verbose format) -f freshen existing files, create none -p extract to pipe, no messages -u update files, create if necessary -t test archive integrity -z display archive comment modifiers: -n never overwrite existing files -X restore owner/protection info -o overwrite files WITHOUT prompting -a convert text (CR LF => LF) -j junk paths (don't make directories) -U don't make names lowercase -q quiet mode (-qq => quieter) -V retain VMS version numbers Examples: (See manual for more information) unzip data1 Readme => extracts file Readme from zipfile data1.zip unzip -p foo | more => send contents of foo.zip via pipe into program more unzip -fo foo => quietly replace existing files if archive files newer unzip "-V" foo "Bar" => must quote uppercase options and filenames in VMS ******************************************************************************* Option -a does exactly what you want!! This is covered much better in unzip.man: -a convert to MS-DOS textfile format (CR LF), Mac format (CR), Unix/VMS format (LF), OR from ASCII to EBCDIC, depending on your system (only use for TEXT files!) Since this is a text-only option, the bugs file already notes as a Future Feature: - build in capability to check text/binary type and warn if -a (if version < 1.1 and not made on DOS--i.e., not early Info-ZIP versions) Also, I haven't had an awful lot of luck with ZOO, w.r.t. consistently getting good comments nor in getting stable file dates, both of which I think a distributed compressed archive ought to have. ZIP allows for a general archive comment, as well as one-line comments for each individual file. Here's the output from one of the extra utilities, ZipInfo, with its verbose output on a file I just played with: $ zipinfo -v test !!! Again, my command line -- GDG ******************************************************************************* End-of-central-directory record: ------------------------------- This zipfile constitutes the sole disk of a single-part archive; its central directory contains 4 entries. The central directory is 519 (207h) bytes long, and its offset in bytes from the beginning of the zipfile is 8313 (2079h). The zipfile comment is 537 bytes long and contains the following text: ======================== zipfile comment begins ========================== This is a test zip file of lacheck, version 1.15. I am including comments in the file, for the entire zip archive and for each file, as a tool in archiving. For archives which are somewhat dynamic, such as TeX-related archives, this allows for at least a little more information -- both to the end user, as well as to archive maintainers. Also, while I am somewhat naive in archiving, this is a tool which seems to fit the widest number of platforms, with the most functionality available, while creating the smallest files. ========================= zipfile comment ends =========================== Central directory entry #0: --------------------------- lacheck_sources.lacheck_lex host operating system (created on): VAX VMS version of encoding software: 1.0 minimum operating system compatibility required: MS-DOS or OS/2 FAT minimum software version required to extract: 1.0 compression method: imploded size of sliding dictionary (implosion): 8K number of Shannon-Fano trees (implosion): 3 file security status: not encrypted extended local header: no file last modified on: 7 Jun 1992 15:58:32 32-bit CRC value (hex): f85d446d compressed size: 5492 bytes uncompressed size: 18173 bytes length of filename: 27 characters length of extra field: 0 bytes length of file comment: 56 characters disk number on which file begins: disk 0 apparent file type: text VMS file attributes (100755 octal): (RWED,RWED,RE,RE) MS-DOS file attributes (00 hex): none offset of local header from start of archive: 0 (0h) bytes ------------------------- file comment begins ---------------------------- This is the lex file for lacheck, v. 1.15 -- lacheck.lex -------------------------- file comment ends ----------------------------- Central directory entry #1: --------------------------- lacheck_sources.lacheck_man host operating system (created on): VAX VMS version of encoding software: 1.0 minimum operating system compatibility required: MS-DOS or OS/2 FAT minimum software version required to extract: 1.0 compression method: imploded size of sliding dictionary (implosion): 4K number of Shannon-Fano trees (implosion): 3 file security status: not encrypted extended local header: no file last modified on: 7 Jun 1992 15:57:44 32-bit CRC value (hex): db4ad8b1 compressed size: 1750 bytes uncompressed size: 3348 bytes length of filename: 27 characters length of extra field: 0 bytes length of file comment: 66 characters disk number on which file begins: disk 0 apparent file type: text VMS file attributes (100755 octal): (RWED,RWED,RE,RE) MS-DOS file attributes (00 hex): none offset of local header from start of archive: 5549 (15ADh) bytes ------------------------- file comment begins ---------------------------- This is the Unix man page file for lacheck, v. 1.15 -- lacheck.man -------------------------- file comment ends ----------------------------- Central directory entry #2: --------------------------- lacheck_sources.makefile host operating system (created on): VAX VMS version of encoding software: 1.0 minimum operating system compatibility required: MS-DOS or OS/2 FAT minimum software version required to extract: 1.0 compression method: imploded size of sliding dictionary (implosion): 4K number of Shannon-Fano trees (implosion): 3 file security status: not encrypted extended local header: no file last modified on: 7 Jun 1992 15:59:06 32-bit CRC value (hex): c9c9bcdb compressed size: 630 bytes uncompressed size: 1039 bytes length of filename: 24 characters length of extra field: 0 bytes length of file comment: 56 characters disk number on which file begins: disk 0 apparent file type: text VMS file attributes (100755 octal): (RWED,RWED,RE,RE) MS-DOS file attributes (00 hex): none offset of local header from start of archive: 7356 (1CBCh) bytes ------------------------- file comment begins ---------------------------- This is the "Make" file for lacheck, v. 1.15 -- Makefile -------------------------- file comment ends ----------------------------- Central directory entry #3: --------------------------- lacheck_sources.rrev host operating system (created on): VAX VMS version of encoding software: 1.0 minimum operating system compatibility required: MS-DOS or OS/2 FAT minimum software version required to extract: 1.0 compression method: shrunk file security status: not encrypted extended local header: no file last modified on: 7 Jun 1992 15:59:30 32-bit CRC value (hex): affb9ee7 compressed size: 223 bytes uncompressed size: 254 bytes length of filename: 20 characters length of extra field: 0 bytes length of file comment: 59 characters disk number on which file begins: disk 0 apparent file type: text VMS file attributes (100755 octal): (RWED,RWED,RE,RE) MS-DOS file attributes (00 hex): none offset of local header from start of archive: 8040 (1F68h) bytes ------------------------- file comment begins ---------------------------- This is the rrev file for lacheck, v. 1.15, -- lacheck.rrev -------------------------- file comment ends ----------------------------- ******************************************************************************* Or, $ UNZIP -v test.zip !!! Yet again, my command line -- GDG ******************************************************************************* [test.zip] comment: This is a test zip file of lacheck, version 1.15. I am including comments in the file, for the entire zip archive and for each file, as a tool in archiving. For archives which are somewhat dynamic, such as TeX-related archives, this allows for at least a little more information -- both to the end user, as well as to archive maintainers. Also, while I am somewhat naive in archiving, this is a tool which seems to fit the widest number of platforms, with the most functionality available, while creating the smallest files. Length Method Size Ratio Date Time CRC-32 Name ("^" ==> case ------ ------ ---- ----- ---- ---- ------ ---- conversion) 18173 Implode 5492 70% 06-07-92 15:58 f85d446d ^lacheck_sources.lacheck_lex This is the lex file for lacheck, v. 1.15 -- lacheck.lex 3348 Implode 1750 48% 06-07-92 15:57 db4ad8b1 ^lacheck_sources.lacheck_man This is the Unix man page file for lacheck, v. 1.15 -- lacheck.man 1039 Implode 630 39% 06-07-92 15:59 c9c9bcdb ^lacheck_sources.makefile This is the "Make" file for lacheck, v. 1.15 -- Makefile 254 Shrunk 223 12% 06-07-92 15:59 affb9ee7 ^lacheck_sources.rrev This is the rrev file for lacheck, v. 1.15, -- lacheck.rrev ------ ------ --- ------- 22814 8095 65% 4 ******************************************************************************* Or, finally $ UNZIP -l test.zip !!! my final command line -- GDG ******************************************************************************* [test.zip] comment: This is a test zip file of lacheck, version 1.15. I am including comments in the file, for the entire zip archive and for each file, as a tool in archiving. For archives which are somewhat dynamic, such as TeX-related archives, this allows for at least a little more information -- both to the end user, as well as to archive maintainers. Also, while I am somewhat naive in archiving, this is a tool which seems to fit the widest number of platforms, with the most functionality available, while creating the smallest files. Length Date Time Name ("^" ==> case ------ ---- ---- ---- conversion) 18173 06-07-92 15:58 ^lacheck_sources.lacheck_lex 3348 06-07-92 15:57 ^lacheck_sources.lacheck_man 1039 06-07-92 15:59 ^lacheck_sources.makefile 254 06-07-92 15:59 ^lacheck_sources.rrev ------ ------- 22814 4 ******************************************************************************* I have played with this on all systems I have access to here -- VMS, HP-UX, Sun 3, Macintosh, and MS-DOS -- and the actions, output, archiving and unarchiving are all consistent. Better still, while the announcement indicated that PK*ZIP compatability was not a critical issue, I haven't run across a file I ZIPped which PKUNZIP couldn't handle, nor one I PKZIPped which UNZIP couldn't handle (I am sure there are some dimensions where they will fail, but my guess is that they are among the more esoteric options, or in widely differing versions -- I haven't found them). Sorry for the long post extolling the virtues of these utilities. I do think we ought to consider this as an option, though. One aspect you might also want to consider is making available pre-compiled MS-DOS versions -- that way, we have a little better handle on what functionality your distribution users will have. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Thu Jun 11 17:40:53 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22853; Thu, 11 Jun 92 17:40:47 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 11567; Thu, 11 Jun 1992 18:39:25 CDT Date: Thu, 11 Jun 1992 18:39:01 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: twg@SHSU.edu Message-Id: <0095BF3E.ABA6CA40.11567@SHSU.edu> Subject: Question regarding other possible sites Presently, I am assuming that Aston, Stuttgart, and SHSU (and I hope Ymir) are considering working together in establishing whatever mirror/sharing arrangements (I'm going to begin referring to these as comprehensive archive sites, as opposed to specialized archive sites) I've worked out a transportation model which might be useful w.r.t. connections -- more on this next week. Two topics: First, who have I overlooked among current or prospective coordinated comprehensive sites? I would really like to add one more North American site to this list and feel sure that I have slighted someone unintentionally -- I'm just ignorant! Second, does anyone know of one or more sites in (a) Japan or elsewhere in Asian, (b) Australia or New Zealand, (c) Southern Europe or Middle East, and (d) South America which might be interested in serving as a coordinated comprehensive archive? If so, please contact me so I can begin a semi-sales pitch on this. If you have a contact there (even an e-mail address from way back when!), it would help (unless you want to run interference on this yourself). Tomorrow's gonna be quick for me -- I give an exam then go to Dallas to give a presentation. I will provide some details on the transportation scheme I have devised early next week. Also, I have to put the finishing touches on the requested modified directory tree structure, w.r.t. the discussion so far, at least as I have read it. --George From ITeX-Mgr@SHSU.edu Thu Jun 11 20:16:01 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23511; Thu, 11 Jun 92 20:15:58 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from uu.psi.com by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 11 Jun 1992 21:14:29 CDT Received: from radel.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) id AA19174; Thu, 11 Jun 92 21:59:26 -0400 Date: Thu, 11 Jun 92 21:42:02 EDT From: jon@radel.com (Jon Radel) Reply-To: TWG@SHSU.edu Subject: Re: ZIP/UNZIP on FILESERV/Niord Message-Id: <9206112142.0.UUL1.3#20406@radel.com> To: TWG@SHSU.edu Cc: jon@radel.com In-Reply-To: Your message of Thu, 11 Jun 1992 14:16:04 CDT Thanks to all for the info re: ZIP supporting text file end-of-line translation. I'm going to getting a copy of the ZIP programs and giving my decision to use ZOO some reconsideration. Luckily I haven't put immense amounts of work into using ZOO yet. I will concur on George's comments about ZOO not being very stable on file dates, etc. I've gotten some weird behavior out of the UNIX version. --Jon Radel uucp: {rutgers etc.}!uupsi!radel!jon P.O. Box 2276 domain: jon@radel.com <-best Reston, VA 22090-0276 jon%radel.com@uu.psi.com <-2nd best U.S.A. From ITeX-Mgr@SHSU.edu Fri Jun 12 03:56:49 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25489; Fri, 12 Jun 92 03:56:47 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 12 Jun 1992 04:55:02 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA24614 (5.65c/IDA-1.4.4 for ); Fri, 12 Jun 1992 11:41:01 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA01705; Fri, 12 Jun 92 11:40:59 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9206120940.AA01705@hp5.iti.informatik.th-darmstadt.de> Subject: Re: ZIP/UNZIP on FILESERV/Niord To: TWG@SHSU.edu Date: Fri, 12 Jun 92 11:40:51 MESZ In-Reply-To: <0095BF19.F08ABEC0.10225@SHSU.edu>; from "George D. Greenwade" at Jun 11, 92 2:16 pm X-Mailer: ELM [version 2.3 PL11] George wrote: > > > I have played with this on all systems I have access to here -- VMS, HP-UX, > Sun 3, Macintosh, and MS-DOS -- and the actions, output, archiving and > unarchiving are all consistent. Better still, while the announcement > indicated that PK*ZIP compatability was not a critical issue, I haven't run > across a file I ZIPped which PKUNZIP couldn't handle, nor one I PKZIPped > which UNZIP couldn't handle (I am sure there are some dimensions where they > will fail, but my guess is that they are among the more esoteric options, > or in widely differing versions -- I haven't found them). In my experience, unzip is not compatible to older versions of PK*ZIP. When users here had problems, I announced them to use the actual version (1.10) of PK*ZIP, and everything went wrong. (But I also had problems when I received older ZIP archives and tried to unpack them with unzip.) As a summary: As long as we use actual versions in our archives there should not be any problems. -- Joachim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de Computer Science Department Technical University of Darmstadt, Germany ``How do we persuade new users that spreading fonts across the page like peanut butter across hot toast is not necessarily the route to typographic excellence? -- Peter Flynn From ITeX-Mgr@SHSU.edu Fri Jun 12 04:11:15 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25536; Fri, 12 Jun 92 04:11:13 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 12 Jun 1992 05:07:39 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA15493; Fri, 12 Jun 1992 06:07:39 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA17128; Fri, 12 Jun 92 06:07:38 EDT Date: Fri, 12 Jun 92 06:07:38 EDT From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <9206121007.AA17128@claude.cs.umb.edu> To: TWG@SHSU.edu Subject: Re: Nelson's macro markup schema In most cases, there would be `%%' or ``%%%' before the { the left brace that starts the header info. But I agree, it isn't foolproof. How about just %%% headerinfo{...} Or one could even use the same syntax as for attribute values (at least with the original scheme) %%% headerinfo = { ... } %%% headerinfo = " ... " etc From ITeX-Mgr@SHSU.edu Fri Jun 12 04:58:23 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25844; Fri, 12 Jun 92 04:58:19 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 12 Jun 1992 05:57:30 CDT Via: vax.rhbnc.ac.uk; Fri, 12 Jun 1992 11:57:06 +0100 Date: Fri, 12 JUN 92 11:52:08 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: RE: Question regarding other possible sites Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <20E00803_0007CF90.0095BFCEFE1142C0$9_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) >>> Second, does anyone know of one or more sites in (a) Japan or elsewhere in >>> Asian, (b) Australia or New Zealand, (c) Southern Europe or Middle East, >>> and (d) South America which might be interested in serving as a coordinated >>> comprehensive archive? If so, please contact me so I can begin a >>> semi-sales pitch on this. If you have a contact there (even an e-mail >>> address from way back when!), it would help (unless you want to run >>> interference on this yourself). For Japan/Nihon, you might consider Akiu.Gw.Tohoku.Ac.Jp: they were very quick off the mark in getting the latest betatest versios of emTeX ... ** Phil. From ITeX-Mgr@SHSU.edu Fri Jun 12 05:34:59 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25972; Fri, 12 Jun 92 05:34:57 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 12 Jun 1992 06:33:58 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA28816 (5.65c/IDA-1.4.4 for ); Fri, 12 Jun 1992 13:33:35 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA02354; Fri, 12 Jun 92 13:33:34 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9206121133.AA02354@hp5.iti.informatik.th-darmstadt.de> Subject: Re: ZIP/UNZIP on FILESERV/Niord To: TWG@SHSU.edu Date: Fri, 12 Jun 92 13:33:32 MESZ In-Reply-To: <9206120940.AA01705@hp5.iti.informatik.th-darmstadt.de>; from "Joachim Schrod" at Jun 12, 92 11:40 am X-Mailer: ELM [version 2.3 PL11] I wrote: > > When users here had problems, I announced them to use the actual > version (1.10) of PK*ZIP, and everything went wrong. [[ Think that the three hours sleep tonight were not enough ;-) ]] This should read: When users here had problems, I advised them to use the actual version and everything was all right. On another topic: I was out for a week and now find the large mail volume of TWG. George, may you please post a summary of the proposed directory structure? I think I should better comment on the revised version than on the original one with all the annotations. -- Joachim From ITeX-Mgr@SHSU.edu Fri Jun 12 12:16:51 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28857; Fri, 12 Jun 92 12:16:44 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 12 Jun 1992 13:12:00 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA16138 (5.65c/IDA-1.4.4 for ); Fri, 12 Jun 1992 20:11:01 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA02890; Fri, 12 Jun 92 20:10:58 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9206121810.AA02890@hp5.iti.informatik.th-darmstadt.de> Subject: Re: Nelson's macro markup schema To: TWG@SHSU.edu Date: Fri, 12 Jun 92 20:10:57 MESZ In-Reply-To: <199206091757.AA07797@gyrfalcon.lcs.mit.edu>; from "David M. Jones" at Jun 9, 92 1:57 pm X-Mailer: ELM [version 2.3 PL11] I want to join Phil in his proposal and want to change it a bit. First my reasons: -- RFC822 like collections of key-value pairs are well known, in a much wider community than BibTeX is known. -- They are **MUCH** easier to parse than BibTeX-like files. (I just wrote a BibTeX parser in lex and yacc. It took me almost a complete day to write this damn beast. Alone the error recovery is a pain in the a**. And I'm still not sure if the parser groks some BibTeX entry possibilites right. Eg, everybody knows the @comment entry? It's now very clear (at least for me) why nowhere is a grammar for BibTeX entries -- this grammar would show how irregular this whole language is. An RFC822 parser is written in under an hour (incl. test and doc...).) -- It was mentioned by some people in this round (eg, barbara) that the macro index info *is* BibTeX. You should note that this is not true. BibTeX would choke on nearly all headers I've seen. In addition, it is -- to my knowledge -- not possible, to write a BibTeX style which outputs an appropriate representation. The documentation field within the `BibTeX entry' usually contains paragraphs -- but BibTeX will munge all paragraphs into one large. (Ie, empty lines are discarded.) Perhaps I should note that I've done a fair amount of programming in the .bst language. I guess, this is not an appropriate forum for a BibTeX discussion. If anybody cares why the BibTeX implementation (and the unnamed bst programming language) is IMNSHO rotten to the heart and should be replaced completely, he or she can contact me... -- The `RFC822 method' is also appropriate to comment BibTeX files, but the `BibTeX method' isn't. Yes, I noted that the at character is optional -- but I think that many authors would fail here. The would insert it and would not be aware that one *cannot* escape an at character in BibTeX. I think that the order of the entries, as Phil has pointed out them, should not be required, but recommended. (In Standard-Speak: neither `shall' nor `may', but `should'.) Programs interpreting them shall not depend on any particular order, intended for better human readability. In the proposal there should be remarks which fields are mandatory and which are optional. As a first guess I would say that Document schema: Name: Timestamp: Document type: Author: : are mandatory. would be either the Address or the E-Mail field. Don't add phone or FAX to the required fields. Eg, I would never write my phone number in a macro file. (TeX is a recreational activity for me, and I have already too much phone calls concerning TeX... ;-) Add a few other fields: Note: Annotations which do not fit in the description block. I take the latter as a semantic description. The Note field would be used for organizational hints. Eg, to note that this file is obsolete. Part Of: May also be named `Package'. Notes that this file is part of a collection of larger files and make only sense together with all files of this package. This field must be distinguished from the `Compatibility' field suggested by barbara and Phil. It tells that this file belongs to the core of a package. Eg: I have written MAKEPROG, a package for the documentation of programs. Some macros are included, for usage with Plain TeX, LaTeX, (ex)or webmac. The `Part Of' field for these files would name MAKEPROG, the `Compatibility' would name one of these macro packages. References: May also be named `See also'. Meaning should be obvious. Phil, was the specification in the `Description' field meant as a specific capability of this field or was it a general method of specifying long text. (Besides the continuation lines a la RFC822.) What about: Field-Name: ... arbitrary text which does not have a line equal to ?! -- Or even ... ;-) Isn't that better? (Ie: the end tag does not depend on the field name. Better to write and better to parse.) Well, this has got a longer message. Hope that it's read by some and that the comments keep coming in. -- Joachim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de Computer Science Department Technical University of Darmstadt, Germany ``How do we persuade new users that spreading fonts across the page like peanut butter across hot toast is not necessarily the route to typographic excellence? -- Peter Flynn From ITeX-Mgr@SHSU.edu Fri Jun 12 12:41:45 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29024; Fri, 12 Jun 92 12:41:40 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 12 Jun 1992 13:39:39 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA39040 (5.65c/IDA-1.4.4 for ); Fri, 12 Jun 1992 20:39:04 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA02932; Fri, 12 Jun 92 20:39:02 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9206121839.AA02932@hp5.iti.informatik.th-darmstadt.de> Subject: Re: Standardized directory structure, reprise To: TWG@SHSU.edu Date: Fri, 12 Jun 92 20:39:01 MESZ In-Reply-To: <0095BC15.C108C400.27039@SHSU.edu>; from "George D. Greenwade" at Jun 7, 92 6:08 pm X-Mailer: ELM [version 2.3 PL11] Do we agree that this discussion is about the directory structure of TeX archives and **NOT** of TeX installations?! I do not think that it is appropriate for the latter. A proposal for an installation's directory structure may be fetched >From ftp.th-darmstadt.de, directory pub/tex/documentation, file texdir.txt. This file is in German and is the summary of a discussion at a DANTE meeting. It will be distributed Real Soon Now in English for further comments of more people. You should note the people who discussed it did not agree on the font directory structure, but the rest was commonly accepted. I would like to throw in another thought which I discussed with several people in the last half year: Here in Darmstadt we do some TeX development and have sometimes problems locating the latest revisions of programs. Wouldn't it be of interest to have a developper's server? Some place where actual versions of the `core TeX' programs/packages, together with the information about the current maintainer, the reference sites, etc., is collected (and updated automatically). Such a server would not carry all-and-everything like the large archive sites (stuttgart, aston, ymir, or shsu comes to mind). The advantages are -- developpers would be able to place new versions on their home machine, and don't have to take care of the transport to the developper's server. (If they don't have a home machine, they can place it directly on the server.) -- the large archive sites don't need to look on each small machine when something new pops up. They can check the developper's server (maybe automatically with some mirror software). Something like +------------------+ +--------------+ +-----------+ | small site where |--> | developper's | | major TeX | | a TeX developper |--->| server |--->| archive | | works |--> | | | | +------------------+ +--------------+ +-----------+ The disadvantage is -- one must decide what the `core' of TeX is. I can imagine a model a la X11. One has a required part, a recommended part, a contributed part, and the rest (from fishing in the mud ;-). Btw, hardware resources would be no problem. I'm able to install such a server here in Darmstadt where I have still 1 GB free disk space at our ftp server... And, as some of you know, I'm working extensively with -- and on -- mirror software, so automatical updates would be no problem. The list of reference sites exists also -- I maintain it for myself. :-) -- Joachim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de Computer Science Department Technical University of Darmstadt, Germany ``How do we persuade new users that spreading fonts across the page like peanut butter across hot toast is not necessarily the route to typographic excellence? -- Peter Flynn From ITeX-Mgr@SHSU.edu Fri Jun 12 13:32:53 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29311; Fri, 12 Jun 92 13:32:47 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 12 Jun 1992 14:02:40 CDT Via: vax.rhbnc.ac.uk; Fri, 12 Jun 1992 20:01:27 +0100 Date: Fri, 12 JUN 92 19:50:45 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: Re: Nelson's macro markup schema Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <20E0067F_00077AC8.0095C011DA81BB80$1_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) Joachim --- [I'm glad to see that I'm not the only one to prefer RFC-822 to Bibliotheque!] >>> Phil, was the specification in the `Description' field meant as >>> a specific capability of this field or was it a general method of >>> specifying long text. (Besides the continuation lines a la RFC822.) It was the second: a general way of indicating that the text which followed would not _necessarily_ be indented (a la RFC-822), but would only terminate when a matching End: "<"block">" was found at the logical beginning of a line. I thought it necessary because stripping the leading per-cents and lwsp made it rather difficult to decide whether a record was truly indented or not. >>> What about: >>> Field-Name: >>> ... arbitrary text which does not have a line equal to >>> >>> ?! -- Or even ... ;-) Isn't that better? (Ie: the end tag >>> does not depend on the field name. Better to write and better to >>> parse.) Well, it seems non-orthogonal, which to me is therefore counter-intuitive, but you probably write more parsers than I, so I am happy to take your professional advice. How about a totally generalisable solution: Form simple, line-oriented, entities, the tag is : For any entity that is in the form of a , let there exist a variant form Begin: End: ** Phil. From ITeX-Mgr@SHSU.edu Sat Jun 13 05:08:11 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03798; Sat, 13 Jun 92 05:08:07 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Sat, 13 Jun 1992 06:07:06 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA26259; Sat, 13 Jun 1992 07:07:03 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA17792; Sat, 13 Jun 92 07:07:02 EDT Date: Sat, 13 Jun 92 07:07:02 EDT From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <9206131107.AA17792@claude.cs.umb.edu> To: TWG@SHSU.edu Subject: Re: Standardized directory structure, reprise Sure, this discussion is about the directory structure of TeX archives, not TeX installations. But if the two could be the same, in part or in whole (or even ``in concept'') this would be a good thing. K From ITeX-Mgr@SHSU.edu Sat Jun 13 22:32:44 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06297; Sat, 13 Jun 92 22:32:42 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from FRIGGA.CLAREMONT.EDU by Niord.SHSU.edu (MX V3.1B) with SMTP; Sat, 13 Jun 1992 23:31:45 CDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GL6I9OENDC9ULM7N@HMCVAX.CLAREMONT.EDU>; Sat, 13 Jun 1992 21:31 PDT Date: Sat, 13 Jun 1992 21:31 PDT From: Don Hosek Reply-To: TWG@SHSU.edu Subject: Re: TeX CD-ROM To: TWG@SHSU.edu Message-Id: <01GL6I9OENDC9ULM7N@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"TWG@SHSU.edu" The complete ymir archive would easily fit on a CD ROM (it's currently around 150M or so). The big problem with a CD ROM is that my understanding of the technology is that it's difficult (impossible?) to have a universal CD ROM readable on DOS/Mac/Unix/VMS which means that one's market is made somewhat less reachable. Not to mention the fluid nature of the contents. But as long as its not my money being invested... -dh From ITeX-Mgr@SHSU.edu Mon Jun 15 05:19:11 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11709; Mon, 15 Jun 92 05:19:09 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Mon, 15 Jun 1992 06:15:29 CDT Via: vax.rhbnc.ac.uk; Mon, 15 Jun 1992 12:13:54 +0100 Date: Mon, 15 JUN 92 12:13:47 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: Re: TeX CD-ROM Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <21E010D2_001E14F8.0095C22D83A60460$19_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) Don --- >>> The big problem with a CD ROM is that my understanding of the >>> technology is that it's difficult (impossible?) to have a >>> universal CD ROM readable on DOS/Mac/Unix/VMS ... I understood that this was not the case --- that there existed an ISO standard which could be read by all of these systems. I'll see if I can track down a reference ... ** Phil. From ITeX-Mgr@SHSU.edu Mon Jun 15 12:58:15 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14684; Mon, 15 Jun 92 12:58:08 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 22307; Mon, 15 Jun 1992 13:57:00 CDT Date: Mon, 15 Jun 1992 13:56:56 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: twg@SHSU.edu Message-Id: <0095C23B.ED17B2A0.22307@SHSU.edu> Subject: Directory structure as it now stands On Sun, 07 Jun 1992 18:08:34 CDT, I posted the preliminary proposed directory structure. Since then, there has been some quite useful discussion (thanks!!!), as well as a request for a posting of where we now stand. I believe that this is correct, as of the moment. Please post any changes, omissions, or oversights so these can be properly included. Files and directories denoted with an "*" are changes from the original proposal. Also, in all cases, note that TeX-archive in the original has been modified to lowercase-only tex-archive. The tex-archive tree is not assumed to be the absolute top-level directory, although it is assumed that it will appear on the top-level directory of trees, unless it resides in the immediate second level general use access directory, such as /pub/tex-archive. For all purposes of this outline, this is the intent in the use of the /tex-archive nomenclature. /tex-archive FILES.TXT -- (ls -lR or, for VMS, something similar to dir/size/date/wid=(file=42)/nohead/notrail [...tex-archive...]) Note: This file is sorted alphabethically, by directory. FILES.ZIP -- FILES.TXT in zip format * FILEDATE.TXT -- like FILES.TXT, but in reverse-date order, with newest going on top. For VMS, I will write some TPU code to make this work. * FILEDATE.ZIP -- FILEDATE.TXT in zip format UPDATE30.TXT -- new files in the past 30 days, alphabetically, by directory * UPDATE30.BY-BATE -- reverse-date ordered UPDATE30.TXT UPDATE7.TXT -- new files in the past 7 days, alphabetically, by directory * UPDATE7.BY-BATE -- reverse-date ordered UPDATE7.TXT INDEX.TXT -- this file README.xxx -- README in various languages (xxx=language; .ENG=English, .GER=German, .ITA=Italian, etc.) /tex-archive/archive-tools Archiving tools, to include ZIP, UNZIP, FILEHDR, UU*CODE, VV*CODE (when available), others; each in its own subdir. * /tex-archive/bibliography * New directory structure, originally in /extensions. This is devoted to * BibTeX, as well as related tools, styles, macros, etc. Additionally, any * other bibliographic package would be included here * /bibtex * /base (minimally required; primarily original distrtibution) * /bst * /supported * /unsupported * /tools /tex-archive/conversion Converters for xxx2TeX, such as RTF2TeX, word2TeX, etc.; each in its own subdir. /tex-archive/drivers {\em Original} sources for xxx2DVI-type drivers; each in its own subdir. Operating system-specific ports appear in /tex-archive/systems/"OS"/drivers (where "OS" is the specific operating system. /tex-archive/extensions /AMS /AMSTeX /AMSLaTeX /REVTEX * /tex-macro (moved to extensions out of its own second-level directory) * /base (I don't think there really are any true "base" macros -- i.e., * minimally required to use TeX -- if so, they go here; if not, this * is deleted) * /supported * /unsupported /eplain /lamstex * /latex-style (moved to extensions out of its own second-level directory) * /base (minimally required; Lamport/Mittelbach/Schoepf files) * /supported * /unsupported /text1 others; each in its own subdir. This is for all extensions layered on top of TeX. /tex-archive/fonts /AMSfonts /utilities (font utilities; each in its own subdir.) ** I believe that this is so far out of my league, that any further ** proposal on this one has to come from someone else. I believe that ** specific distributed packages, such as AMSfonts belongs in its own subdir., ** as do all other distributed packages. I also believe that font utilities, ** such as the SF2PK-types of packages belong in their own directories within ** a utilities subdir. ** Precisely how to design this and what to include where is open entirely ** to your comment and judgment. /tex-archive/graphics /eepic /epic /pictex /xypic Graphic tools/interfaces for TeX; each in its own subdir. * /tex-archive/help (previously included as /tex-archive/hints; this name * allows for a little extra coverage; I personally am opposed to * /documentation as it appears to be "documentation"-types of materials, * as opposed to helpful files) ASCII files on a variety of topics, including - using the archives - submitting to the archives - standard headers; point to /tex-archive/archive-tools/filehdr - mirroring network; use closest site - comp.text.tex and various mailing lists available * tex-faq.txt -- c.t.t's FAQ * tex-faq.supp -- TeX-FAQ-Supplement * tex-macro.index -- David's macro index now in the works * texdir.txt -- from ftp.th.darmstadt.de -- proposed/suggested directory * structure (hopefully in English as well as the present German; * possibly we need the same extensions as the README.xxx at the top * level?) * /errata -- the errata files * /bug -- the bug files The first three files above were moved from the top-level directory. The fourth provides guidance in local installation and directory structures. The two new subdirectories are for obvious reasons, previously discussed; after reading the other posts, it was my understanding that a /bug and an /errata directory -- one each, as I read bnb's posts -- would be satisfactory in this directory area. /tex-archive/indexing Indexing tools; each in its own subdir. * /tex-archive/books (renamed from /tex-archive/Knuth-books to allow for * wider inclusion of macros for printed materials) /metafontbook (files used with) /texbook (files used with) * /tbefiles (files used with TeX by Example) * others; each in its own subdir. /tex-archive/languages babel, japanese TeX, arabtex, hyphenation, etc.; all language-specific aspects; each in its own subdir. /tex-archive/periodicals /texhax each year; each in its own subdir. /texmag each volume; each in its own subdir. /textugnews or /ttn each volume; each in its own subdir. /uktex each year; each in its own subdir. /tugboat contents files /ctt (compressed comp.text.tex archives??) each year; each in its own subdir. /tex-archive/systems /amiga /atari /mac /msdos /vax-vms /unix other systems; each in its own subdir. This will expand to all system-specific files, following when possible the design of the top-level /tex-archive directory, such as TeX-archive/drivers above /tex-archive/tutorials /essential /gentle other tutorial-type documentation; seek course outlines as well for a good overview of teaching/learning TeX and its ancillaries /tex-archive/users-groups /DANTE /TUG users groups; each in its own subdir. * /developers -- for source code from product developers, per Joachim * Schrod's post of Friday, June 12. While this is not a formal user * group, the work done needs to be available. More on this will follow. /tex-archive/web-sources /cweb /mf /spiderweb /tex Web sources for various aspects. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Mon Jun 15 16:29:25 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16316; Mon, 15 Jun 92 16:29:18 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 22755; Mon, 15 Jun 1992 17:28:08 CDT Date: Mon, 15 Jun 1992 17:28:05 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095C259.6C7D0BE0.22755@SHSU.edu> Subject: Systematic aspects I hope we can agree to Again, this is a post which has been on the back burner which I would like to now bring forward. I'm not claiming to have the best calculations on what follows, but I believe it's within presentation at the base level for discussion. This is hastily written, so I can clear up problems on request. The scheme for mirroring I have had in my mind for some time now is to have two types of archives. First, the "biggies", which I have referred to as "coordinated comprehensive TeX archive sites" or "CTAs"; second, the ones which make ftp'ing worthwhile, which I have referred to as "specialized TeX archive sites" or "STAs". The CTAs are envisioned to be few in number (the specific number I have been working with is 8), which are connected via the mirroring mechanism. The STAs are where new files can be added, as well as machines which serve a specific or a set of specific purposes (such as ftp.cs.umb.edu, e-math.ams.com, and any host of others). This is why I asked for specific places for other mirrors -- I would like to see Stuttgart and Aston serve northern Europe, ymir and SHSU North America (there's 4), in addition to a site in Australia for that continent and the South Pacific, a site in Japan for Asia, a site to serve southern Europe and the Middle East, and a site to serve South America (there's 4 more). Conceptually: each of the 8 CTAs correspond to one another via a round-robin-type distribution. Each of these machines is responsible for "talking" to only two other CTAs. As a file enters one CTA, it is passed along to the 2 it is linked to. Each of these 2 pass it along to one other (they only pass to one as they are linked back to the originating site). In all, a new file can be passed along to all 8 CTAs in three iterations once the tree begins. If we assume that a machine talks to a close neighbor (basically defined as another host is a somewhat close time zone) and far neighbor (basically defined as anotehr host which is approximately 12 hours different) and that each host runs updates at approximately the same local time (everyone at their 0200, for example), then there are a total of 4 CTA-CTA maintenance connections per site per day (the incoming East->West and outgoing West->East for each partner). With a web between hosts, it is conceivable (and here is where my transportation theory math calculations may be suspect) that any new file placed on any one CTA will be fully propogated to all CTAs within 36 hours (which is a pretty good international mirror). The trick is in getting an adequately large number of CTA in the mirror network so that no one has too large a burden, but an adequately small number to speed propogation. Certainly, if a site outside of this CTA network were to elect to mirror, on its own, one of the CTA sites, even better! If each CTA has a list of partner STAs it is responsible for (for example, ymir may have responsibility for e-math.ams.com) and it polls those STAs every 24 hours, this means that a new file placed on e-math will be fully propogated in something like 60 hours (the 24 hour polling window + the 36 hour CTA propogation time), or 2.5 days. With proper partnerships between CTAs and their companion STAs, we can easily cut down on net traffic as most of the incoming files from the STAs will get to the CTA network via one and only one connection covering less physical distance. Clearly, the cost factor for each CTA site needs to be considered, but I believe that who each site can connect to most efficiently will be relatively easy to identify. Also, it is fully conceivable that some sites may serve exclusively as a CTA (for example, maybe Stuttgart just wants to be a CTA and not have any STA partners -- fine, so long as we know that and another site can handle the load). Two very attractive benefits accrue. First, a development area (which I placed under the /tex-archive/user-groups branch in my prior post) can be coordinated and appear on all CTA network hosts. Second, *a* specific home site for any file can be identified, allowing much better quality control over version updates, etc., as compared to the current system. This specific file home site does not need to be a CTA (in some cases, such as the Mittelbach/Schoepf files, I would be very surprised if Stuttgart didn't serve as the authoritative host; in other cases, all which would be necessary is which STA host wherever in the world was preferred by the file or package's author, such as eplain, modes, etc., at ftp.cs.umb.edu). As far as the end user is concerned, I don't believe that they would care that SHSU was the CTA entry point for eplain, so long as they knew where the authoritative site was for the author's work. As far as the archivists are concerned, it is a simple table lookup as to which CTA is the incoming entry point for files from the STA. Now that you've seen my dreamland (yes, I did have to go into a hospital for extensive sleep studies recently 8-)) for what we can do in a mirroring network, which I believe to be feasible under Unix presently and I hope is capable on VMS eventually, I would love to hear your comments. This is where all of my inquiries have been headed since late March/early April. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Mon Jun 15 19:51:54 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17681; Mon, 15 Jun 92 19:51:52 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from theory.lcs.mit.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Mon, 15 Jun 1992 20:50:47 CDT Received: from GYRFALCON.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA24045; Mon, 15 Jun 92 21:50:22 EDT From: dmjones@theory.lcs.mit.edu (David M. Jones) Reply-To: TWG@SHSU.edu Received: by gyrfalcon.lcs.mit.edu (5.65c/TOC-1.2C) id AA11667; Mon, 15 Jun 92 21:46:14 EDT Date: Mon, 15 Jun 92 21:46:14 EDT Message-Id: <199206160146.AA11667@gyrfalcon.lcs.mit.edu> To: twg@shsu.edu Subject: (1) Databases and (2) compression schemes I have a couple of random comments/questions. 1) Has anyone given any thought to how (or whether) the archie database should be utilized by the TeX archives? Do the archie-architects know anything that would be useful to the TeX world? Also, as far as I can tell, none of the major TeX archives are currently represented in the archie database. Is this intentional? 2) There's been some discussion of whether ZOO or ZIP should be used by the archives. Two part question: a) Mail servers typically allow several options for archiving and encoding files. What options should mail servers support? (By the way, is vvencode ready for use yet?) b) Also, on the extreme speculative side of things, is there any way that ftp could be modified to allow the user to specify an archiving scheme interactively? That is, could the user specify that a file should be ZIPed or ZOOed before transfer? This would have the advantage that the archive would only have to keep a plain text version of most files around. Unfortunately, I suspect that the overhead of compressing files on the fly in real time would be prohibitive. David. From ITeX-Mgr@SHSU.edu Tue Jun 16 08:24:01 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20549; Tue, 16 Jun 92 08:23:59 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 25483; Tue, 16 Jun 1992 09:22:17 CDT Date: Tue, 16 Jun 1992 09:22:10 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: info-tex@SHSU.edu, tex-archive@math.utah.edu, twg@SHSU.edu Cc: texhax@tex.ac.uk, uktex@tex.ac.uk Message-Id: <0095C2DE.B5202A00.25483@SHSU.edu> Subject: MS-DOS compiled versions of ZIP/UNZIP on FILESERV/Niord I've had a few private posts from people on MS-DOS machines which, for various reasons, cannot create the UNZIP and ZIP utilities I announced last week (most of them have created it on their larger system and want it for the PC now that they're hooked on its performance and platform independence). I have created yet another package for your access, which contains the pre-compiled MS-DOS executables for your use. Attached is the description file. --George =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= ZIP_PC_COMPILED --------------- The ZIP_PC_COMPILED package includes UUENCODEd files which include the MS-DOS executables and documentation for Info-Zip's ZIP (v. 1.0) and UNZIP (v. 4.2) utilities. This set is built entirely from the source files distributed in the ZIP and UNZIP packages and is completely compatible with the wide variety of platforms under which those utilities can be compiled. This implementation is largely compatible with the widely-used PK*ZIP suite of utilities, although there are some differences. The UNZIP variant of this distribution UUDECODEs to UNZIP42.EXE, a self-exploding executable which creates the UNZIP executable under MS-DOS, as well as the accompanying documentation. The ZIP variant of this distribution UUDECODEs to a ZIP archive file, which may be unzipped with UNZIP or with most versions of PKUNZIP. The ZIP archive file includes the MS-DOS executable and documentation for ZIP. To retrieve the package of two files distributed in three parts, include: SENDME ZIP_PC_COMPILED in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). To retrieve a specific file, such as ZIP_PC_COMPILED.UNZIP42_UUE, include: SENDME ZIP_PC_COMPILED.UNZIP42_UUE in your mail message to FILESERV. For anonymous ftp retrieval of these files, they are available in their original form from Niord.SHSU.edu (192.92.115.8) in the directory [.ZIP_PC_COMPILED]. Files in this package: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- ZIP_PC_COMPILED.UNZIP42_UUE 72 UNZIP42.UUE ZIP_PC_COMPILED.ZIP10EXX_UUE_1OF2 79 ZIP10EXX.UUE ZIP_PC_COMPILED.ZIP10EXX_UUE_2OF2 49 (concatenate to part 1, then decode) Approximate total blocks in full ZIP_PC_COMPILED package = 200 From ITeX-Mgr@SHSU.edu Tue Jun 16 12:11:01 1992 Flags: 000000000001 Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22332; Tue, 16 Jun 92 12:10:58 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from manta.cs.washington.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 16 Jun 1992 13:08:46 CDT Received: by manta.cs.washington.edu (5.64a/7.0cr) id AA20034; Tue, 16 Jun 92 11:08:45 -0700 Date: Tue, 16 Jun 92 11:08:45 -0700 From: mackay@cs.washington.edu Reply-To: TWG@SHSU.edu Return-Path: Message-Id: <9206161808.AA20034@manta.cs.washington.edu> To: TWG@SHSU.edu Cc: TWG@SHSU.EDU In-Reply-To: CHAA006@VAX.RHBNC.AC.UK's message of Mon, 15 JUN 92 12:13:47 BST <21E010D2_001E14F8.0095C22D83A60460$19_1@UK.AC.RHBNC.VAX> Subject: TeX CD-ROM I believe that High Sierra is pretty widespread as a physical format, but that is less than half the fight. All it would permit is the raw dumping of consistently sized blocks (or whatever High Sierra breaks down into) through utilities like Unix dd. The problem of file hierarchies etc still remains---doesn't it? Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 From ITeX-Mgr@SHSU.edu Tue Jun 16 12:13:21 1992 Flags: 000000000001 Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22366; Tue, 16 Jun 92 12:13:15 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from manta.cs.washington.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 16 Jun 1992 13:08:46 CDT Received: by manta.cs.washington.edu (5.64a/7.0cr) id AA20034; Tue, 16 Jun 92 11:08:45 -0700 Date: Tue, 16 Jun 92 11:08:45 -0700 From: mackay@cs.washington.edu Reply-To: TWG@SHSU.edu Return-Path: Message-Id: <9206161808.AA20034@manta.cs.washington.edu> To: TWG@SHSU.edu Cc: TWG@SHSU.EDU In-Reply-To: CHAA006@VAX.RHBNC.AC.UK's message of Mon, 15 JUN 92 12:13:47 BST <21E010D2_001E14F8.0095C22D83A60460$19_1@UK.AC.RHBNC.VAX> Subject: TeX CD-ROM I believe that High Sierra is pretty widespread as a physical format, but that is less than half the fight. All it would permit is the raw dumping of consistently sized blocks (or whatever High Sierra breaks down into) through utilities like Unix dd. The problem of file hierarchies etc still remains---doesn't it? Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 From ITeX-Mgr@SHSU.edu Tue Jun 16 12:35:30 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22471; Tue, 16 Jun 92 12:35:25 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 16 Jun 1992 13:31:09 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA16681; Tue, 16 Jun 1992 14:31:03 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA19208; Tue, 16 Jun 92 14:31:02 EDT Date: Tue, 16 Jun 92 14:31:02 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9206161831.AA19208@claude.cs.umb.edu> To: TWG@SHSU.edu In-Reply-To: David M. Jones's message of Mon, 15 Jun 92 21:46:14 EDT <199206160146.AA11667@gyrfalcon.lcs.mit.edu> Subject: archie Reply-To: TWG@SHSU.edu 1) Has anyone given any thought to how (or whether) the archie database should be utilized by the TeX archives? archie just goes sniffing around the world building directory lists and saving them in a db for retrieval, as I understand it. Different charter than what we're trying to do. Also, as far as I can tell, none of the major TeX archives are currently represented in the archie database. archie only looks on Unix hosts. I thought it looked everywhere, automatically, but maybe not. From ITeX-Mgr@SHSU.edu Tue Jun 16 13:51:10 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22861; Tue, 16 Jun 92 13:51:08 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from theory.lcs.mit.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 16 Jun 1992 14:42:33 CDT Received: from GYRFALCON.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA02341; Tue, 16 Jun 92 15:42:16 EDT From: dmjones@theory.lcs.mit.edu (David M. Jones) Reply-To: TWG@SHSU.edu Received: by gyrfalcon.lcs.mit.edu (5.65c/TOC-1.2C) id AA12038; Tue, 16 Jun 92 15:37:47 EDT Date: Tue, 16 Jun 92 15:37:47 EDT Message-Id: <199206161937.AA12038@gyrfalcon.lcs.mit.edu> To: TWG@SHSU.edu In-Reply-To: Karl Berry's message of Tue, 16 Jun 92 14:31:02 EDT <9206161831.AA19208@claude.cs.umb.edu> Subject: archie > Also, as far as I can tell, none of the major TeX archives are currently > represented in the archie database. > >archie only looks on Unix hosts. I thought it looked everywhere, >automatically, but maybe not. The UNIX-only rule explains why ymir, Aston, and SHSU aren't covered, but not why Stuttgart isn't. Is there anyway to get listings of the VMS TeX archives included in Archie (assuming, of course, that this is desirable and worthwhile)? The reason I brought this up is that at least two people have sent me mail saying that the "Archive:" field of my Index was made superfluous by Archie. I was skeptical of this from the start, but I was surprised to find how far from true it was. David. From ITeX-Mgr@SHSU.edu Tue Jun 16 14:09:03 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22939; Tue, 16 Jun 92 14:09:00 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 16 Jun 1992 15:02:23 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA17879; Tue, 16 Jun 1992 16:02:12 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA19334; Tue, 16 Jun 92 16:02:11 EDT Date: Tue, 16 Jun 92 16:02:11 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9206162002.AA19334@claude.cs.umb.edu> To: TWG@SHSU.edu In-Reply-To: David M. Jones's message of Tue, 16 Jun 92 15:37:47 EDT <199206161937.AA12038@gyrfalcon.lcs.mit.edu> Subject: archie Reply-To: TWG@SHSU.edu The UNIX-only rule explains why ymir, Aston, and SHSU aren't covered, but not why Stuttgart isn't. I'm clueless about this. Is there anyway to get listings of the VMS TeX archives included in Archie (assuming, of course, that this is desirable and worthwhile)? I would say it's desirable and worthwhile, but it's obviously up to the archie people. I don't know where to reach them, unfortunately. The reason I brought this up is that at least two people have sent me mail saying that the "Archive:" field of my Index was made superfluous by Archie. archie cannot tell you where the ``official'' home of something is. The Archive: field index would be useful for that if nothing else -- and, of course, it is useful for those people without access to archie, not to mention connecting to archie takes a heck of a lot longer than looking up a file on your local network. From ITeX-Mgr@SHSU.edu Tue Jun 16 14:27:13 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23072; Tue, 16 Jun 92 14:27:08 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from theory.lcs.mit.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 16 Jun 1992 15:13:36 CDT Received: from GYRFALCON.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA02628; Tue, 16 Jun 92 16:13:28 EDT From: dmjones@theory.lcs.mit.edu (David M. Jones) Reply-To: TWG@SHSU.edu Received: by gyrfalcon.lcs.mit.edu (5.65c/TOC-1.2C) id AA12082; Tue, 16 Jun 92 16:08:59 EDT Date: Tue, 16 Jun 92 16:08:59 EDT Message-Id: <199206162008.AA12082@gyrfalcon.lcs.mit.edu> To: TWG@SHSU.edu In-Reply-To: Karl Berry's message of Tue, 16 Jun 92 16:02:11 EDT <9206162002.AA19334@claude.cs.umb.edu> Subject: archie > The reason I brought this up is that at > least two people have sent me mail saying that the "Archive:" field of > my Index was made superfluous by Archie. > >archie cannot tell you where the ``official'' home of something is. The >Archive: field index would be useful for that if nothing else -- and, of >course, it is useful for those people without access to archie, not to >mention connecting to archie takes a heck of a lot longer than looking >up a file on your local network. Thank you. These are the same reasons I had thought of, but it's good to have them confirmed by someone else. Cheers, David. From ITeX-Mgr@SHSU.edu Tue Jun 16 14:48:46 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23244; Tue, 16 Jun 92 14:48:42 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 16 Jun 1992 15:16:18 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA18042; Tue, 16 Jun 1992 16:16:17 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA19369; Tue, 16 Jun 92 16:16:16 EDT Date: Tue, 16 Jun 92 16:16:16 EDT From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <9206162016.AA19369@claude.cs.umb.edu> To: TWG@SHSU.edu In-Reply-To: Joachim Schrod's message of Fri, 12 Jun 92 20:10:57 MESZ <9206121810.AA02890@hp5.iti.informatik.th-darmstadt.de> Subject: Nelson's macro markup schema I don't mind if file headers become RFC822-like instead of BibTeX-like. Does anyone disagree? Nelson? The only thing I don't like is having to indent paragraphs instead of separating them with blank lines. Joachim offers the possibility of delimiting field text with 1) continuation lines (ugh, I don't want to deal with a backslash or whatever on every line) or 2) ... , which seems verbose to me. Is there any difficulty with allowing quotes " ... " (or braces, or left quotes and right quotes, whatever) to delimit the field text? It would be acceptable to me that the delimiter cannot be used in the text itself (i.e., no escapes a la C). In the proposal there should be remarks which fields are mandatory and which are optional. As a practical matter, all fields are optional. Certainly any program to read such things should never give up if some ``mandatory'' field isn't found. I think the description of the header scheme should just recommend using certain fields for all files. Joachim's list of such fields seems ok to me, except I don't know what `Document schema' is. The version number of the header scheme itself the document purports to conform to? From ITeX-Mgr@SHSU.edu Tue Jun 16 16:09:15 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23622; Tue, 16 Jun 92 16:09:12 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 16 Jun 1992 16:50:08 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA19010; Tue, 16 Jun 1992 17:49:52 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA19467; Tue, 16 Jun 92 17:49:51 EDT Date: Tue, 16 Jun 92 17:49:51 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9206162149.AA19467@claude.cs.umb.edu> To: TWG@SHSU.edu In-Reply-To: "George D. Greenwade"'s message of Mon, 15 Jun 1992 13:56:56 CDT <0095C23B.ED17B2A0.22307@SHSU.edu> Subject: Directory structure as it now stands Reply-To: TWG@SHSU.edu FILES.TXT -- (ls -lR or, for VMS, something similar to Didn't we agree on all lowercase? * UPDATE30.BY-BATE -- reverse-date ordered UPDATE30.TXT ... * UPDATE7.BY-BATE -- reverse-date ordered UPDATE7.TXT Typo in these two, George :-) * /bibtex * /base (minimally required; primarily original distrtibution) Is this just bibtex.web, or does it include the documentation, or does it include btxmac.tex, or what? * /bst * /supported * /unsupported Is this the best distinction to make when you're just retrieving the files? Presumably each file should say within it. Speaking as an archive user, I'd just as soon have all the bst files in one directory. If there was a README file which described the output style implemented by each, that would be perfectly sufficient. I guess this supported/unsupported distinction is made in many other places in the tree. I'm sorry I didn't see this before. * /tools ? I'd prefer to put other programs in their own directory, at the same level as `bibtex', instead of hiding them in yet another layer. `tib', for example, and `refer2bib'. /tex-archive/conversion Converters for xxx2TeX, such as RTF2TeX, word2TeX, etc.; each in its own subdir. or tex2xxx, right? (if there are any, surely there are.) By the way, I once heard it advanced that using `2' for `to' is rather parochial, since it doesn't translate into any other languages. So I try to use `to' for everything (except web2c, which is too late to change). Is this true (I guess I'm asking the people on this list whose native language is not English), or is it a meaningless nit? /tex-archive/drivers {\em Original} sources for xxx2DVI-type drivers; each in its own subdir. Operating system-specific ports appear in /tex-archive/systems/"OS"/drivers (where "OS" is the specific operating system. I think you mean dvi2xxx. Less trivially, I don't understand the connection between this and systems/. Every driver is originally written to work on some system, and if the sources aren't ``original'', then it's a different driver, is it not? Actually, it's more likely that a driver is written to work on multiple systems. Put another way, I think the drivers should be separated as they are in tex-archive/drivers, by program name, and not shoved down under systems/. This leaves the question of what goes under systems/. The ports of TeX and the other programs themselves? Something seems wrong here. I need to think before I blather on more about it, though. /tex-archive/extensions I'm confused. This seems to be a directory of macro packages. Then why don't we call it `macros', instead of `extensions'? The latter could also mean extensions to tex.web itself, e.g., xet-tex. * /tex-macro (moved to extensions out of its own second-level directory) I'd just call this `plain', meaning macros that work with plain TeX (and possibly everything else), as opposed to macro files which only work with LaTeX or whatever. * /latex-style (moved to extensions out of its own second-level directory) * /base (minimally required; Lamport/Mittelbach/Schoepf files) * /supported * /unsupported Shouldn't the directory be called `latex', with subdirectories for the base LaTeX system maintained now by F&R and all the other contributed styles? others; each in its own subdir. What about the (surely numerous) files which are just single files. `path.sty', for example. I guess this would go in `tex-macro' (or `plain')? * /tex-archive/help (previously included as /tex-archive/hints; this name I think help is an excellent name. /msdos How about just `dos', since Microsoft doesn't exactly have a monopoly anymore (if they ever did)? Maybe this is another thing no one cares about. /tex-archive/web-sources /cweb /mf /spiderweb /tex Why are mf and tex here? I would expect the original tangle/weave, if the directory is for sources to WEBS, as opposed to simply programs written in WEB (this latter is not what we want, IMHO). The only thing I can think of to do with tex.web and mf.web themselves is make a top-level directory tex-archive/sources and put them (and nothing else, I guess) there. From ITeX-Mgr@SHSU.edu Tue Jun 16 17:20:07 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24055; Tue, 16 Jun 92 17:20:01 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 16 Jun 1992 17:58:56 CDT Received: from plot79.math.utah.edu.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23864; Tue, 16 Jun 92 16:58:53 MDT Date: Tue, 16 Jun 92 16:58:53 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Re: Directory structure as it now stands In-Reply-To: Your message of Tue, 16 Jun 92 17:49:51 EDT Message-Id: Karl Berry objects to the name msdos in the proposed archive tree, and suggests it be reduced to dos since Microsoft is not the only supplier. However, dos is also used by other vendors (including IBM for an old small mainframe system). I always make a habit of using pcdos (or in text, PC DOS), which is a little more generic, and personal computer oriented. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Wed Jun 17 05:11:54 1992 Flags: 000000000011 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27428; Wed, 17 Jun 92 05:11:50 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 17 Jun 1992 06:11:15 CDT Via: vax.rhbnc.ac.uk; Wed, 17 Jun 1992 12:10:30 +0100 Date: Wed, 17 JUN 92 11:25:44 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: Miscellaneous Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <25000284_0031DEB0.0095C3B9218AD340$17_2@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) [A few comments on the plethora of messages which have arrived while my VAX was down ...] >>> The checksum is very important, because it is the only way a recipient >>> can tell if the file has been received uncorrupted. Corruption, >>> especially via e-mail, is rampant. Also, undocumented changes are a >>> form of corruption; the checksum will catch them too. I can see the benefit of a checksum, but am not sure of the implementation details. Does the checksum include the header? If so, does it include its own record in the header? Does it include the leading per-cents in the header? If it includes none of these, isn't a great deal of integrity- checking lost? How do the leading per-cents fit into the proposal that the markup scheme is appropriate for all text files, not just TeX ones? >>> archie only looks on Unix hosts. I thought it looked everywhere, >>> automatically, but maybe not. Here follows some correspondence with the Archie authors, which I sent privately to George earlier: When the existence of archie was first promulgated, I was disappointed to read that the initial issue was only able to understand Un*x-based archives. Here at Aston University we run what is believed to be the largest archive of TeX- related material in the world; this is hosted on a VMS machine. This didn't worry us overmuch, since we were only contactable via the Janet network. SO the burning question of the day is: Can you handle a VMS-archive listing, and would it propagate to all archie servers? Furthermore, would archie clients (both human and program) understand the VMS directory syntax bits? Best regards, and thanks for a great product, -------- We have always intended to include VMS listing into archie and I'm happy to say that it will be a reality in the next month or so. This is when we are due to launch the next version (3.0) of the system. We do have one VMS parser written (and will be writing others since there are several VMS formats) in the next little while. Under the new system the archie information will be automatically distributed throughout the system and the database is written to accommodate the various VMS permissions fields in toto (although archie clients are free to pick and choose whereever). >>> The only thing I don't like is having to indent paragraphs instead of >>> separating them with blank lines. Joachim offers the possibility of >>> delimiting field text with >>> 1) continuation lines (ugh, I don't want to >>> deal with a backslash or whatever on every line) >>> or 2) ... , which seems verbose to me. >>> Is there any difficulty with allowing quotes " ... " (or braces, or left >>> quotes and right quotes, whatever) to delimit the field text? It would >>> be acceptable to me that the delimiter cannot be used in the text itself >>> (i.e., no escapes a la C). I think that the use of such characters is too error-prone; in the first version of Path.Sty which Nelson sent to me, there was an unescaped string quote within the text. If the author himself can make such an error, what hope have we lesser mortals?! I would advocate the Begin: End: approach for multi-line entity values. >> I always make a habit of using pcdos (or in text, PC DOS), which >> is a little more generic, and personal computer oriented. Unfortunately, PC DOS is frequently used to refer to the IBM-specific version of DOS for IBM PCs & PS2s. vide Windows 3.1 Secrets by Brian Livingstone, p.378: ``For IBM PCs & PS/2s, this version of DOS is referred to as PC-DOS [...]'' ** Phil. From ITeX-Mgr@SHSU.edu Wed Jun 17 05:28:12 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27452; Wed, 17 Jun 92 05:28:07 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 17 Jun 1992 06:27:34 CDT Via: vax.rhbnc.ac.uk; Wed, 17 Jun 1992 12:26:50 +0100 Date: Wed, 17 JUN 92 12:26:37 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: Miscellaneous Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <250006A5_00076CF0.0095C3C1A3669040$26_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) [A few comments on the plethora of messages which have arrived while my VAX was down ...] >>> The checksum is very important, because it is the only way a recipient >>> can tell if the file has been received uncorrupted. Corruption, >>> especially via e-mail, is rampant. Also, undocumented changes are a >>> form of corruption; the checksum will catch them too. I can see the benefit of a checksum, but am not sure of the implementation details. Does the checksum include the header? If so, does it include its own record in the header? Does it include the leading per-cents in the header? If it includes none of these, isn't a great deal of integrity- checking lost? How do the leading per-cents fit into the proposal that the markup scheme is appropriate for all text files, not just TeX ones? >>> archie only looks on Unix hosts. I thought it looked everywhere, >>> automatically, but maybe not. Here follows some correspondence with the Archie authors, which I sent privately to George earlier: When the existence of archie was first promulgated, I was disappointed to read that the initial issue was only able to understand Un*x-based archives. Here at Aston University we run what is believed to be the largest archive of TeX- related material in the world; this is hosted on a VMS machine. This didn't worry us overmuch, since we were only contactable via the Janet network. SO the burning question of the day is: Can you handle a VMS-archive listing, and would it propagate to all archie servers? Furthermore, would archie clients (both human and program) understand the VMS directory syntax bits? Best regards, and thanks for a great product, -------- We have always intended to include VMS listing into archie and I'm happy to say that it will be a reality in the next month or so. This is when we are due to launch the next version (3.0) of the system. We do have one VMS parser written (and will be writing others since there are several VMS formats) in the next little while. Under the new system the archie information will be automatically distributed throughout the system and the database is written to accommodate the various VMS permissions fields in toto (although archie clients are free to pick and choose whereever). >>> The only thing I don't like is having to indent paragraphs instead of >>> separating them with blank lines. Joachim offers the possibility of >>> delimiting field text with >>> 1) continuation lines (ugh, I don't want to >>> deal with a backslash or whatever on every line) >>> or 2) ... , which seems verbose to me. >>> Is there any difficulty with allowing quotes " ... " (or braces, or left >>> quotes and right quotes, whatever) to delimit the field text? It would >>> be acceptable to me that the delimiter cannot be used in the text itself >>> (i.e., no escapes a la C). I think that the use of such characters is too error-prone; in the first version of Path.Sty which Nelson sent to me, there was an unescaped string quote within the text. If the author himself can make such an error, what hope have we lesser mortals?! I would advocate the Begin: End: approach for multi-line entity values. >> I always make a habit of using pcdos (or in text, PC DOS), which >> is a little more generic, and personal computer oriented. Unfortunately, PC DOS is frequently used to refer to the IBM-specific version of DOS for IBM PCs & PS2s. vide Windows 3.1 Secrets by Brian Livingstone, p.378: ``For IBM PCs & PS/2s, this version of DOS is referred to as PC-DOS [...]'' ** Phil. From ITeX-Mgr@SHSU.edu Wed Jun 17 09:41:53 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28341; Wed, 17 Jun 92 09:41:47 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 17 Jun 1992 10:24:44 CDT Received: from plot79.math.utah.edu.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28207; Wed, 17 Jun 92 09:24:26 MDT Date: Wed, 17 Jun 92 09:24:26 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 In-Reply-To: Your message of Wed, 17 JUN 92 11:25:44 BST Subject: File header documentation and checksum program Message-Id: Philip Taylor writes: >> ... >> I can see the benefit of a checksum, but am not sure of the implementation >> details. Does the checksum include the header? If so, does it include >> its own record in the header? Does it include the leading per-cents in >> the header? If it includes none of these, isn't a great deal of integrity- >> checking lost? How do the leading per-cents fit into the proposal that >> the markup scheme is appropriate for all text files, not just TeX ones? >> ... The manual page for checksum provides a positive answer to these questions; it is appended below. The question about leading percents vs TeX files is answered by observing that the file headers are hidden inside whatever comment syntax the file's language provides. To make them distinctive, the comment-start symbol is duplicated or triplicated. Further details can be found in the complete typeset description of the file header package, available on ftp.math.utah.edu in ~ftp/pub/tex/bib in these files: -rw-r--r-- 1 beebe 621 Jun 3 14:15 filehdr-1.19.tar-lst -rw-r--r-- 1 beebe 86073 Jun 3 14:15 filehdr-1.19.tar.z -rw-r--r-- 1 beebe 74681 Jun 3 14:14 filehdr-1.19.zip -rw-r--r-- 1 beebe 836 Jun 3 14:14 filehdr-1.19.zip-lst -rw-r--r-- 1 beebe 101231 Jun 3 14:13 filehdr-1.19.zoo -rw-r--r-- 1 beebe 649 Jun 3 14:15 filehdr-1.19.zoo-lst -rw-r--r-- 1 beebe 57976 May 29 10:27 filehdr.el Via e-mail, send a message with the text send filehdr-1.19.zip from ftp/tex/bib to tuglib@math.utah.edu. The tar, zip, and zoo files contain the same information: namely, the complete LaTeX documentation, Makefile, Emacs info file, and GNU Emacs Lisp code. The Lisp code is also available separately in filehdr.el. I hope readers of this list will look at the filehdr document to see the generality behind these file headers. Here is the checksum manual page subsection: >> ... >> DESCRIPTION >> checksum will search for the first line of its input which >> contains the word checksum in lowercase and no other alpha- >> betic characters. We refer to this line as the ``critical >> line'' of the file. If the critical line contains no quota- >> tion marks, then the output file created is a copy of the >> input file, except that the critical line is replaced by a >> line where the word checksum is replaced by Here, lc is the >> number of lines in the output file, written in decimal. >> Similarly, wc is the word count of the output file, and cc >> is the character count when the end of line character is >> taken to be the single character ASCII newline (octal 012). >> >> For many text files, it is possible to hide the ``critical >> line'' in a comment near the beginning of the file. >> >> It is difficult to arrange that a file contains its own >> checksum. Instead, the field xxxxx contains the checksum, >> written in decimal in a five-digit field (with possible >> leading 0's) of the file obtained from the output file by >> replacing the field containing the checksum by the string >> >> ZZZZZ. >> >> If the critical line already contains after the word >> ``checksum'' precisely two quotation marks, and the first is >> the last character of the four-character string ,"" " = ", >> then the material between the two quotation marks will be >> deleted and replaced by a checksum and three counts as >> described above. >> >> While the counts of words, characters, and lines could be >> obtained by the UNIX wc(1) utility, that information is >> still not sufficient to detect character substitutions, or >> transpositions of characters, lines, and words. The CRC-16 >> checksum remedies that, since the resulting checksum depends >> on the order and value of every single byte in the file. >> >> checksum is intended to support the reliable exchange of >> text files between different computers, even ones with dif- >> ferent operating systems. Thus, the newline character >> sequence that terminates each line is treated as if it were >> an ASCII newline (linefeed) character, even though it may be >> a carriage return, a carriage return and a line feed, or >> simply an end-of-record condition in the file, depending on >> the operating system and file type. The file checksum is >> therefore independent of the particular representation of >> end-of-line. >> >> Although UNIX systems have a file checksum utility, sum(1), >> the result it produces differs between UNIX variants, and in >> any event, it is neither publicly available for porting to >> other systems, nor independent of the end-of-line represen- >> tation. checksum is freely available. >> ... ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Thu Jun 18 01:56:21 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04877; Thu, 18 Jun 92 01:56:19 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from uu.psi.com by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 18 Jun 1992 02:48:41 CDT Received: from radel.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) id AA01232; Thu, 18 Jun 92 03:42:33 -0400 Date: Wed, 17 Jun 92 22:57:00 EDT From: jon@radel.com (Jon Radel) Reply-To: TWG@SHSU.edu Subject: Re: archie Message-Id: <9206172257.0.UUL1.3#20406@radel.com> To: TWG@SHSU.edu Cc: jon@radel.com In-Reply-To: Your message of Tue, 16 Jun 92 15:37:47 EDT > > Also, as far as I can tell, none of the major TeX archives are currently > > represented in the archie database. > > > >archie only looks on Unix hosts. I thought it looked everywhere, > >automatically, but maybe not. > > The UNIX-only rule explains why ymir, Aston, and SHSU aren't covered, > but not why Stuttgart isn't. Is there anyway to get listings of the > VMS TeX archives included in Archie (assuming, of course, that this is > desirable and worthwhile)? The reason I brought this up is that at > least two people have sent me mail saying that the "Archive:" field of > my Index was made superfluous by Archie. I was skeptical of this from > the start, but I was surprised to find how far from true it was. > > David. Superfluous just because there is are information servers that index files by file name using brute force? Yeah, sure. It works fine so long as everyone promises to faithfully encode version numbers in the filenames, not to change file names when moving information to another site, and to never, ever allow namespace clashes between different packages. Archie is a very, very useful tool, but it has a long way to go, IMHO, before it is in danger of replacing a catalog of files put together by a human who's paying attention and attempts to specify the archive which can be considered the authoritative source for a software package. --Jon Radel uucp: {rutgers etc.}!uupsi!radel!jon P.O. Box 2276 domain: jon@radel.com <-best Reston, VA 22090-0276 jon%radel.com@uu.psi.com <-2nd best U.S.A. From ITeX-Mgr@SHSU.edu Thu Jun 18 02:05:42 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04898; Thu, 18 Jun 92 02:05:39 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from uu.psi.com by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 18 Jun 1992 02:48:56 CDT Received: from radel.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) id AA01273; Thu, 18 Jun 92 03:42:57 -0400 Date: Wed, 17 Jun 92 23:30:52 EDT From: jon@radel.com (Jon Radel) Reply-To: TWG@SHSU.edu Subject: Re: TeX CD-ROM Message-Id: <9206172330.0.UUL1.3#20406@radel.com> To: TWG@SHSU.edu Cc: jon@radel.com In-Reply-To: Your message of Sat, 13 Jun 1992 21:31 PDT > > The complete ymir archive would easily fit on a CD ROM (it's > currently around 150M or so). > > The big problem with a CD ROM is that my understanding of the > technology is that it's difficult (impossible?) to have a > universal CD ROM readable on DOS/Mac/Unix/VMS which means that > one's market is made somewhat less reachable. Not to mention the > fluid nature of the contents. But as long as its not my money > being invested... > > -dh > Yes and no. If one wants to retain VMS file structure, 25 character UNIX filenames, Mac file "forks," etc. then, yes, you can't do it all on the same CD-ROM without some massive kludge. If you're willing to live within the constraints of ISO-9660 level 1 specs you end up with something that you can read on just about anything. You're limited to 8.3 character filenames, a limited number of levels of subdirectories (8?), and there are severe limits to the file structure you can impose. For universiality, you'd want to stick to "stream" type files. This is essentially what Walnut Creek CD-ROM does, though their UNIX oriented CD-ROMs come with a program to map the 8.3 file names to the original ones automatically. Their Mac files are MacBinaried, or functional equivalent, which they were on the UNIX archive machine anyway. DOS files survive just fine. In other words, it's only slightly more messy than using a UNIX machine for an ftp archive. For any of the TeX archives, the transfer to CD-ROM should be quite smooth. --Jon Radel uucp: {rutgers etc.}!uupsi!radel!jon P.O. Box 2276 domain: jon@radel.com <-best Reston, VA 22090-0276 jon%radel.com@uu.psi.com <-2nd best U.S.A. From ITeX-Mgr@SHSU.edu Thu Jun 18 08:35:16 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06388; Thu, 18 Jun 92 08:35:12 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 18 Jun 1992 09:06:12 CDT Via: vax.rhbnc.ac.uk; Thu, 18 Jun 1992 15:05:05 +0100 Date: Thu, 18 JUN 92 15:05:00 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: RE: File header documentation and checksum program Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <20201EF7_00075020.0095C4A0EDFA40E0$37_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) Well, I'm sorry Nelson, but the manual page makes little sense to me: >> If the critical line contains no quota- >> tion marks, then the output file created is a copy of the >> input file, except that the critical line is replaced by a >> line where the word checksum is replaced by Here, lc is the >> number of lines in the output file, written in decimal. >> Similarly, wc is the word count of the output file, and cc >> is the character count when the end of line character is >> taken to be the single character ASCII newline (octal 012). `... is replaced by "Here"'? Why replace "checksum" by "Here"? I don't understand this bit at all. What are `lc', `wc' and 'cc'? You define them, but nowhere say where they are used. >> It is difficult to arrange that a file contains its own >> checksum. Instead, the field xxxxx contains the checksum, >> written in decimal in a five-digit field (with possible >> leading 0's) of the file obtained from the output file by >> replacing the field containing the checksum by the string >> >> ZZZZZ. What field "xxxxx"? This is the first mention of such a field. >> If the critical line already contains after the word >> ``checksum'' precisely two quotation marks, and the first is >> the last character of the four-character string ,"" " = ", What four-character string? Assuming that the commas serve only to set off the string, I find four double quotes, five spaces and one equals. And why does CheckSum have this string hard-coded into it? Surely its applicability goes far beyond any one document markup schema? So then I thought I'd try the document to which you refer: >>> Further details can be found in the complete typeset description of >>> the file header package, available on ftp.math.utah.edu in >>> ~ftp/pub/tex/bib in these files: !ftp> cd ~ftp/pub/tex/bib !550 Unknown user name after ~ !ftp> cd ftp/pub/tex/bib !550 ftp/pub/tex/bib: No such file or directory. !ftp> quit Sorry, Nelson: I have enormous respect both for you and your achievements, but this latest offering is _definitely_ not up to your normal standards! ** Phil. From ITeX-Mgr@SHSU.edu Thu Jun 18 10:11:16 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17984; Thu, 18 Jun 92 10:11:08 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from theory.lcs.mit.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 18 Jun 1992 10:14:19 CDT Received: from GYRFALCON.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA19391; Thu, 18 Jun 92 11:14:03 EDT From: dmjones@theory.lcs.mit.edu (David M. Jones) Reply-To: TWG@SHSU.edu Received: by gyrfalcon.lcs.mit.edu (5.65c/TOC-1.2C) id AA13154; Thu, 18 Jun 92 11:14:00 EDT Date: Thu, 18 Jun 92 11:14:00 EDT Message-Id: <199206181514.AA13154@gyrfalcon.lcs.mit.edu> To: TWG@SHSU.edu In-Reply-To: CHAA006@VAX.RHBNC.AC.UK's message of Thu, 18 JUN 92 15:05:00 BST <20201EF7_00075020.0095C4A0EDFA40E0$37_1@UK.AC.RHBNC.VAX> Subject: File header documentation and checksum program I'm a bit bored just at the moment, so I thought I would answer this. >`... is replaced by "Here"'? Why replace "checksum" by "Here"? >I don't understand this bit at all. What are `lc', `wc' and 'cc'? >You define them, but nowhere say where they are used. A crucial line was left out, apparently because the original troff source for the manual is faulty. The offending text should read checksum will search for the first line of its input which contains the word checksum in lowercase and no other alphabetic characters. We refer to this line as the ``critical line'' of the file. If the critical line contains no quotation marks, then the output file created is a copy of the input file, except that the critical line is replaced by a line where the word checksum is replaced by checksum = "xxxxx lc wc cc". Here, lc is the number of lines in the output file, written in decimal. Similarly, wc is the word count of the output file, and cc is the character count when the end of line character is taken to be the single character ASCII newline (octal 012). >>> If the critical line already contains after the word >>> ``checksum'' precisely two quotation marks, and the first is >>> the last character of the four-character string ,"" " = ", This should presumably read If the critical line already contains after the word ``checksum'' precisely two quotation marks, and the first is the last character of the four-character string ` = "', then the material between the two quotation marks will be deleted and replaced by a checksum and three counts as described above. This is again a problem with the troff man page. >And why does CheckSum have this string hard-coded into it? >Surely its applicability goes far beyond any one document markup schema? I wondered about this also. The problem, as I see it, is that if you're going to imbed the checksum in the text of a file, the checksum calculating program must be able to identify the imbedded checksum and handle it correctly, which means that the checksum has to be imbedded in a specific way. (Can anyone parse that?) Would it be of any use to have an option that merely calculates the checksum of a file and prints the resulting number on the terminal? It seems to me that in all cases that I'm familiar with where checksums are used, they are imbedded inside the file and the programs for calculating or checking the checksums know exactly where to find them and, furthermore, the checksum-calculating routine is just part of some larger program (METAFONT, for example). >!ftp> cd ~ftp/pub/tex/bib >!550 Unknown user name after ~ >!ftp> cd ftp/pub/tex/bib >!550 ftp/pub/tex/bib: No such file or directory. >!ftp> quit Try "cd pub/tex/bib." Nelson was guilty of a minor bit of UNIX-centricity here. This sort of thing is why I make it a habit to always type "ls" ("dir" for the VMS folks) first when ftp'ing to a strange machine, so I can calibrate the path names I've been given with the location where ftp dumps me. David. From ITeX-Mgr@SHSU.edu Thu Jun 18 12:51:15 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07866; Thu, 18 Jun 92 12:51:12 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 1494; Thu, 18 Jun 1992 12:52:56 CDT Date: Thu, 18 Jun 1992 12:52:49 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095C48E.77BC0A60.1494@SHSU.edu> Subject: RE: File header documentation and checksum program On Thu, 18 JUN 92 17:44:26 BST, Phil Taylor posted: > David: Many thanks for your clarification. Now if I can just locate > "LaTeXinfo.Sty", which "filehdr.ltx" references, I shall be away... > (unless, of course, "LaTeXinfo.Sty" references something even more arcane > :-{) LaTeXinfo is, at least as I understand it, a LaTeX interface for TeXinfo, which is what the documentation for the GNU utilities is prepared in. The entire package is available on ee.utah.edu (128.110.8.42) in the anonymous ftp directory /emacs/HP-new/LaTeXinfo. If you'll wait a few minutes, I will put the latexinfo.sty style file on FILESERV (SENDME STY.LATEXINFO in about 15 minutes will get it, or ftp to the [.STY] directory on Niord.SHSU.edu). Also, I will zip up the contents and place it in the directory [.LATEXINFO] on Niord. Maybe I'll even UUENCODE the zip file, then split it into 80-block pieces for FILESERV access (I *really* am trying to avoid grading the stat exam I just got out of). Just out of curiousity, how many on this list do NOT run an Archie client and instead use the dreaded telnet into Archie? --George From ITeX-Mgr@SHSU.edu Thu Jun 18 12:58:55 1992 Flags: 000000000011 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07949; Thu, 18 Jun 92 12:58:51 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 18 Jun 1992 11:45:46 CDT Via: vax.rhbnc.ac.uk; Thu, 18 Jun 1992 17:44:34 +0100 Date: Thu, 18 JUN 92 17:44:26 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: RE: File header documentation and checksum program Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <20201C1C_000774D0.0095C4B73398D100$43_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) David: Many thanks for your clarification. Now if I can just locate "LaTeXinfo.Sty", which "filehdr.ltx" references, I shall be away... (unless, of course, "LaTeXinfo.Sty" references something even more arcane :-{) >> >And why does CheckSum have this string hard-coded into it? >> >Surely its applicability goes far beyond any one document markup schema? >> I wondered about this also. The problem, as I see it, is that if >> you're going to imbed the checksum in the text of a file, the checksum >> calculating program must be able to identify the imbedded checksum and >> handle it correctly, which means that the checksum has to be imbedded >> in a specific way. (Can anyone parse that?) >> Would it be of any use to have an option that merely calculates the >> checksum of a file and prints the resulting number on the terminal? >> It seems to me that in all cases that I'm familiar with where >> checksums are used, they are imbedded inside the file and the programs >> for calculating or checking the checksums know exactly where to find >> them and, furthermore, the checksum-calculating routine is just part >> of some larger program (METAFONT, for example). Well, it seems that the present "Checksum" both goes too far and not far enough: too far, in that it makes presuppositions about the format of the string for which it will both search and replace; not far enough, in that nowhere can I see how one uses "Checksum" to _check_ a received file for checksum (actually, can we call it CRC? so far as I can see, it's not a checksum at all, hence the somewhat misguided comment that it's very difficult for a checksum to include itself: for a true checksum, that's trivial; for a CRC, it's hellishly difficult ...). So, I would propose two enhancements to "Checksum": 1) That it accept as qualifier a string (`pattern') describing the string (`pattern') to be sought for and modified; the standard action might be equivalent to something like: $ Checksum /pattern="checksum = "" """ while for RFC-822-style CRCs it might be: $ Checksum /pattern="^Checksum: " where "^" is the GREP-like notation for beginning of line, ":d" is the GREP-like notation for digit-strings, and the tags denote the semantics of each field. Within string-quotes, a string-quote is represented by a doubled string quote. 2) That it accept a qualifier "/CheckOnly" which reports on the CRCs found and calculated, and notes any mismatch, without re-writing the file. Philip Taylor, RHBNC. From ITeX-Mgr@SHSU.edu Thu Jun 18 12:59:17 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07953; Thu, 18 Jun 92 12:59:12 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 18 Jun 1992 13:44:53 CDT Received: from plot79.math.utah.edu.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07802; Thu, 18 Jun 92 12:44:27 MDT Date: Thu, 18 Jun 92 12:44:27 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: Philip Taylor (RHBNC) , twg@shsu.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Re: For reference: recent message to TWG In-Reply-To: Your message of Thu, 18 JUN 92 15:05:36 BST Message-Id: Phil Taylor spotted a problem in the checksum manual page extract in yesterday's mail message from me; I've traced it to a bug in Sun's nroff which does not behave as both the original AT&T and Sun nroff/troff documentation specify with respect to handling of quotes. Here is the garbled first paragraph again, but from an ULTRIX system, which sets it correctly >> ... >> DESCRIPTION >> checksum will search for the first line of its input which contains the >> word checksum in lowercase and no other alphabetic characters. We refer >> to this line as the ``critical line'' of the file. If the critical line >> contains no quotation marks, then the output file created is a copy of >> the input file, except that the critical line is replaced by a line >> where the word checksum is replaced by checksum = "xxxxx lc wc cc". >> Here, lc is the number of lines in the output file, written in decimal. >> Similarly, wc is the word count of the output file, and cc is the char- >> acter count when the end of line character is taken to be the single >> character ASCII newline (octal 012). >> ... Later on, it says: >> ... >> If the critical line already contains after the word ``checksum'' pre- >> cisely two quotation marks, and the first is the last character of the >> four-character string " = ", then the material between the two quotation >> marks will be deleted and replaced by a checksum and three counts as >> ... This contains a transcription error from the TeX code in the original cweb source, which says >> ... >> >> four-character string |" = \""|, >> ... The string that is meant is . Consulting the cweb code uncovers the two lines if (s[j] != '"') {j++; continue;} if( (s[j-1] == ' ') && (s[j-2] == '=') && (s[j-3] == ' ')) which do precisely that check. I'll modify the checksum manual page to clarify this. Phil, thanks very much for your sharp eyes and persistence! Phil goes on to ask >> ... >> >>> Further details can be found in the complete typeset description of >> >>> the file header package, available on ftp.math.utah.edu in >> >>> ~ftp/pub/tex/bib in these files: >> >> !ftp> cd ~ftp/pub/tex/bib >> !550 Unknown user name after ~ >> !ftp> cd ftp/pub/tex/bib >> !550 ftp/pub/tex/bib: No such file or directory. >> !ftp> quit >> ... There is a bit of UNIXese in my description. Under UNIX with the Berkeley C shell or AT&T Korn shell (UNIX shell == DEC VMS DCL interpreter == DEC TOPS-20 EXEC == IBM PC DOS COMMAND.COM == command interpreter), ~/foo represents the subdirectory foo of the current user, and ~username/foo the subdirectory foo under the home directory of the indicated username. Thus ~ftp/pub means the subdirectory pub of the user named ftp. This is the correct path specification for a local user, and is in wide use on the UNIX part of the Internet. The reason for the ~ (tilde) abbreviation is to avoid the need to know the absolute path to the login directory, which varies from system to system; on ours, it is /home/csc-sun/someletter, where someletter is currently a, b, c, or d. However, when you do anonymous ftp to a UNIX host, you are talking to the ftp server, not the C or Korn shell. In the interests of security, anonymous ftp issues a chroot (change root) system call to make its login directory the root of the file system that is visible >From anonymous ftp. Thus ~ftp becomes equivalent to / (the filesystem root), and what you need to do is "cd pub/tex/bib", since at the login point, you are in the parent directory of pub. If you subsequently do a pwd (print working directory), or whatever your ftp implementation provides for that purpose, it will respond with ftp> pwd 257 "/pub/tex/bib" is current directory. Notice the /, arising from the chroot system call. The reason I don't write this file name as /pub/tex/bib is that it would be incorrect on any of our 80 local machines; on those, that directory must be referred to as ~ftp/pub/tex/bib. In the future, I'll try to make things clearer by writing, ``With anonymous ftp, do "cd pub/tex/bib", ...''. Thanks again for pointing out the confusion! ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Thu Jun 18 13:35:16 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA08170; Thu, 18 Jun 92 13:35:14 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 1816; Thu, 18 Jun 1992 14:10:48 CDT Date: Thu, 18 Jun 1992 14:09:40 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: info-tex@SHSU.edu, tex-archive@math.utah.edu, twg@SHSU.edu Cc: texhax@tex.ac.uk, uktex@tex.ac.uk Message-Id: <0095C499.33D31680.1816@SHSU.edu> Subject: SPAN access to FILESERV/Niord As usual, I overlook the simple and obvious. Michael Lemke , who was assisting me on an entirely unrelated topic, pointed out that the archives available on FILESERV and Niord can also be accessed via SPAN since THENET (the Texas Higher Education Network) is SPAN-connected via UTSPAN::UTADNX. Users on SPAN can access SHSU's root archive area in UTSPAN::UTADNX::SHSU::MX_ROOT:[FILESERV] You can then set default to any of the directories built off of the [FILESERV] root, backup, copy, or view the file(s) or directories you wish. Thought I'd pass this along. My thanks to Michael for pointing out this interface tool which we can painlessly make available. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Thu Jun 18 13:39:45 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA08185; Thu, 18 Jun 92 13:39:41 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 18 Jun 1992 14:10:48 CDT Via: vax.rhbnc.ac.uk; Thu, 18 Jun 1992 20:09:54 +0100 Date: Thu, 18 JUN 92 20:09:50 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: RE: File header documentation and checksum program Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <202030D5_00075168.0095C4CB83DEA720$12_2@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) [LaTeXinfo: Many thanks, George] >>> Just out of curiousity, how many on this list do NOT run an Archie client >>> and instead use the dreaded telnet into Archie? I use an Archie client under PC-DOS on my PS/2 but I never thought to use it to locate LaTeXinfo :-( ** Phil. From ITeX-Mgr@SHSU.edu Thu Jun 18 13:48:58 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA08252; Thu, 18 Jun 92 13:48:41 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from theory.lcs.mit.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 18 Jun 1992 14:19:37 CDT Received: from GYRFALCON.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA21480; Thu, 18 Jun 92 15:18:46 EDT From: dmjones@theory.lcs.mit.edu (David M. Jones) Reply-To: TWG@SHSU.edu Received: by gyrfalcon.lcs.mit.edu (5.65c/TOC-1.2C) id AA13327; Thu, 18 Jun 92 15:18:43 EDT Date: Thu, 18 Jun 92 15:18:43 EDT Message-Id: <199206181918.AA13327@gyrfalcon.lcs.mit.edu> To: TWG@SHSU.edu In-Reply-To: CHAA006@VAX.RHBNC.AC.UK's message of Thu, 18 JUN 92 17:44:26 BST <20201C1C_000774D0.0095C4B73398D100$43_1@UK.AC.RHBNC.VAX> Subject: File header documentation and checksum program >David: Many thanks for your clarification. Now if I can just locate >"LaTeXinfo.Sty", which "filehdr.ltx" references, I shall be away... >(unless, of course, "LaTeXinfo.Sty" references something even more >arcane :-{) That reminds me, I've been meaning to suggest that a DVI file be included with the standard filehdr distribution, to avoid this problem. Or would this cause problems because of the different ways that binary files are stored on UNIX vs. VMS vs. God-only-knows-what? >1) That it accept as qualifier a string (`pattern') describing the > string (`pattern') to be sought for and modified; the standard action > might be equivalent to something like: > > $ Checksum /pattern="checksum = "" """ > > while for RFC-822-style CRCs it might be: > > $ Checksum /pattern="^Checksum: " > > where "^" is the GREP-like notation for beginning of line, ":d" is the > GREP-like notation for digit-strings, and the tags denote the semantics > of each field. Within string-quotes, a string-quote is represented by > a doubled string quote. I think something of this sort would be grand. The only quibble I have is the use of doubled quotes to represent a string-quote; all the UNIX shells I know of would choke on that. (They'd want \" instead.) Presumably the way of imbedding quotes in a quoted string is operating-system dependent and the checksum program can be insulated >From it? >2) That it accept a qualifier "/CheckOnly" which reports on the CRCs found > and calculated, and notes any mismatch, without re-writing the file. Actually, there's a -v (would that be /v on VMS?) option that does this. Oops, I see that Nelson is back with us now, so I'll yield the floor to him. I do have some more thoughts about the BibTeX vs. RFC-822 style headers, but I'd like to hear what Nelson thinks about last week's dicusion first. Cheers, David. P.S. In answer to George's question, I still telnet to archie. You mean there's a better way? I'll have to check into this. From ITeX-Mgr@SHSU.edu Thu Jun 18 16:14:20 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09101; Thu, 18 Jun 92 16:14:12 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 2299; Thu, 18 Jun 1992 15:52:05 CDT Date: Thu, 18 Jun 1992 15:49:47 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095C4A7.3078E6A0.2299@SHSU.edu> Subject: Archie clients On Thu, 18 JUN 92 20:09:50 BST, Phil Taylor posted: > [LaTeXinfo: Many thanks, George] No problem! We've got a pretty good connection and it did get me away from grading temporarily. 8-) > >>> Just out of curiousity, how many on this list do NOT run an Archie client > >>> and instead use the dreaded telnet into Archie? > > I use an Archie client under PC-DOS on my PS/2 but I never thought to use > it to locate LaTeXinfo :-( This wasn't a slap at you, Phil (*please* don't take it that way!). I just happened to use Archie to find the file and it reminded me that I've been meaning to bring this up for about a week, but didn't want to interrupt any threads. One aspect of the proposed directory structure which no one has commented on is the inclusion of Archie client software in the archive-tools area. I meant to in my last revision of the directory tree and omitted it inadvertantly (as well as proving I can't type very well). As pointed out by others already, Archie has its limitations and (at least for now) can't be viewed as definitive or authoritative w.r.t. many of the topics we've discussed here. However, it is a good first-level tool and it is being ported to handle more architectures (read: VMS). Assuming the mirroring can be arranged to create my "dreamland" network of comprehensive and specialized archives, the network community will pretty much know where to go for what insofar as TeX files are concerned. As a prior user of TELNET-based Archie, I thought it was just about worthless. As a current user of client-based Archie (under MS-DOS, VMS, and HP-UX), I believe it to be wonderful. If we can propogate the clients among our users by having it available in our archives, maybe the "looking around" load can be reduced. Anyway, would anyone have any objection to including the sources (or maybe the precompiled executables) for Archie clients in the archive-tools area? Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Thu Jun 18 17:14:19 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09444; Thu, 18 Jun 92 17:14:17 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 2828; Thu, 18 Jun 1992 17:43:00 CDT Date: Thu, 18 Jun 1992 17:41:34 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095C4B6.CDDA1040.2828@SHSU.edu> Subject: Oooops, forgot something On Thu, 18 Jun 92 15:18:43 EDT David M. Jones posted: > P.S. In answer to George's question, I still telnet to archie. You mean > there's a better way? I'll have to check into this. We have the archie client software, already including the latest patch to put it to version 1.3.2 on Niord.SHSU.edu (192.92.115.8) in [FILESERV.ARCHIE]ARCHIE-1_3_2.ZIP. It builds on Unix, VMS, MS/PC-DOS, and OS2. The file ARCHIE.DOC is also there if you want to look at it first. Essentially, the client uses a protocol which allows you to have an executable use your TCP/IP connection, do the polling of the archie server, and the results are sent to your screen. Lots of nice options. The Archie folks claim it saves their resources significantly over TELNET connections. --George From beebe Thu Jun 18 17:27:46 1992 Flags: 000000000001 Return-Path: Received: from plot79.math.utah.edu.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09520; Thu, 18 Jun 92 17:27:26 MDT Date: Thu, 18 Jun 92 17:27:26 MDT From: Nelson H. F. Beebe To: TWG@SHSU.edu Cc: beebe X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: RE: File header documentation and checksum program In-Reply-To: Your message of Thu, 18 JUN 92 17:44:26 BST Message-Id: Philip Taylor asks about checksum verification. This is provided for: checksum -v filehdr.el will return a success or failure status code, and also display an informative message. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Thu Jun 18 17:47:55 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09641; Thu, 18 Jun 92 17:47:52 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 18 Jun 1992 18:27:36 CDT Received: from plot79.math.utah.edu.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09520; Thu, 18 Jun 92 17:27:26 MDT Date: Thu, 18 Jun 92 17:27:26 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: RE: File header documentation and checksum program In-Reply-To: Your message of Thu, 18 JUN 92 17:44:26 BST Message-Id: Philip Taylor asks about checksum verification. This is provided for: checksum -v filehdr.el will return a success or failure status code, and also display an informative message. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Fri Jun 19 03:11:44 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12901; Fri, 19 Jun 92 03:11:43 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from dir.nott.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 19 Jun 1992 04:10:26 CDT Received: from mips.nott.ac.uk by dir.nott.ac.uk with SMTP (PP) id <22203-0@dir.nott.ac.uk>; Fri, 19 Jun 1992 10:10:11 +0100 To: TWG@shsu.edu Subject: Re: File header documentation and checksum program In-Reply-To: Message from bed_gdg@edu.SHSU of 18 Jun 92 12:52:49 CDT X-Organization: Cripps Computing Centre, University of Nottingham X-Postal: University Park, Nottingham NG7 2RD, UK X-Phone: +44 (602) 484848 ext 2064 Date: Fri, 19 Jun 92 10:10:11 +0100 Message-Id: <8817.708945011@mips> From: David Osborne Reply-To: TWG@SHSU.edu In message <0095C48E.77BC0A60.1494@SHSU.edu> of 18 Jun 92 12:52:49 CDT, "George D. Greenwade" said: > Just out of curiousity, how many on this list do NOT run an Archie client > and instead use the dreaded telnet into Archie? I plead guilty with diminshed responsibility due to pressure of other work. Please give me a light sentence, m'lord. ;-) --Dave From ITeX-Mgr@SHSU.edu Fri Jun 19 03:42:45 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12976; Fri, 19 Jun 92 03:42:43 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from dir.nott.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 19 Jun 1992 04:41:39 CDT Received: from mips.nott.ac.uk by dir.nott.ac.uk with SMTP (PP) id <22419-0@dir.nott.ac.uk>; Fri, 19 Jun 1992 10:38:29 +0100 To: TWG@shsu.edu Subject: Re: Archie clients In-Reply-To: Message from bed_gdg@edu.SHSU of 18 Jun 92 15:49:47 CDT X-Organization: Cripps Computing Centre, University of Nottingham X-Postal: University Park, Nottingham NG7 2RD, UK X-Phone: +44 (602) 484848 ext 2064 Date: Fri, 19 Jun 92 10:38:30 +0100 Message-Id: <9134.708946710@mips> From: David Osborne Reply-To: TWG@SHSU.edu In message <0095C4A7.3078E6A0.2299@SHSU.edu> of 18 Jun 92 15:49:47 CDT, "George D. Greenwade" said: > If we can propogate the clients among our users by having it > available in our archives, maybe the "looking around" load can be reduced. > > Anyway, would anyone have any objection to including the sources (or maybe > the precompiled executables) for Archie clients in the archive-tools area? This sounds like a very good idea to me, assuming the archives will be indexed in the Archie databases. --Dave From ITeX-Mgr@SHSU.edu Fri Jun 19 14:20:04 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18827; Fri, 19 Jun 92 14:19:50 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 19 Jun 1992 15:14:01 CDT Received: from plot79.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18795; Fri, 19 Jun 92 14:13:55 MDT Date: Fri, 19 Jun 92 14:13:55 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: twg@shsu.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: filehdr.dvi, plus arc, zip, and zoo Message-Id: Yesterday, I updated the filehdr archives on ftp.math.utah.edu in ~ftp/pub/tex/bib (from ftp, just do "cd pub/tex/bib") to include the .dvi and .bbl files. This makes it possible to produce typeset documentation without needing to have the LaTeXinfo package installed. The latest version of the latter has been installed this morning in the directory ~ftp/pub/tex/pub/latexinfo in the compressed UNIX tar files latexinfo-1.7.tar.z and latexinfo-1.7.tar-lst. Its author reports that he is a few weeks away from completion of the next version. Via e-mail "send index from ftp/misc" and "send index from ftp/tex/bib" to tuglib@math.utah.edu. I've also updated ~ftp/pub/misc to hold implementations of arc, zip, and zoo. In the interests of greater convenience to non-UNIX sites, compressed tar files will gradually be supplemented, and perhaps eventually replaced, by .zip files. It seems to me that a larger community of developers is behind zip than zoo; both seem to offer similar features, and importantly, both compression and directory tree support. [The infozip.who file lists 46 collaborators.] Most arc versions are unable to handle directory trees, which is distinctly inconvenient for larger packages like MakeIndex. I am therefore disinclined to add new .arc files to the archives on ftp.math.utah.edu. Index files are updated nightly, so if you use tuglib for retrievals via e-mail, wait until tomorrow. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Fri Jun 19 15:40:30 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19277; Fri, 19 Jun 92 15:40:28 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 6341; Fri, 19 Jun 1992 16:29:23 CDT Date: Fri, 19 Jun 1992 16:29:06 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095C575.D8C7B560.6341@SHSU.edu> Subject: RE: filehdr.dvi, plus arc, zip, and zoo On Fri, 19 Jun 92 14:13:55 MDT, Nelson H. F. Beebe posted: > .... In the interests of greater convenience to non-UNIX sites, compressed > tar files will gradually be supplemented, and perhaps eventually replaced, > by .zip files. It seems to me that a larger community of developers is > behind zip than zoo; both seem to offer similar features, and importantly, > both compression and directory tree support. [The infozip.who file lists > 46 collaborators.] Outstanding! Maybe we'll start a semi-mini-revolution on this and move to real platform independence with compressed files emanating out of archival sites. Now, if we can just get to a single period in filenames...... 8-) I know that GNU guidelines call for the version number in filenames (which I wholly support, BTW), but do those guidelines {\em require} periods or can an "underscore-for-period" logic be used in the major part of the name (i.e., latexinfo-1_7.zip as opposed to latexinfo-1.7.zip)? If this isn't a per se requirement, I vote to move in that direction also in the name of a more portable filing scheme. The above proposal may appear trivial and the statement that this may be a revolution may look silly, but if you consider the possibility of a comprehensive and coordinated worldwide archival network which may arise out of this group, my guess is that others will follow our lead, at least to a degree. Regards and a good weekend to all, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Sat Jun 20 12:24:22 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23274; Sat, 20 Jun 92 12:24:19 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from VAX01.AMS.COM by Niord.SHSU.edu (MX V3.1B) with SMTP; Sat, 20 Jun 1992 13:23:23 CDT Received: from MATH.AMS.COM by MATH.AMS.COM (PMDF #2306 ) id <01GLFMTRED0GFBVNR0@MATH.AMS.COM>; Sat, 20 Jun 1992 14:22:54 EST Date: 20 Jun 1992 14:22:54 -0400 (EDT) From: bbeeton Reply-To: TWG@SHSU.edu Subject: Re: Directory structure as it now stands In-Reply-To: <0095C23B.ED17B2A0.22307@SHSU.edu> To: TWG@SHSU.edu Message-Id: <709064574.161860.BNB@MATH.AMS.COM> Content-Transfer-Encoding: 7BIT Mail-System-Version: i've just read the accumulated twg posts after a week away, and have a couple of comments. in his message of jun 15, george lays out a revised directory structure proposal. he cites an earlier comment by me as the idea behind having separate /tex-archive/help/errata and /bug areas. actually, i'm quite happy with the way this material is posted at labrea, with errata and bug files in the same subdirectory -- /tex/errata . in addition to (current-only versions of) tex82, mf84 and cm85.bug there is the entire collection of errata.* files (errata.tex is "current", and errata.one ... .six the earlier ones; they are not cumulative). in addition, the directory contains knuth's errorlog.tex (the cumulative list of changes, classified by type of change, published as the appendix to his paper "the errors of tex") and macros needed to tex it. this is a total of 12 files, and it won't be growing by any more than one file per year. since these files are maintained under the direction of knuth himself, i think it's worth considering this to be a "cta" source and not bothering to redistribute the contents. to put it more succinctly, i suggest just one directory in an "sta" -- /tex-archive/help/errata . i agree with whoever it was that said it -- /help is a really good name for the area that contains documentation on how to use the archive and on the system in general. it wasn't obvious, and i don't remember what was said in the earlier iteration(s) -- where are trip, trap, and any other system tests to be placed? at labrea, trip lives with tex.web and trap with mf.web, but on score (which was the canonical archive of the stanford tex project) they were in a single directory, . it's not out of the question to believe that there may in the future be test files to determine whether dvi drivers conform to the standard -- where would those go? and, for that matter, where would the text(s) of the dvi driver (and other) standard(s) go? one final question. for tugboat, and perhaps some other publications, parallel versions of style files, plain and latex, have been placed on the archives, with code common to both in a separate file. where is such a "common" file to be archived? -- bb From ITeX-Mgr@SHSU.edu Sun Jun 21 17:09:17 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26933; Sun, 21 Jun 92 17:09:15 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from FRIGGA.CLAREMONT.EDU by Niord.SHSU.edu (MX V3.1B) with SMTP; Sun, 21 Jun 1992 18:08:16 CDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GLHDAF4IK6A7347M@HMCVAX.CLAREMONT.EDU>; Sun, 21 Jun 1992 16:07 PDT Date: Sun, 21 Jun 1992 16:07 PDT From: Don Hosek Reply-To: TWG@SHSU.edu Subject: Re: Directory structure as it now stands To: TWG@SHSU.edu Message-Id: <01GLHDAF4IK6A7347M@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"TWG@SHSU.edu" -Karl Berry objects to the name msdos in the proposed archive tree, -and suggests it be reduced to dos since Microsoft is not the only -supplier. -However, dos is also used by other vendors (including IBM for an old -small mainframe system). -I always make a habit of using pcdos (or in text, PC DOS), which -is a little more generic, and personal computer oriented. Well, PC-DOS is the name used by IBM's version of MS-DOS. Personally, I think that among the net community there is an understanding that "PC" refers to all 80x86-based systems, and "DOS" and "MSDOS" are generic terms which refer to MS-DOS/PC-DOS/DR-DOS. I doubt that there's much danger that anyone would see a directory labelled DOS and assume it contains AmigaDOS software or programs for DOS/VSE. Likewise, I doubt that someone seeing a directory labelled MSDOS would assume that the software would not work with PCDOS or DRDOS. Or, for that matter, that software in a directory labelled IBM_PC would not run on a Gateway 2000. -dh From ITeX-Mgr@SHSU.edu Mon Jun 22 08:45:33 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29547; Mon, 22 Jun 92 08:45:31 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 11841; Mon, 22 Jun 1992 09:00:33 CDT Date: Mon, 22 Jun 1992 09:00:23 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095C792.A8523440.11841@SHSU.edu> Subject: RE: filehdr.dvi, plus arc, zip, and zoo On Sat, 20 Jun 92 07:33:09 EDT, Karl Berry posted: > As long as the archive (zip, tar, whatever) unpacks into latexinfo-1.7, I > don't see anything wrong with naming the archive file itself > latexinfo-1_7.zip. Thanks; I ope everyone can agree to this as this goes a long way to allowing the archives to at least share compressed archive files under the same naming structure. However, this may still be less than optimal for platform independence. On unpacking, DOS will create a directory file named LATEXINF.7 (I can live with this, the 8+3 structure is okay in this regard). On unpacking, VMS will create LATEXINFO-1.DIR with a subdirectory of 7.DIR (I just tried this to verify my suspicions). Also, while the ZIP archive can be named something such as latexinfo-1_7_a.zip to unpack to latexinfo-1.7.a, it will not unpack under either DOS or VMS (at least in the present iteration of ZIP/UNZIP; I know that the next version's enhancement is to be a more robust parsing, so maybe I'm more concerned about this than I ought to be, but......). As I have stated previously, I wholly support the notion of version inclusion in filenames; however, I even support more strongly the notion of being able to get to files by making them as parsable as possible in their native naming structure. --George From ITeX-Mgr@SHSU.edu Mon Jun 22 13:34:19 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01911; Mon, 22 Jun 92 13:34:15 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 13194; Mon, 22 Jun 1992 12:35:43 CDT Date: Mon, 22 Jun 1992 12:35:00 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: twg@SHSU.edu Message-Id: <0095C7B0.A4244660.13194@SHSU.edu> Subject: Filedates I have been playing with the mirror perl script once again and find that it has the very nice feature of not only mirroring the file in contents, but in the filedate, as well. Using Unix's touch utility (I assume Unix calls such things utilities), and looking at the script, I think I see how this is handled (although I must still admit that I haven't a clue about perl). We have a somewhat parallel utility to touch for VMS (if anyone's interested) called FILE. The sources reside in the directory [FILESERV.FILE] on Niord.SHSU.edu as FILE_SOURCES.ZIP. Alternately, you can retrieve these in 2-part VMS_SHARE format from FILESERV by including SENDME FILE in the body of a mail message to it. This brings me to a few critical questions. 1. I assume that in mirroring, a common time is desired. If so, shall the time of original deposit to an archive site (say, in the incoming directory -- which I omitted in the last outline of the directory structure) or the time of the classification into the proper directory be the one reported? 2. What is a suggested procedure for handling the case of parallel file names (such as subeqn.sty). Shall the author be notified and (s)he requested to re-name it, shall it be something unilateral by an archive maintainer, or shall holy intervention preclude such things from occurring? 3. Will one site be responsible for classifying all incoming files into a "proper" directory and filename or will each site classify the files it receives? Just wondering, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Mon Jun 22 13:55:34 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03094; Mon, 22 Jun 92 13:55:30 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Mon, 22 Jun 1992 12:47:55 CDT Via: vax.rhbnc.ac.uk; Mon, 22 Jun 1992 18:45:37 +0100 Date: Mon, 22 JUN 92 18:45:42 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: Miscellaneous Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <20209A7F_000800E0.0095C7E46C7D2720$54_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) >>> (i.e., latexinfo-1_7.zip as opposed to latexinfo-1.7.zip)? If this isn't a >>> per se requirement, I vote to move in that direction also in the name of a >>> more portable filing scheme. I have to say, I find this less than obvious. To me (and therefore, I suggest, to the average reader), `LaTeXinfo-1_7.Zip' does _not_ suggest major revision 1, minor revision 7 of LaTeXinfo.Zip at all. What it _does_ suggest is (something like) LaTeXinfo.Zip: Part 1 of 7, or perhaps LaTeXinfo-1, part 7. If we are to encode the version/revision numbers sonewhere in the LHS of the filename, may I suggest that we take the opportunity to make it transparently obvious? I would suggest, for the LaTeXinfo example cited above, `LaTeXinfo-V1_7.Zip', and extend this to generate some rules: 1) The primary separator between the LHS and RHS of a filespec shall be a period; there shall be at most one period. 2) The LHS of a filespec shall contain its name, version/revision number, and such other information as shall be necessary for an immediate appreciation of its likely contents. 3) The RHS of a filespec shall contain its (file) type; this shall normally be restricted to a maximum of three letters, but may be extended after an intervening minor component delimiter (q.v.) to indicate (for example) compression (in which case a trailing `Z' shall be appended). Other modifiers shall be adopted as evidence of their need is established. 4) Within the LHS of a filespec, there may exist major components, delimited by the major component delimiter `-' (hyphen/minus/dash); the first, leftmost, and most significant component shall be the name. Other components shall start with an initial letter or letters to indicate their semantics; for example, version numbers shall start with the letter `V'; other tags shall be adopted as evidence of their need is established. 5) Within a major component, there may exist minor components, separated by a minor component delimiter `_' (underscore/underline); where two or more minor components shall be so delimited, the leftmost shall be deemed more signficant; for example, `-V1_7' indicates major revision/ version 1, minor version/revision 7. What comments, please ? Regarding George's experiments with unpacking ZIP files: I think we have to be very careful not to posit the existence of ?GNU? ZIP/UNZIP on every system. For those that have native mode ZIP/UNZIPs (e.g. PKZIP & PKUNZIP for MS-DOS), the probability is very high that the native- mode utility will be used preferentially to the ?GNU? version. We should therefore take into account the behaviour of native mode utilities. And no-one seems to have pointed out that (a) ZIP files are not just compressed files; they are compressed _archive_ files, and may therefore unpack to many files, not just one; and (b), that even if they are used as single-file archives, the name of the archived file and the name of the archive file (read those phrases very carefully!) need bear no relationship to one another whatsoever. Philip Taylor, RHBNC From ITeX-Mgr@SHSU.edu Mon Jun 22 14:01:12 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03552; Mon, 22 Jun 92 14:01:01 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 13649; Mon, 22 Jun 1992 14:19:57 CDT Date: Mon, 22 Jun 1992 14:17:57 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095C7BF.05A702C0.13649@SHSU.edu> Subject: RE: Miscellaneous On Mon, 22 JUN 92 18:45:42 BST, Phil Taylor posted: > I have to say, I find this less than obvious. To me (and therefore, I > suggest, to the average reader), `LaTeXinfo-1_7.Zip' does _not_ suggest > major revision 1, minor revision 7 of LaTeXinfo.Zip at all. What it _does_ > suggest is (something like) LaTeXinfo.Zip: Part 1 of 7, or perhaps > LaTeXinfo-1, part 7. If we are to encode the version/revision numbers > sonewhere in the LHS of the filename, may I suggest that we take the > opportunity to make it transparently obvious? I would suggest, for the > LaTeXinfo example cited above, `LaTeXinfo-V1_7.Zip', and extend this to > generate some rules: Bless you, Phil! I was beginning to think I was somewhat if a loner on this topic (alas, though, you are also constrained by VMS standards -- hope our Unix-based colleagues will consider your proposal and provide some feedback understanding our plight). One quick comment on your proposal, though, which I have developed some doubts about (recall, I was at one time the leading--only?--proponent of 8+3): > 3) The RHS of a filespec shall contain its (file) type; this shall normally > be restricted to a maximum of three letters, but may be extended after > an intervening minor component delimiter (q.v.) to indicate (for example) > compression (in which case a trailing `Z' shall be appended). Other > modifiers shall be adopted as evidence of their need is established. I see this as somewhat limiting beyond what is necessary in an archive. For example, if you have multiple README files in a directory, say README.FILESET1 and README.FILESET2, how might you propose naming them? I have been led (by the nose through exchanges arising on tex-archive and on TWG) to agree that, whenever possible, canonically-correct names be used whenever possible in the archive naming structure. Moreover, I would hope that we could have somewhat unique filenames, wherein precisely where the file was in the first place didn't matter quite so heavily (i.e., so that a search of directory listing would lead to a relatively small number of matches in starting a physical search). Beyond this, I agree with and support the other 4 topics in whole. > Regarding George's experiments with unpacking ZIP files: I think we have to > be very careful not to posit the existence of ?GNU? ZIP/UNZIP on every > system. For those that have native mode ZIP/UNZIPs (e.g. PKZIP & PKUNZIP > for MS-DOS), the probability is very high that the native- mode utility > will be used preferentially to the ?GNU? version. We should therefore take > into account the behaviour of native mode utilities. It is not a GNU product development. Info-Zip is a somewhat loosely organized group of 46 identifiable developers, with at least 300 others involved in testing. It is based virtually entirely off a mailing list/digest named info-zip out of UCLA. While I agree with your concerns regarding native ZIP mode, I believe that if we make the archiving tool available, it may not be a standard on that particular platform, but it can be an archiving tool used consistently within our archives. Just as Eberhard distributes PKUNZIP.EXE and PKZ102.EXE with emTeX, the archive-tools subdirectory can have the sources and/or executables (possibly by platform) to get to the agreed-to standard. I am NOT attempting to supplant PK*ZIP; I am attempting to get to something which can be well-known to exist as a standard within our structure. This concern extends to Unix users who can just as easily claim, "well, tar.Z is *our* standard" and VMS users can claim, "no, use backup savesets" -- lord, what a mess! Finally, your note delineating between archive files and archived files is well taken and appreciated. I guess that my underlying concern is that the archive files can be unpacked to an archived file in a form usable on multiple platforms, which your proposal addresses relatively nicely. --George From ITeX-Mgr@SHSU.edu Tue Jun 23 01:19:51 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07343; Tue, 23 Jun 92 01:19:43 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Mon, 22 Jun 1992 17:01:53 CDT Received: from plot79.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04491; Mon, 22 Jun 92 16:01:36 MDT Date: Mon, 22 Jun 92 16:01:36 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: twg@shsu.edu Cc: beebe@math.utah.edu Subject: Comments on archive file naming X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Message-Id: Philip Taylor has just posted a specific proposal regarding the naming of archive (tar, zip, zoo, ...) files, and raises several important points. I thought it would be worthwhile to report here what the recent practice has been in the Free Software Foundation archives. The primary goal of FSF is the (still unfinished) GNU operating system, and FSF policy has been that support for their software on other operating systems is only of marginal interest, and usually discouraged, since it takes away from time better spent on the GNU project. This policy position is certainly understandable. However, the high quality of the FSF production is widely recognized, so much so that at least two computer vendors (Data General and NeXT) use the GNU C compiler (gcc) as their standard C compilers. Many in the user community also wish to have GNU utilities available on other operating systems, including particularly VAX VMS and IBM PC DOS. Both Emacs and gcc are available for VMS and PC DOS systems, and there is an Internet collaboration afoot to keep porting new GNUware to the IBM PC world. Details can be found on the huge wuarchive.wustl.edu archive (the directory listing alone is over 7MB!). Because the FSF archives often contain multiple released versions of software, it is critical that it be possible for remote users to distinguish between versions. As a small example, today the FSF master archive on prep.ai.mit.edu in ~ftp/pub (from anonymous ftp, do "cd pub") contains: -rw-r--r-- 1 14910 6292 Feb 14 13:54 texinfo-2.14.README -rw-r--r-- 1 14910 465509 Feb 14 13:55 texinfo-2.14.tar.Z -rw-r--r-- 1 14910 7007 Jun 12 14:10 texinfo-2.15.README -rw-r--r-- 1 14910 497375 Jun 12 14:09 texinfo-2.15.tar.Z In general, program archives are named "program-major.minor.tar.Z". When tar unbundles this archive, it is puts everything into a directory subtree named "program-major.minor", e.g. rwxrwxr-x5170/11 0 Jun 12 12:55 1992 texinfo-2.15/ rwxrwxr-x5170/11 0 Jun 12 12:55 1992 texinfo-2.15/elisp/ rw-rw-rw-5170/11 25985 Jan 16 21:59 1992 texinfo-2.15/elisp/texinfo.el rw-rw-rw-5170/11 71007 Jun 11 21:39 1992 texinfo-2.15/elisp/texnfo-upd.el .... rwxrwxr-x5170/11 0 Jun 12 12:55 1992 texinfo-2.15/C/ rw-r--r--5082/1 176595 Jun 7 21:31 1992 texinfo-2.15/C/makeinfo.c .... rw-rw-rw-5170/11 7007 Jun 12 12:45 1992 texinfo-2.15/README rw-rw-rw-5170/11 17982 Jun 2 14:03 1991 texinfo-2.15/COPYING ... There are two good reasons for having the directory name prefixing EVERY file name in an archive file: (1) If the software is unbundled in a directory that is not empty, the likelihood of clobbering existing files is minimized (unlike zip, and possibly zoo, UNIX tar does not normally ask if it should overwrite an existing file, unless requested to do so by a seldom-used command-line option). (2) Once the software is unbundled and the archive file discarded, the directory name left behind contains the program version number. In some programs, this may be the ONLY way of subsequently discovering what the version is. [Many GNU programs support a command line option to provide exactly that information, and I follow that practice in all of my own software.] With this background understood, there are two obvious problems with this scheme for non-UNIX systems: (a) periods (and possibly other punctuation characters) in directory names; (b) file and directory names longer than the PC DOS limit of 8+3 characters. Both of these conflict with the reasons (1) and (2) above. Problem (a) can be circumvented by replacing the periods with other characters. I routinely did so on the DEC-20, where I used a hyphen instead of a period. This is marginally more portable than underscore in filenames, and on most keyboards, easier to type. However, if major and minor version numbers are so encoded, then limitation (b) is usually reached. It therefore seems advisable to consider the following alternative naming convention for TeXware archives: (1) Encode the version numbers with hyphens (or perhaps underscores) in the archive file, not worrying about limitation (b), on the grounds that all (I've never seen an exception on dozens of operating systems) ftp implementations make it possible to rename a file fetched from a remote system (this is a necessity, given the varying naming conventions). Thus, we would call the sample files above texinfo-2-25.tar.Z. On non-UNIX systems with adequate file name lengths, this might be renamed to texinfo-2-25.tar-z, or texinfo-2-25.tarz, or texinfo-2-25.trz (I've used all of these in the past). (2) In the archive file itself, recognize that other operating systems have severe name length and character set restrictions, and avoid creating files that have names that would conflict. This is particularly important for directory names, for which tools like zip and zoo might be unable to handle non-native spellings. Thus, I propose that the above example would be revised to unbundle into the directory subtree texinfo/v2-14/ instead of texinfo-2.14 The leading v in v2-14 of course means `version', and is present because I'm told that at least one O/S balks at a leading digit in a file name. As long as the 8-char name length limit (b) is adhered to, such names should not cause problems on any current operating system that supports a true hierarchical file system (I do NOT consider old IBM CMS minidisks to form such a system). ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Tue Jun 23 01:20:54 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07350; Tue, 23 Jun 92 01:20:45 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 14045; Mon, 22 Jun 1992 17:12:51 CDT Date: Mon, 22 Jun 1992 17:12:47 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: twg@SHSU.edu Message-Id: <0095C7D7.724AF9A0.14045@SHSU.edu> Subject: Yet another iteration on directory structure I have created a prototype tex-archive directory on Niord.SHSU.edu (192.92.115.8) just so I could look at it as a directory structure, as opposed to a listing. Presently, it is partially (largely?) incomplete, with no files of consequence in it -- it is merely a skeleton of a directory structure. This is already a relatively large file (around 180 lines), so I will not attach it all. You can retrieve the directory structure, in whole, by getting the file [FILESERV.TWG]TWG.TEX-ARCHIVE-DIRECTORIES either by anonymous ftp or via a SENDME TWG.TEX-ARCHIVE-DIRECTORIES in the body of a mail message to FILESERV. If you are interested, you can ftp to Niord, cd to [FILESERV.TWG.TEX-ARCHIVE] and see what is there (it gives an entirely different feel to actually see it in place!). I still need a little guidance on how to best set up the fonts area. I have expanded the bibliography area, split drivers into viewers and printers (maybe need to add ``manipulation'' for DVIDVI instead of printers, where I have them now?), put an ``errata'' area in help as a single directory, assumed that the base web for TeX and MF will be in their respective areas (instead of ``web-sources'' now named ``web'') and included a ``standards'' area in web for trip/trap, other standard tests, and text of standards. A brief (yes, this is ``brief''!) listing of the major areas follows; note that no text files are included. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% In brief (from [FILESERV.TWG.TWG.TEX-ARCHIVE-DIRECTORIES): MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]ARCHIVE-TOOLS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.ARCHIVE-TOOLS]ARCHIE.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.ARCHIVE-TOOLS]CHECKSUM.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.ARCHIVE-TOOLS]COMPRESSION.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.ARCHIVE-TOOLS]ENCODING.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.ARCHIVE-TOOLS]FILEHDR.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]BIBLIOGRAPHY.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BIBLIOGRAPHY]BIBTEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BIBLIOGRAPHY.BIBTEX]BASE.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BIBLIOGRAPHY.BIBTEX]BIBCARD.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BIBLIOGRAPHY.BIBTEX]BIBTEST.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BIBLIOGRAPHY.BIBTEX]BST.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BIBLIOGRAPHY.BIBTEX.BST]SUPPORTED.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BIBLIOGRAPHY.BIBTEX.BST]UNSUPPORTED.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BIBLIOGRAPHY.BIBTEX]MACBIBTEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BIBLIOGRAPHY]REF2BIB.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BIBLIOGRAPHY]TIB.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BIBLIOGRAPHY]TOOLS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]BOOKS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BOOKS]METAFONTBOOK.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BOOKS]TBEFILES.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.BOOKS]TEXBOOK.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]CONVERSION.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]DRIVERS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.DRIVERS]PRINTERS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.DRIVERS]VIEWERS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]FONTS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.FONTS]AMSFONTS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.FONTS]MF.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.FONTS]UTILITIES.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]GRAPHICS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.GRAPHICS]EEPIC.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.GRAPHICS]EPIC.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.GRAPHICS]PICTEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.GRAPHICS]PSFIG.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.GRAPHICS]XYPIC.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]HELP.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.HELP]ERRATA.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.HELP]RESOURCES.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]INCOMING.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]INDEXING.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.INDEXING]IDXTEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.INDEXING]INDEXOR.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.INDEXING]MACMAKEINDEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.INDEXING]MAKEINDEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.INDEXING]TEXINDEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.INDEXING]TEXINDEX2.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.INDEXING]TEXIX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]LANGUAGES.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.LANGUAGES]BABEL.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.LANGUAGES]HYPHENATION.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]MACROS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS]AMS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS.AMS]AMSLATEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS.AMS]AMSTEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS]EPLAIN.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS]LAMSTEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS]LATEX-STYLE.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS.LATEX-STYLE]BASE.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS.LATEX-STYLE]SUPPORTED.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS.LATEX-STYLE]UNSUPPORTED.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS]MUSIC.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS.MUSIC]MTEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS.MUSIC]MUSICTEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS]PLAIN.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS.PLAIN]BASE.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS.PLAIN]SUPPORTED.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS.PLAIN]UNSUPPORTED.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS]REVTEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.MACROS]TEXT1.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]PERIODICALS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.PERIODICALS]CTT.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.PERIODICALS]TEXHAX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.PERIODICALS]TEXMAG.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.PERIODICALS]TTN.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.PERIODICALS]TUGBOAT.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.PERIODICALS]UKTEX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]SYSTEMS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.SYSTEMS]AMIGA.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.SYSTEMS]ATARI.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.SYSTEMS]MAC.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.SYSTEMS]MSDOS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.SYSTEMS]UNIX.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.SYSTEMS]VAX-VMS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]TUTORIALS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.TUTORIALS]ESSENTIAL.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.TUTORIALS]GENTLE.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]USERS-GROUPS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.USERS-GROUPS]DANTE.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.USERS-GROUPS]DEVELOPERS.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.USERS-GROUPS]TUG.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE]WEB.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.WEB]CWEB.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.WEB]SPIDERWEB.DIR;1 MX_ROOT:[FILESERV.TWG.TEX-ARCHIVE.WEB]STANDARDS.DIR;1 From ITeX-Mgr@SHSU.edu Tue Jun 23 13:02:58 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11294; Tue, 23 Jun 92 13:02:52 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 23 Jun 1992 14:00:01 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA08280; Tue, 23 Jun 1992 14:59:45 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA00452; Tue, 23 Jun 92 14:59:41 EDT Date: Tue, 23 Jun 92 14:59:41 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9206231859.AA00452@claude.cs.umb.edu> To: TWG@SHSU.edu In-Reply-To: "George D. Greenwade"'s message of Mon, 22 Jun 1992 12:35:00 CDT <0095C7B0.A4244660.13194@SHSU.edu> Subject: Filedates Reply-To: TWG@SHSU.edu 3. Will one site be responsible for classifying all incoming files into a "proper" directory and filename I don't see how this could work. or will each site classify the files it receives? That's what I was thinking all along. The author of the package could also be involved. From ITeX-Mgr@SHSU.edu Tue Jun 23 13:05:55 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11309; Tue, 23 Jun 92 13:05:48 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 23 Jun 1992 13:56:33 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA08217; Tue, 23 Jun 1992 14:56:16 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA00434; Tue, 23 Jun 92 14:56:14 EDT Date: Tue, 23 Jun 92 14:56:14 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9206231856.AA00434@claude.cs.umb.edu> To: TWG@SHSU.edu Cc: twg@SHSU.edu In-Reply-To: "George D. Greenwade"'s message of Mon, 22 Jun 1992 12:35:00 CDT <0095C7B0.A4244660.13194@SHSU.edu> Subject: Filedates Reply-To: TWG@SHSU.edu 1. I assume that in mirroring, a common time is desired. Yes, absolutely! I've never understood by ftp doesn't preserve dates. If so, shall the time of original deposit to an archive site (say, in the incoming directory -- which I omitted in the last outline of the directory structure) or the time of the classification into the proper directory be the one reported? I don't think it should be either the deposit-time or classification-time, but rather the time the file has in the original archive where the author put it. From ITeX-Mgr@SHSU.edu Tue Jun 23 13:17:02 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11384; Tue, 23 Jun 92 13:16:53 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 23 Jun 1992 13:59:12 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA08259; Tue, 23 Jun 1992 14:58:54 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA00442; Tue, 23 Jun 92 14:58:52 EDT Date: Tue, 23 Jun 92 14:58:52 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9206231858.AA00442@claude.cs.umb.edu> To: TWG@SHSU.edu In-Reply-To: "George D. Greenwade"'s message of Mon, 22 Jun 1992 12:35:00 CDT <0095C7B0.A4244660.13194@SHSU.edu> Subject: parallel filenames Reply-To: TWG@SHSU.edu What is a suggested procedure for handling the case of parallel file names (such as subeqn.sty) I assume you mean there's two different files, both named subeqn.sty? Shall the author be notified and (s)he requested to re-name it That sounds good to me. (But there are two authors involved.) shall it be something unilateral by an archive maintainer I think definitely not. Then the distribution at the archive site would be different than the distribution at the original site. Ugh. holy intervention preclude such things from occurring? For example, refusing to admit two files by the same name? Seems rather high-handed to me. From ITeX-Mgr@SHSU.edu Tue Jun 23 16:00:25 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12893; Tue, 23 Jun 92 15:59:56 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 23 Jun 1992 14:56:35 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA08985; Tue, 23 Jun 1992 15:56:09 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA00585; Tue, 23 Jun 92 15:56:08 EDT Date: Tue, 23 Jun 92 15:56:08 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9206231956.AA00585@claude.cs.umb.edu> To: TWG@SHSU.edu In-Reply-To: Nelson H. F. Beebe's message of Mon, 22 Jun 92 16:01:36 MDT Subject: archive file unpacking Reply-To: TWG@SHSU.edu propose that the above example would be revised to unbundle into the directory subtree texinfo/v2-14/ instead of texinfo-2.14 This seems a good suggestion. (Well, not really, I hate this suggestion, but I have no alternative!) From ITeX-Mgr@SHSU.edu Tue Jun 23 16:04:46 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12977; Tue, 23 Jun 92 16:04:41 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 23 Jun 1992 15:47:18 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA09663; Tue, 23 Jun 1992 16:47:06 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA00666; Tue, 23 Jun 92 16:47:05 EDT Date: Tue, 23 Jun 92 16:47:05 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9206232047.AA00666@claude.cs.umb.edu> To: TWG@SHSU.edu In-Reply-To: "George D. Greenwade"'s message of Mon, 22 Jun 1992 17:12:47 CDT <0095C7D7.724AF9A0.14045@SHSU.edu> Subject: directory names and version numbers Reply-To: TWG@SHSU.edu If at all possible, I hope every source directory in the archive has a version number with it, i.e., that the directory `latexinfo', say, is a link (another name for -- do all the archive machines' systems have this concept?) to `latexinfo-v1-3', say. That way, people know what we're getting. Apologies if this is what everyone has been saying all along anyway. K From beebe Tue Jun 23 19:31:11 1992 Flags: 000000000001 Return-Path: Received: from plot79.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13978; Tue, 23 Jun 92 19:30:58 MDT Date: Tue, 23 Jun 92 19:30:58 MDT From: Nelson H. F. Beebe To: twg@shsu.edu Cc: beebe, rodgers, debar, staff X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Literature refs on CD ROM Message-Id: A week ago, there was some discussion on this list about CD ROM formats, capacities, and O/S independence. Some very recent literature references that may be useful are given below, together with some comments, and selected quotations. OPTICAL STORAGE Ref. [1] discusses the relative merits of WORM (write-once, read mostly) vs CD ROM (read-only memory) optical storage, and includes a siebar on the RRIP format (see remarks on [4] below). Ref. [2] is 9-page table of vendor information. Ref. [3] makes these interesting remarks: ``Each of these (CD ROMs) holds 660Mbytes. ... CD ROMs in quantity can cost less than US$1.50 each to manufacture. Prices for basic CD-ROM readers have plummeted to as little as US$200 retail. ... Access times just a year or so ago were often 800 ms; the fastest drives today do better than 300 ms.'' Ref. [4] says: ``You can make a thousand CD ROMs for around US$3000, plus or minus discounts, packaging, etc.. Cartridge tapes cost nearly 10 times as much to produce. ... A hundred CD ROMs should cost less than US$2000 to produce. ... Andrew Young, president of Young Minds [one of the organizations that produce CD ROMs of public-domain software], contends that the current crossover point is under 50 units, and dropping. ... The current standard for CD ROM file systems is ISO-9660. Based on a de facto standard known as ``High Sierra'', ISO-9660 is capable, efficient, and widely available. If your users can live with MS-DOS file naming and semantics, ISO-9660 is a perfectly reasonable choice. Most UNIX software distributors, however, find ISO-9660 to be overly restrictive. The file names are bad enough: eight characters or less, no case sensitivity, only one special character (_). Add the limit on directory levels (eight), and the lack of modes, symbolic links, and other UNIXisms, and the situation gets unacceptable in a big hurry. ... Fortunately, a solution is nearly at hand. The Rock Ridge Interface Protocol (RRIP) is upwardly compatible with ISO-9660, but provides full (read-only) UNIX file-system semantics. The gotcha is that only one UNIX vendor seems to have RRIP support in place. NeXT has announced it for the 3.0 OS release. Several other vendors have it in the pipeline. Only Sun has it now, however.'' As I write these words, I'm installing software on a Sun SPARCstation 2 with a RRIP CD ROM on my desk; the system was just installed this afternoon. Tomorrow morning, I'm bringing in an audio CD and headphones to try it out on music. REFERENCES [1] Michael Jay Tucker, ``The Fabulous Closet of Fibber McGee'', SunExpert Magazine, pp. 52--62, June 1992. [2] Maureen McKeon, ``Optical Disk Drives'', SunExpert Magazine, pp. 63--71, June 1992. [3] David Fiedler, ``CD ROM: The Belle of the Ball'', Open Systems Today, pp. 44, 50, June 8, 1992 [4] Richard Morin, ``CD or Not CD, and Other Questions'', SunExpert Magazine, pp. 38, 40--41, June 1992. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Tue Jun 9 10:37:36 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04233; Tue, 9 Jun 92 10:37:33 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 09 Jun 1992 11:09:14 CDT Via: vax.rhbnc.ac.uk; Tue, 9 Jun 1992 16:40:16 +0100 Date: Tue, 9 JUN 92 16:39:53 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: RE: Standardised directory structure / filenames Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <21A0225E_001649E0.0095BD9BB13F8B80$30_2@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) [Space requirements of `reverse-sorted-by-date' vs. `last-$n$-days'] I can see your point. But for the user who has been away on Sabbatical, and wants to know `what's new since I went away', is ideal, if large. I would happily compromise with both! ** P. From ITeX-Mgr@SHSU.edu Tue Jun 9 10:37:37 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04234; Tue, 9 Jun 92 10:37:34 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 09 Jun 1992 11:09:59 CDT Via: vax.rhbnc.ac.uk; Tue, 9 Jun 1992 17:04:10 +0100 Date: Tue, 9 JUN 92 16:53:54 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: Re: Standardised directory structure / filenames Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <21A0225E_00164DF0.0095BD9DA6A90E60$30_3@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) [Version numbers with length proportional to magnitude]. I take Barbara's point... I withdraw my own proposal. There is also an objection that, if the (VMS) archive is partially maintained by other than the (TeX) archiver, the VMS version numbers could change unintentionally. Perhaps better to ignore them. ** Phil. From ITeX-Mgr@SHSU.edu Tue Jun 9 10:49:20 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04344; Tue, 9 Jun 92 10:49:18 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from MATH.AMS.COM by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 09 Jun 1992 11:43:52 CDT Received: from MATH.AMS.COM by MATH.AMS.COM (PMDF #041B2) id <01GL0ENDN70WEO5KSJ@MATH.AMS.COM>; Tue, 9 Jun 1992 12:43:15 EST Date: 09 Jun 1992 12:43:12 -0400 (EDT) From: bbeeton Reply-To: TWG@SHSU.edu Subject: Re: Nelson's macro markup schema In-Reply-To: <21A0225E_00164558.0095BD9B21E4A1A0$30_1@UK.AC.RHBNC.VAX> To: TWG@SHSU.edu Message-Id: <708108192.562696.BNB@MATH.AMS.COM> Content-Transfer-Encoding: 7BIT Mail-System-Version: some relatively minor comments to follow up on phil's suggestions. i think the arrangement here is somewhat more logical than the one illustrated by melson's header schema. however, unless i am much mistaken, the order of elements within a bibtex entry is immaterial, and the actual arrangement is usually by convention (or sheer laziness). so the only issue here is whether it becomes necessary to change hundreds of existing ones. i do think, as phil says, that some additional information is useful; in particular, assumptions (e.g. is nfss or pictex required?), compatability as a separately-identifiable element, and identification of the header schema itself, so that information can be extracted by automated means. i think i didn't make clear to phil the reason for the extra punctuation and delimiters -- to simplify parsing. i think it's not impossible to envision a situation in which some of the suggested tags occur in the descriptive text of a header, even to being followed by a colon. i suppose that can be overcome by requiring that the tags be fixed in position and order. however, i find the notion of positional inflexibility as onerous as phil finds extra punctuation. (although i use emacs, we haven't yet got the emacs routine installed, and i simply use a template that i created for that purpose, so it's not impossible.) has anyone actually created a .bst file that will do something with the present headers (as defined by nelson)? if so, i'd like to hear about the experience. at ams, we adopted nelson's headers rather than concocting our own on the theory that any attempt at uniformity is better than chaos. but if there are improvements possible, i think they ought to be considered. -- bb From beebe Tue Jun 16 16:59:07 1992 Flags: 000000000001 Return-Path: Received: from plot79.math.utah.edu.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23864; Tue, 16 Jun 92 16:58:53 MDT Date: Tue, 16 Jun 92 16:58:53 MDT From: Nelson H. F. Beebe To: TWG@SHSU.edu Cc: beebe X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Re: Directory structure as it now stands In-Reply-To: Your message of Tue, 16 Jun 92 17:49:51 EDT Message-Id: Karl Berry objects to the name msdos in the proposed archive tree, and suggests it be reduced to dos since Microsoft is not the only supplier. However, dos is also used by other vendors (including IBM for an old small mainframe system). I always make a habit of using pcdos (or in text, PC DOS), which is a little more generic, and personal computer oriented. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From beebe Wed Jun 17 09:25:01 1992 Flags: 000000000001 Return-Path: Received: from plot79.math.utah.edu.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28207; Wed, 17 Jun 92 09:24:26 MDT Date: Wed, 17 Jun 92 09:24:26 MDT From: Nelson H. F. Beebe To: TWG@SHSU.edu Cc: beebe X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 In-Reply-To: Your message of Wed, 17 JUN 92 11:25:44 BST Subject: File header documentation and checksum program Message-Id: Philip Taylor writes: >> ... >> I can see the benefit of a checksum, but am not sure of the implementation >> details. Does the checksum include the header? If so, does it include >> its own record in the header? Does it include the leading per-cents in >> the header? If it includes none of these, isn't a great deal of integrity- >> checking lost? How do the leading per-cents fit into the proposal that >> the markup scheme is appropriate for all text files, not just TeX ones? >> ... The manual page for checksum provides a positive answer to these questions; it is appended below. The question about leading percents vs TeX files is answered by observing that the file headers are hidden inside whatever comment syntax the file's language provides. To make them distinctive, the comment-start symbol is duplicated or triplicated. Further details can be found in the complete typeset description of the file header package, available on ftp.math.utah.edu in ~ftp/pub/tex/bib in these files: -rw-r--r-- 1 beebe 621 Jun 3 14:15 filehdr-1.19.tar-lst -rw-r--r-- 1 beebe 86073 Jun 3 14:15 filehdr-1.19.tar.z -rw-r--r-- 1 beebe 74681 Jun 3 14:14 filehdr-1.19.zip -rw-r--r-- 1 beebe 836 Jun 3 14:14 filehdr-1.19.zip-lst -rw-r--r-- 1 beebe 101231 Jun 3 14:13 filehdr-1.19.zoo -rw-r--r-- 1 beebe 649 Jun 3 14:15 filehdr-1.19.zoo-lst -rw-r--r-- 1 beebe 57976 May 29 10:27 filehdr.el Via e-mail, send a message with the text send filehdr-1.19.zip from ftp/tex/bib to tuglib@math.utah.edu. The tar, zip, and zoo files contain the same information: namely, the complete LaTeX documentation, Makefile, Emacs info file, and GNU Emacs Lisp code. The Lisp code is also available separately in filehdr.el. I hope readers of this list will look at the filehdr document to see the generality behind these file headers. Here is the checksum manual page subsection: >> ... >> DESCRIPTION >> checksum will search for the first line of its input which >> contains the word checksum in lowercase and no other alpha- >> betic characters. We refer to this line as the ``critical >> line'' of the file. If the critical line contains no quota- >> tion marks, then the output file created is a copy of the >> input file, except that the critical line is replaced by a >> line where the word checksum is replaced by Here, lc is the >> number of lines in the output file, written in decimal. >> Similarly, wc is the word count of the output file, and cc >> is the character count when the end of line character is >> taken to be the single character ASCII newline (octal 012). >> >> For many text files, it is possible to hide the ``critical >> line'' in a comment near the beginning of the file. >> >> It is difficult to arrange that a file contains its own >> checksum. Instead, the field xxxxx contains the checksum, >> written in decimal in a five-digit field (with possible >> leading 0's) of the file obtained from the output file by >> replacing the field containing the checksum by the string >> >> ZZZZZ. >> >> If the critical line already contains after the word >> ``checksum'' precisely two quotation marks, and the first is >> the last character of the four-character string ,"" " = ", >> then the material between the two quotation marks will be >> deleted and replaced by a checksum and three counts as >> described above. >> >> While the counts of words, characters, and lines could be >> obtained by the UNIX wc(1) utility, that information is >> still not sufficient to detect character substitutions, or >> transpositions of characters, lines, and words. The CRC-16 >> checksum remedies that, since the resulting checksum depends >> on the order and value of every single byte in the file. >> >> checksum is intended to support the reliable exchange of >> text files between different computers, even ones with dif- >> ferent operating systems. Thus, the newline character >> sequence that terminates each line is treated as if it were >> an ASCII newline (linefeed) character, even though it may be >> a carriage return, a carriage return and a line feed, or >> simply an end-of-record condition in the file, depending on >> the operating system and file type. The file checksum is >> therefore independent of the particular representation of >> end-of-line. >> >> Although UNIX systems have a file checksum utility, sum(1), >> the result it produces differs between UNIX variants, and in >> any event, it is neither publicly available for porting to >> other systems, nor independent of the end-of-line represen- >> tation. checksum is freely available. >> ... ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From beebe Thu Jun 18 12:45:10 1992 Flags: 000000000001 Return-Path: Received: from plot79.math.utah.edu.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07802; Thu, 18 Jun 92 12:44:27 MDT Date: Thu, 18 Jun 92 12:44:27 MDT From: Nelson H. F. Beebe To: Philip Taylor (RHBNC) , twg@shsu.edu Cc: beebe X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Re: For reference: recent message to TWG In-Reply-To: Your message of Thu, 18 JUN 92 15:05:36 BST Message-Id: Phil Taylor spotted a problem in the checksum manual page extract in yesterday's mail message from me; I've traced it to a bug in Sun's nroff which does not behave as both the original AT&T and Sun nroff/troff documentation specify with respect to handling of quotes. Here is the garbled first paragraph again, but from an ULTRIX system, which sets it correctly >> ... >> DESCRIPTION >> checksum will search for the first line of its input which contains the >> word checksum in lowercase and no other alphabetic characters. We refer >> to this line as the ``critical line'' of the file. If the critical line >> contains no quotation marks, then the output file created is a copy of >> the input file, except that the critical line is replaced by a line >> where the word checksum is replaced by checksum = "xxxxx lc wc cc". >> Here, lc is the number of lines in the output file, written in decimal. >> Similarly, wc is the word count of the output file, and cc is the char- >> acter count when the end of line character is taken to be the single >> character ASCII newline (octal 012). >> ... Later on, it says: >> ... >> If the critical line already contains after the word ``checksum'' pre- >> cisely two quotation marks, and the first is the last character of the >> four-character string " = ", then the material between the two quotation >> marks will be deleted and replaced by a checksum and three counts as >> ... This contains a transcription error from the TeX code in the original cweb source, which says >> ... >> >> four-character string |" = \""|, >> ... The string that is meant is . Consulting the cweb code uncovers the two lines if (s[j] != '"') {j++; continue;} if( (s[j-1] == ' ') && (s[j-2] == '=') && (s[j-3] == ' ')) which do precisely that check. I'll modify the checksum manual page to clarify this. Phil, thanks very much for your sharp eyes and persistence! Phil goes on to ask >> ... >> >>> Further details can be found in the complete typeset description of >> >>> the file header package, available on ftp.math.utah.edu in >> >>> ~ftp/pub/tex/bib in these files: >> >> !ftp> cd ~ftp/pub/tex/bib >> !550 Unknown user name after ~ >> !ftp> cd ftp/pub/tex/bib >> !550 ftp/pub/tex/bib: No such file or directory. >> !ftp> quit >> ... There is a bit of UNIXese in my description. Under UNIX with the Berkeley C shell or AT&T Korn shell (UNIX shell == DEC VMS DCL interpreter == DEC TOPS-20 EXEC == IBM PC DOS COMMAND.COM == command interpreter), ~/foo represents the subdirectory foo of the current user, and ~username/foo the subdirectory foo under the home directory of the indicated username. Thus ~ftp/pub means the subdirectory pub of the user named ftp. This is the correct path specification for a local user, and is in wide use on the UNIX part of the Internet. The reason for the ~ (tilde) abbreviation is to avoid the need to know the absolute path to the login directory, which varies from system to system; on ours, it is /home/csc-sun/someletter, where someletter is currently a, b, c, or d. However, when you do anonymous ftp to a UNIX host, you are talking to the ftp server, not the C or Korn shell. In the interests of security, anonymous ftp issues a chroot (change root) system call to make its login directory the root of the file system that is visible >From anonymous ftp. Thus ~ftp becomes equivalent to / (the filesystem root), and what you need to do is "cd pub/tex/bib", since at the login point, you are in the parent directory of pub. If you subsequently do a pwd (print working directory), or whatever your ftp implementation provides for that purpose, it will respond with ftp> pwd 257 "/pub/tex/bib" is current directory. Notice the /, arising from the chroot system call. The reason I don't write this file name as /pub/tex/bib is that it would be incorrect on any of our 80 local machines; on those, that directory must be referred to as ~ftp/pub/tex/bib. In the future, I'll try to make things clearer by writing, ``With anonymous ftp, do "cd pub/tex/bib", ...''. Thanks again for pointing out the confusion! ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Thu Jun 18 12:51:15 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07866; Thu, 18 Jun 92 12:51:12 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 1494; Thu, 18 Jun 1992 12:52:56 CDT Date: Thu, 18 Jun 1992 12:52:49 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095C48E.77BC0A60.1494@SHSU.edu> Subject: RE: File header documentation and checksum program On Thu, 18 JUN 92 17:44:26 BST, Phil Taylor posted: > David: Many thanks for your clarification. Now if I can just locate > "LaTeXinfo.Sty", which "filehdr.ltx" references, I shall be away... > (unless, of course, "LaTeXinfo.Sty" references something even more arcane > :-{) LaTeXinfo is, at least as I understand it, a LaTeX interface for TeXinfo, which is what the documentation for the GNU utilities is prepared in. The entire package is available on ee.utah.edu (128.110.8.42) in the anonymous ftp directory /emacs/HP-new/LaTeXinfo. If you'll wait a few minutes, I will put the latexinfo.sty style file on FILESERV (SENDME STY.LATEXINFO in about 15 minutes will get it, or ftp to the [.STY] directory on Niord.SHSU.edu). Also, I will zip up the contents and place it in the directory [.LATEXINFO] on Niord. Maybe I'll even UUENCODE the zip file, then split it into 80-block pieces for FILESERV access (I *really* am trying to avoid grading the stat exam I just got out of). Just out of curiousity, how many on this list do NOT run an Archie client and instead use the dreaded telnet into Archie? --George From beebe Fri Jun 19 14:14:09 1992 Flags: 000000000001 Return-Path: Received: from plot79.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18795; Fri, 19 Jun 92 14:13:55 MDT Date: Fri, 19 Jun 92 14:13:55 MDT From: Nelson H. F. Beebe To: twg@shsu.edu Cc: beebe X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: filehdr.dvi, plus arc, zip, and zoo Message-Id: Yesterday, I updated the filehdr archives on ftp.math.utah.edu in ~ftp/pub/tex/bib (from ftp, just do "cd pub/tex/bib") to include the .dvi and .bbl files. This makes it possible to produce typeset documentation without needing to have the LaTeXinfo package installed. The latest version of the latter has been installed this morning in the directory ~ftp/pub/tex/pub/latexinfo in the compressed UNIX tar files latexinfo-1.7.tar.z and latexinfo-1.7.tar-lst. Its author reports that he is a few weeks away from completion of the next version. Via e-mail "send index from ftp/misc" and "send index from ftp/tex/bib" to tuglib@math.utah.edu. I've also updated ~ftp/pub/misc to hold implementations of arc, zip, and zoo. In the interests of greater convenience to non-UNIX sites, compressed tar files will gradually be supplemented, and perhaps eventually replaced, by .zip files. It seems to me that a larger community of developers is behind zip than zoo; both seem to offer similar features, and importantly, both compression and directory tree support. [The infozip.who file lists 46 collaborators.] Most arc versions are unable to handle directory trees, which is distinctly inconvenient for larger packages like MakeIndex. I am therefore disinclined to add new .arc files to the archives on ftp.math.utah.edu. Index files are updated nightly, so if you use tuglib for retrievals via e-mail, wait until tomorrow. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Sat Jun 20 05:33:53 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22229; Sat, 20 Jun 92 05:33:51 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Sat, 20 Jun 1992 06:33:13 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA02197; Sat, 20 Jun 1992 07:33:10 -0400 Received: by claude.cs.umb.edu (4.1/1.34) id AA21866; Sat, 20 Jun 92 07:33:09 EDT Date: Sat, 20 Jun 92 07:33:09 EDT From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <9206201133.AA21866@claude.cs.umb.edu> To: TWG@SHSU.edu Subject: RE: filehdr.dvi, plus arc, zip, and zoo As long as the archive (zip, tar, whatever) unpacks into latexinfo-1.7, I don't see anything wrong with naming the archive file itself latexinfo-1_7.zip. From beebe Mon Jun 22 16:02:00 1992 Flags: 000000000001 Return-Path: Received: from plot79.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04491; Mon, 22 Jun 92 16:01:36 MDT Date: Mon, 22 Jun 92 16:01:36 MDT From: Nelson H. F. Beebe To: twg@shsu.edu Cc: beebe Subject: Comments on archive file naming X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Message-Id: Philip Taylor has just posted a specific proposal regarding the naming of archive (tar, zip, zoo, ...) files, and raises several important points. I thought it would be worthwhile to report here what the recent practice has been in the Free Software Foundation archives. The primary goal of FSF is the (still unfinished) GNU operating system, and FSF policy has been that support for their software on other operating systems is only of marginal interest, and usually discouraged, since it takes away from time better spent on the GNU project. This policy position is certainly understandable. However, the high quality of the FSF production is widely recognized, so much so that at least two computer vendors (Data General and NeXT) use the GNU C compiler (gcc) as their standard C compilers. Many in the user community also wish to have GNU utilities available on other operating systems, including particularly VAX VMS and IBM PC DOS. Both Emacs and gcc are available for VMS and PC DOS systems, and there is an Internet collaboration afoot to keep porting new GNUware to the IBM PC world. Details can be found on the huge wuarchive.wustl.edu archive (the directory listing alone is over 7MB!). Because the FSF archives often contain multiple released versions of software, it is critical that it be possible for remote users to distinguish between versions. As a small example, today the FSF master archive on prep.ai.mit.edu in ~ftp/pub (from anonymous ftp, do "cd pub") contains: -rw-r--r-- 1 14910 6292 Feb 14 13:54 texinfo-2.14.README -rw-r--r-- 1 14910 465509 Feb 14 13:55 texinfo-2.14.tar.Z -rw-r--r-- 1 14910 7007 Jun 12 14:10 texinfo-2.15.README -rw-r--r-- 1 14910 497375 Jun 12 14:09 texinfo-2.15.tar.Z In general, program archives are named "program-major.minor.tar.Z". When tar unbundles this archive, it is puts everything into a directory subtree named "program-major.minor", e.g. rwxrwxr-x5170/11 0 Jun 12 12:55 1992 texinfo-2.15/ rwxrwxr-x5170/11 0 Jun 12 12:55 1992 texinfo-2.15/elisp/ rw-rw-rw-5170/11 25985 Jan 16 21:59 1992 texinfo-2.15/elisp/texinfo.el rw-rw-rw-5170/11 71007 Jun 11 21:39 1992 texinfo-2.15/elisp/texnfo-upd.el .... rwxrwxr-x5170/11 0 Jun 12 12:55 1992 texinfo-2.15/C/ rw-r--r--5082/1 176595 Jun 7 21:31 1992 texinfo-2.15/C/makeinfo.c .... rw-rw-rw-5170/11 7007 Jun 12 12:45 1992 texinfo-2.15/README rw-rw-rw-5170/11 17982 Jun 2 14:03 1991 texinfo-2.15/COPYING ... There are two good reasons for having the directory name prefixing EVERY file name in an archive file: (1) If the software is unbundled in a directory that is not empty, the likelihood of clobbering existing files is minimized (unlike zip, and possibly zoo, UNIX tar does not normally ask if it should overwrite an existing file, unless requested to do so by a seldom-used command-line option). (2) Once the software is unbundled and the archive file discarded, the directory name left behind contains the program version number. In some programs, this may be the ONLY way of subsequently discovering what the version is. [Many GNU programs support a command line option to provide exactly that information, and I follow that practice in all of my own software.] With this background understood, there are two obvious problems with this scheme for non-UNIX systems: (a) periods (and possibly other punctuation characters) in directory names; (b) file and directory names longer than the PC DOS limit of 8+3 characters. Both of these conflict with the reasons (1) and (2) above. Problem (a) can be circumvented by replacing the periods with other characters. I routinely did so on the DEC-20, where I used a hyphen instead of a period. This is marginally more portable than underscore in filenames, and on most keyboards, easier to type. However, if major and minor version numbers are so encoded, then limitation (b) is usually reached. It therefore seems advisable to consider the following alternative naming convention for TeXware archives: (1) Encode the version numbers with hyphens (or perhaps underscores) in the archive file, not worrying about limitation (b), on the grounds that all (I've never seen an exception on dozens of operating systems) ftp implementations make it possible to rename a file fetched from a remote system (this is a necessity, given the varying naming conventions). Thus, we would call the sample files above texinfo-2-25.tar.Z. On non-UNIX systems with adequate file name lengths, this might be renamed to texinfo-2-25.tar-z, or texinfo-2-25.tarz, or texinfo-2-25.trz (I've used all of these in the past). (2) In the archive file itself, recognize that other operating systems have severe name length and character set restrictions, and avoid creating files that have names that would conflict. This is particularly important for directory names, for which tools like zip and zoo might be unable to handle non-native spellings. Thus, I propose that the above example would be revised to unbundle into the directory subtree texinfo/v2-14/ instead of texinfo-2.14 The leading v in v2-14 of course means `version', and is present because I'm told that at least one O/S balks at a leading digit in a file name. As long as the 8-char name length limit (b) is adhered to, such names should not cause problems on any current operating system that supports a true hierarchical file system (I do NOT consider old IBM CMS minidisks to form such a system). ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Tue Jun 23 21:23:07 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14849; Tue, 23 Jun 92 21:23:01 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 23 Jun 1992 20:31:06 CDT Received: from plot79.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13978; Tue, 23 Jun 92 19:30:58 MDT Date: Tue, 23 Jun 92 19:30:58 MDT X-Mx-Warning: Warning -- Invalid "From" header. From: Nelson H. F. Beebe Reply-To: TWG@SHSU.edu To: twg@shsu.edu Cc: beebe@math.utah.edu, rodgers@math.utah.edu, debar@math.utah.edu, staff@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Literature refs on CD ROM Message-Id: A week ago, there was some discussion on this list about CD ROM formats, capacities, and O/S independence. Some very recent literature references that may be useful are given below, together with some comments, and selected quotations. OPTICAL STORAGE Ref. [1] discusses the relative merits of WORM (write-once, read mostly) vs CD ROM (read-only memory) optical storage, and includes a siebar on the RRIP format (see remarks on [4] below). Ref. [2] is 9-page table of vendor information. Ref. [3] makes these interesting remarks: ``Each of these (CD ROMs) holds 660Mbytes. ... CD ROMs in quantity can cost less than US$1.50 each to manufacture. Prices for basic CD-ROM readers have plummeted to as little as US$200 retail. ... Access times just a year or so ago were often 800 ms; the fastest drives today do better than 300 ms.'' Ref. [4] says: ``You can make a thousand CD ROMs for around US$3000, plus or minus discounts, packaging, etc.. Cartridge tapes cost nearly 10 times as much to produce. ... A hundred CD ROMs should cost less than US$2000 to produce. ... Andrew Young, president of Young Minds [one of the organizations that produce CD ROMs of public-domain software], contends that the current crossover point is under 50 units, and dropping. ... The current standard for CD ROM file systems is ISO-9660. Based on a de facto standard known as ``High Sierra'', ISO-9660 is capable, efficient, and widely available. If your users can live with MS-DOS file naming and semantics, ISO-9660 is a perfectly reasonable choice. Most UNIX software distributors, however, find ISO-9660 to be overly restrictive. The file names are bad enough: eight characters or less, no case sensitivity, only one special character (_). Add the limit on directory levels (eight), and the lack of modes, symbolic links, and other UNIXisms, and the situation gets unacceptable in a big hurry. ... Fortunately, a solution is nearly at hand. The Rock Ridge Interface Protocol (RRIP) is upwardly compatible with ISO-9660, but provides full (read-only) UNIX file-system semantics. The gotcha is that only one UNIX vendor seems to have RRIP support in place. NeXT has announced it for the 3.0 OS release. Several other vendors have it in the pipeline. Only Sun has it now, however.'' As I write these words, I'm installing software on a Sun SPARCstation 2 with a RRIP CD ROM on my desk; the system was just installed this afternoon. Tomorrow morning, I'm bringing in an audio CD and headphones to try it out on music. REFERENCES [1] Michael Jay Tucker, ``The Fabulous Closet of Fibber McGee'', SunExpert Magazine, pp. 52--62, June 1992. [2] Maureen McKeon, ``Optical Disk Drives'', SunExpert Magazine, pp. 63--71, June 1992. [3] David Fiedler, ``CD ROM: The Belle of the Ball'', Open Systems Today, pp. 44, 50, June 8, 1992 [4] Richard Morin, ``CD or Not CD, and Other Questions'', SunExpert Magazine, pp. 38, 40--41, June 1992. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Fri Jun 26 08:39:38 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03574; Fri, 26 Jun 92 08:39:35 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.EDU (MX V3.1B) with SMTP; Fri, 26 Jun 1992 09:35:09 CDT Received: from plot79.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03540; Fri, 26 Jun 92 08:34:56 MDT Date: Fri, 26 Jun 92 08:34:56 MDT From: "Nelson H. F. Beebe" Reply-To: TWG@SHSU.edu To: twg@shsu.edu, tex-archive@math.utah.edu Cc: beebe@math.utah.edu, solovay@math.berkeley.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: checksum program for VAX VMS, and zip vs zoo Message-Id: I've updated the Solovay checksum program to work under VAX VMS, and included a VMS executable file in the distribution. The VMS C compiler is an extra-cost option, so not all VMS sites have it. A small source code change was required in checksum to work around the omission of unsigned integer format items in sscanf(), a clear violation of ISO/ANSI Standard C (ANSI X3.159-1989, Section 4.9.6.2). I chose to do this with preprocessor conditionals, rather than a cweb change file, in order that the output C source code can be compiled on any machine. I've also add a README file and a checksum.hlp file from the nroff output of checksum.man. You can find the new version on ftp.math.utah.edu in ~ftp/pub/misc/checksum.* (with anonymous ftp, "cd pub/misc"). Via e-mail, "send index from ftp/misc" to tuglib@math.utah.edu. The individual source files are also stored in ~ftp/pub/tex/pub/checksum (e-mail: "send index from ftp/tex/pub/checksum"). The distribution is available in tar, zip, and zoo formats, and the Makefile incorporates rules for automatic creation of a distribution directory structure that includes the version number. While extending the Makefile to handle this, I noticed that zip seems to produce the most compact archive file: -rw-r--r-- 2 beebe staff 155612 Jun 26 08:03 checksum-1-03.tar.z -rw-r--r-- 2 beebe staff 112690 Jun 26 08:03 checksum-1-03.zip -rw-r--r-- 2 beebe staff 154592 Jun 26 08:02 checksum-1-03.zoo Zip files seem to be about 25% smaller than tar.z and zoo for other archives as well, though my sample includes only 4 different archives at present. I also found that zoo has a distinct design flaw in the handling of directory trees. With tar, mention of a directory file on the command line results in archiving of the directory and its complete subtree. With zip, you have to specify a recursive command-line option to get the same effect. With zoo, you must explicitly name every file. In terms of the checksum distribution, this means I must have a command line like this: zoo a ../checksum.zoo checksum checksum/* checksum/*/* checksum/*/*/* That command line must be updated if an additional directory level is included. There is a clear risk of incomplete distributions because of this misfeature. Also, the expansion of this command line would rapidly overflow the 128-char limit on IBM PC DOS, so use of zoo on that system would require multiple steps to incrementally add files to the archive. Unless someone knows of a newer version that removes these flaws, I propose to drop the use of zoo, and recommend against its use. The version.c file in the zoo source code says char version[] = "Version 2.01 (1988/08/25 12:43:57)"; If I have unfairly maligned zoo, I'll retract these criticisms. Here is the checksum-1-03.tar-lst file: rwxr-sr-x 11/10 0 Jun 26 08:33 1992 checksum/ rwxr-sr-x 11/10 0 Jun 26 08:33 1992 checksum/v1-03/ rw-r--r-- 11/10 5610 Jun 26 08:01 1992 checksum/v1-03/Makefile rw-r--r-- 11/10 1861 Jun 26 08:32 1992 checksum/v1-03/README rw-r--r-- 11/10 15162 Jun 25 09:47 1992 checksum/v1-03/checksum.c rw-r--r-- 11/10 451 Mar 4 16:30 1991 checksum/v1-03/checksum.eok rw-r--r-- 11/10 4635 Jun 25 18:01 1992 checksum/v1-03/checksum.hlp rw-r--r-- 11/10 6329 Jun 19 17:51 1992 checksum/v1-03/checksum.man rw-r--r-- 11/10 62948 Jun 25 17:24 1992 checksum/v1-03/checksum.tex rw-r--r-- 11/10 289 Feb 13 14:09 1992 checksum/v1-03/checksum.toc rw-r--r-- 11/10 43313 Jun 25 09:47 1992 checksum/v1-03/checksum.w rw-r--r-- 11/10 2760 Jun 25 17:24 1992 checksum/v1-03/polynom.c rw-r--r-- 11/10 287 Mar 4 16:30 1991 checksum/v1-03/polynom.eok rw-r--r-- 11/10 8807 Jun 25 17:24 1992 checksum/v1-03/polynom.tex rw-r--r-- 11/10 103 Feb 13 14:09 1992 checksum/v1-03/polynom.toc rw-r--r-- 11/10 4746 Feb 13 14:13 1992 checksum/v1-03/polynom.w rw-r--r-- 11/10 1568 Mar 4 15:46 1991 checksum/v1-03/test.org rwxr-xr-x 11/10 0 Jun 25 13:16 1992 checksum/v1-03/ibmpcdos/ rw-r--r-- 11/10 15929 Jun 25 09:47 1992 checksum/v1-03/ibmpcdos/checksum.c rw-r--r-- 11/10 18333 Sep 7 09:48 1991 checksum/v1-03/ibmpcdos/checksum.exe rw-r--r-- 11/10 1568 Mar 4 15:46 1991 checksum/v1-03/ibmpcdos/test.org rw-r--r-- 11/10 1595 Sep 6 12:14 1991 checksum/v1-03/ibmpcdos/test.new rwxr-xr-x 11/10 0 Jun 25 13:28 1992 checksum/v1-03/vaxvms/ rw-r--r-- 11/10 1766 Jun 25 13:18 1992 checksum/v1-03/vaxvms/vmsmake.com rw-r--r-- 11/10 67072 Jun 25 13:14 1992 checksum/v1-03/vaxvms/checksum.exe ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Fri Jun 26 10:49:43 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04364; Fri, 26 Jun 92 10:49:33 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.EDU (MX V3.1B) with SMTP; Fri, 26 Jun 1992 11:46:49 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA08951 (5.65c/IDA-1.4.4 for ); Fri, 26 Jun 1992 18:39:57 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA02958; Fri, 26 Jun 92 18:39:45 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9206261639.AA02958@hp5.iti.informatik.th-darmstadt.de> Subject: RE: (183) checksum program for VAX VMS, and zip vs zoo To: twg@shsu.edu (TUG TWG --- Archives) Date: Fri, 26 Jun 92 18:39:44 MESZ Cc: p.taylor@vax.rhbnc.ac.uk (Philip Taylor) In-Reply-To: <20211C4A_00275750.0095CAFA262FF680$65_2@UK.AC.RHBNC.VAX>; from "CHAA006@VAX.RHBNC.AC.UK" at Jun 26, 92 4:58 pm X-Mailer: ELM [version 2.3 PL11] Philip Taylor wrote: > > Even more remarkable, > the resulting image is in stream-LF format, whereas in the combined > experience of I and two colleagues, totalling well over thirty man- > years of VAX/VMS, we have _never_ seen an image in other than fixed-512 > format. What has happened to this great VMS utility named FILE I was used to use? It allows to record file attributes and to change them at will. Eg, if I needed to preserve file attributes, I recorded them, changed them to 512 fixed block (good to transfer with file type image), transferred them over which-ever-system-I-wanted, and put back the file attributes. Worked like a charm. Once I transferred backup savesets (with these ugly record length of 32768) over PC floppies... FILE was available on each DECUS tape. It's a Great Thing (tm)! (I can look if I can dig it out, if it's not available. Should have it on some tape...) -- Joachim PS: Yesterday I sent two mails which I did not receive myself later. The mails were concerned with the IETF WG IAFA, and with ftp daemons. Please send me personal mail if they did not arrive, I'll resubmit them. From ITeX-Mgr@SHSU.edu Fri Jun 26 10:21:02 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04173; Fri, 26 Jun 92 10:20:32 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.EDU (MX V3.1B) with SMTP; Fri, 26 Jun 1992 11:19:02 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA42713 (5.65c/IDA-1.4.4 for ); Fri, 26 Jun 1992 18:15:27 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA02878; Fri, 26 Jun 92 18:15:15 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9206261615.AA02878@hp5.iti.informatik.th-darmstadt.de> Subject: archie (again) To: twg@shsu.edu (TUG TWG --- Archives) Date: Fri, 26 Jun 92 18:15:14 MESZ X-Mailer: ELM [version 2.3 PL11] Since June, 15, there has been a lot of comments on archie in this mailing list. I want to add more infos; below come comments on the following topics: -- Technical points -- Whom's to contact about archie -- Non-technical problems -- The Future of Archie -- Is archie really what we need? Each point may be read without the other topics, if you have only particular interests. ** Technical points First, there were some persons who asked how archie works. For those who really want more to know, there is a paper in the Usenix 92 proceedings. It's also available via anon ftp: in the US (reference site): archie.mcgill.ca directory archie/doc in Europe (mirror): ftp.th-darmstadt.de directory pub/info/internet/archie (Doubtless more sites carry it, too...) -- In this paper we find also a reference to a famous person, who ``contributed to the archie manual page'': Nelson H. F. Beebe :-) :-) In this directory you'll find also the file ls-formats, which describes the form of directory listings archie needs. As you will see, the listings is, in fact, a UNIX 'ls -lR' listing. If one would produce a listing of a VMS site which follows the standard given there, one would be able to add a VMS site to the archie database, too. (A conversion program should not be hard to write, since perl is available on VMS...) So there is no inherent problem in adding VMS sites, it's just a problem that there the site administrators have more problems providing the directory listing file. Btw, someone mentioned that Stuttgart would not be in the database. The database stores always the primary name. So Stuttgart is not listed as ftp.uni-stuttgart.de or rusinfo.rus.uni-stuttgart.de, but as rusmv1.rus.uni-stuttgart.de. ** Whom's to contact about archie Someone mentioned that he wanted to know who's responsible. The "Archie Group" consists of Peter Deutsch , Alan Emtage , and Bill Heelan . But to my knowledge, mail can (and should) be sent to archie-group@archie.mcgill.ca. ** Non-technical problems What is always a non-technical problem? Money... The archie software was never freely redistributable. It was sometimes given free of charge to interested parties who wanted to set up an archie server. Recently, the archie group announced that they will **sell** the software in the future. That means, someone who wants to set up an archie server must not only supply the hardware and the man power, but also the money for the software. And that for a service where the supplier has nearly nothing from it! Btw, it isn't quite clear if this would be a single payment, might even be yearly. Needless to say, this announcement resulted in a heated discussion. The point is quite clear: The archie project has got too large to be a purely voluntary work. They need money. A lot of people asked why they did not ask the IAB or the IETF for funding, especially as Peter Deutsch and Alan Emtage knows people there as IAFA chairs. After all, Henry Spencer also receive(s/d) funding for C-News, so it's possible to get money from there. And surely (ten-)thousands of users would have written a supporting mail to the powers-that-be... For my background: The TU Darmstadt once planned to install the German archie server. They received the archie source under the original conditions (ie, for free) and are now asked to pay money for it. (To be more precisely, they can use the current source, but will not receive any updates.) When they heared that they put the project on ice (well, it cooks on a small fire ;-), our powers-that-be at the university don't want to spend this money. Disclaimer: I report to the best of my knowledge. You should not take it as an official report. But I know the guy who does the archie project here very well, and I've also followed the respective discussion. ** The Future of Archie I will seriously warn to take archie as a given institution. It is _not_ clear if it will survive under the current situation. Some archie service suppliers now shy away from the continuation (resp. the beginning) of their service. This is to a very high degree a `person's project'. If these persons leave and go to another place, they might perhaps not continue their work. I don't want to sound too pessimistic: To my knowledge, Peter Deutsch and Alan Emtage now work at the Computing Center, after they graduated. So the first cliff (where do they work after finishing their M.Sc.) is surrounded. But we should also look some years in the future. ** Is archie really what we need? I want to put up the hypothesis that archie does not fit our needs. What are the _real_ questions user pose, respectively the _real_ problems which must be attacked? ``I need a LaTeX style numbering footnotes on each page.'' ``How do I print long BibTeX files?'' ``METAFONT mode_def's needed for OKI MicroLine 801PS'' ``Managing BibTeX files'' (a question for an interactive UI) ``text flowing around figures'' ``previewing PostScript'' ``BibTeX implementation for IBM PC'' Note: These citations are directly taken from comp.text.tex and my personal incoming mailbox. These are the questions which must be answered. The answers may be easily given by all of us, they involve styles, parameter files, programs, etc. Short: files which may be retrieved from the usual archives. So we should strive to answer the questions above, they subsume the question `where do I find latexinfo'. ;-) And the techniques to answer exactly these questions are already there (well, in a first-order approximation): WAIS for the information retrieval and gopher for an integrated environment for WAIS and anonymous ftp. We should provide David's style index in a WAIS server, _that_ would be a service to the TeX community. You don't know about WAIS? Rush out, throw on your ftp, and fetch the file wais-paper.ps.Z from ftp.th-darmstadt.de, directory pub/info/internet. Or ftp to quake.think.com, directory wais, to get more and full doc. I can promise you: it's great! The global village comes into sight. Any comments? -- Joachim From ITeX-Mgr@SHSU.edu Fri Jun 26 11:18:37 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07177; Fri, 26 Jun 92 11:18:25 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.EDU (MX V3.1B) with SMTP; Fri, 26 Jun 1992 11:54:20 CDT Via: uk.ac.rhbnc.vax; Fri, 26 Jun 1992 17:53:13 +0100 Date: Fri, 26 JUN 92 17:53:29 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: FILE needed? Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <2020E4E8_00076820.0095CB01CAC06520$15_2@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: $TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) >>> What has happened to this great VMS utility named FILE I was used to >>> use? I think Joachim misses the point: the stream-LF image _works_! I didn't need Joe Meadow's FILE to fix it! That was the whole point of the message ... ** Phil. From ITeX-Mgr@SHSU.edu Fri Jun 26 13:28:52 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10065; Fri, 26 Jun 92 13:28:46 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.EDU (MX V3.1B) with SMTP; Fri, 26 Jun 1992 14:20:45 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA32877 (5.65c/IDA-1.4.4 for ); Fri, 26 Jun 1992 21:12:08 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA03190; Fri, 26 Jun 92 21:11:56 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9206261911.AA03190@hp5.iti.informatik.th-darmstadt.de> Subject: Re: (1) Databases and (2) compression schemes (fwd) To: twg@shsu.edu (TUG TWG --- Archives) Date: Fri, 26 Jun 92 21:11:55 MESZ X-Mailer: ELM [version 2.3 PL11] OK, again. This is one of the messages I sent yesterday. My apologies if it arrives twice. -- Joachim ---------------- Original message follows: David M. Jones wrote: > > 2) There's been some discussion of whether ZOO or ZIP should be used by > the archives. Two part question: > > a) Mail servers typically allow several options for archiving and > encoding files. What options should mail servers support? (By the > way, is vvencode ready for use yet?) As many as possible. It's more convenient for the user. The mail-server which runs in Stuttgart does a very good job. > b) Also, on the extreme speculative side of things, is there any way > that ftp could be modified to allow the user to specify an archiving > scheme interactively? Yes, there are ftp daemons out, which allows this. Eg, the wuarchive ftpd (ask archie for ftpd.wuarchive.shar) let's you fetch a whole directory as a .tar.Z, .zip, .zoo, or .what-you-want file. (Of course, the ftp administrator can forbid this for single directories...) In addition, this ftpd provides **much** better statistics (good for convincing the people responsible for funding ;-), etc. The only problem I have with it: I was not able to bring it up on an RS/6000. :-( I hit a nasty security hole in the setuidx() routines and had to stop... -- Joachim From ITeX-Mgr@SHSU.edu Fri Jun 26 13:29:39 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10073; Fri, 26 Jun 92 13:29:32 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.EDU (MX V3.1B) with SMTP; Fri, 26 Jun 1992 14:20:53 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA33159 (5.65c/IDA-1.4.4 for ); Fri, 26 Jun 1992 21:14:49 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA03228; Fri, 26 Jun 92 21:14:37 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9206261914.AA03228@hp5.iti.informatik.th-darmstadt.de> Subject: General structure/admin. of ftp archives (fwd) To: twg@shsu.edu (TUG TWG --- Archives) Date: Fri, 26 Jun 92 21:14:36 MESZ X-Mailer: ELM [version 2.3 PL11] OK, again. This is one of the messages I sent yesterday. My apologies if it arrives twice. -- Joachim ---- Included file follows: /auto/ftp/pub/info/internet/iafa/charter [[ Hmm, I have to read a backlog of 14 days TWG mailings. Seems I will post more tomorrow. Perhaps some background on archie and why archie poses real problems -- y'know? we are running the German archie server here, archie.th-darmstadt.de ... ]] Concerning the detailled directory structure proposal I will post a critique in another mail. But a general point comes to mind: How many people in this discussion know about IAFA? For those not: It's an IETF (== Internet Engineering Task Force) working group on Internet Anonymous Ftp Archives which shall ``define a set of recommended standard procedures for the access and administration of anonymous ftp archives.'' I append the charter below. After approval, the result will be published as an RFC (and will become a de-facto standard, IMO). Eg, the rewrite of the archie server which is currently under way, targets and utilizes the structure defined in the drafts. The drafts themselves (Part I: ``A Guide to FTP Site Administration'', Part II: ``Publishing Information on the Internet with Anonymous FTP'') are available by anonymous ftp, in the US: ftp.cc.mcgill.ca [132.206.27.10] directory pub/iafa/ in Europe: ftp.th-darmstadt.de [130.83.55.75] directory pub/info/internet/iafa/ Darmstadt mirrors daily. (That's me, yesterday I received new revisions. ;-) I can mail the drafts it to people without ftp access. (Or they can use an ftp-mail gateway.) -- Joachim ---------------- included file: pub/info/internet/iafa/charter Internet Anonymous FTP Archives Working Group Chairs: Peter Deutsch/McGill University peterd@cc.mcgill.ca Alan Emtage/McGill University bajan@cc.mcgill.ca Mailing Lists: General Discussion: iafa@cc.mcgill.ca To Subscribe: iafa-request@cc.mcgill.ca Mail Archive: pub/iafa-archive@archive.cc.mcgill.ca Description of Working Group: The Internet Anonymous FTP Archives Working Group is chartered to define a set of recommended standard procedures for the access and administration of anonymous ftp archive sites on the Internet. Such a set of procedures will provide a framework for (a) allowing the inexperienced Internet user the ability to more easily navigate the hundreds of publically accessible archive sites; and (b) allowing users and network-based tools to retrieve specific site information such as access policies, contact information, possible areas of information specialization, archived package descriptions etc in a standardized manner. Particular emphasis will be placed on the possible impact of these procedures on the FTP site administrators. Attention will be paid to the impact of newer archive indexing and access tools on the operation of such archive sites. A set of suggestions will be offered to allow archive site administrators to better integrate their offerings with such tools as they are developed. The security of the anonymous FTP site configuration will also be considered to be an integral part of this document. It is expected that remote management of the archives will be adequately handled by existing network management procedures. Goals and Milestones: Nov 1991 First IETF Meeting: review and approve the charter making any changes deemed necessary. Examine the scope of the recommended procedures and impact on site administrators. Assign writing assignments for the first draft of the documents. Mar 1992 Review first draft and determine necessary revisions. Follow up discussion will occur on mailing list. Jun 1992 Make documents an Internet Draft. Continue revisions based on comments at IETF and on the mailing list. Nov 1992 Fourth IETF meeting. Review final drafts and if OK, give to IESG for publication as an RFC. -- eof From ITeX-Mgr@SHSU.edu Fri Jun 26 13:43:50 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10122; Fri, 26 Jun 92 13:43:40 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.EDU (MX V3.1B) with SMTP; Fri, 26 Jun 1992 14:29:07 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA35834 (5.65c/IDA-1.4.4 for ); Fri, 26 Jun 1992 21:24:40 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA03165; Fri, 26 Jun 92 21:09:56 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9206261909.AA03165@hp5.iti.informatik.th-darmstadt.de> Subject: RE: archie (again) To: TWG@SHSU.edu Date: Fri, 26 Jun 92 21:09:55 MESZ In-Reply-To: <2020EED5_000780B0.0095CB016FC9F500$19_1@UK.AC.RHBNC.VAX>; from "CHAA006@VAX.RHBNC.AC.UK" at Jun 26, 92 5:50 pm X-Mailer: ELM [version 2.3 PL11] You wrote: > > 1) Does archie meet our needs? Joachim posits a series of questions > which are the sort of trivia one reads only too often in TeXhax > and which totally overwhelms C.T.T (which is why I've stopped > reading the latter; you can't separate the wood from the trees). > But these are questions that _users_ ask; the sort of questions > which I assert that _we_ (as service providers) ask is "Where can > I find a copy of , This is a subset of the user's questions. Ie, the ftp listings are indexed and may be searched. Besides -- archie is not able to tell you where the reference site is. (To be honest: 3.0 will be.) If the information is indexed (eg, in David's style index), WAIS does answer such questions already. Besides, one can always index ftp listings. > or perhaps something that refers to ?". Hmm, how do you ask this archie? That's exactly the question one can ask WAIS. I must make clear that I have nothing against archie. Since I have one available at 10 MB/sec, I use it quite often -- but I would not want to put to much support in it. The state of affairs must settle down first. > 2) WAIS: it looks wonderful, and I have a copy on my PS/2. But that > references WLIBSOCK.DLL, which is part of a Novell proprietary > network kit, and which I therefore don't have. I append an announcement about a MSDOS WAIS client which works with the Clarkson Packet Drivers. Ie, it's free. Btw, 30 seconds ago I did not have this information. I just queried WAIS about the comp.archives archives. :-) > Conclusions: wouldn't it be better for a few service providers > to pay a fee to licence Archie than for all MS/DOS users to have > to pay a fee to licence Novell? Since MSDOS users don't have to pay a fee to licence Novell, I think I don't need to answer this question... -- Joachim ------ Included file follows: /auto/wuarchive/archives/usenet/comp.archives/volume92/Apr/920423.10 Path: wupost!spool.mu.edu!agate!rhumba.oit.unc.edu!fullton From: fullton@rhumba.oit.unc.edu (Jim Fullton) Newsgroups: comp.archives Subject: [alt.wais] New WAIS/MSDOS Available Message-ID: Date: 23 Apr 92 22:28:56 GMT Article-I.D.: agate.t7dn8INNi0b References: <1992Apr22.173342.28481@samba.oit.unc.edu> Followup-To: alt.wais Organization: University of NC Lines: 16 Approved: adam@soda.berkeley.edu NNTP-Posting-Host: soda.berkeley.edu X-Original-Newsgroups: alt.wais X-Original-Date: 22 Apr 92 17:33:42 GMT Archive-name: auto/alt.wais/New-WAIS-MSDOS-Available New WAIS/MSDOS Version Available Version 1.02 of WAIS for MSDOS/Clarkson Packet Drivers is available from ftp.oit.unc.edu, in pub/wais/UNC/DOS. This version fixes a few bugs and provides cleaner access for those without a mouse. The next release will provide a mechanism for dealing with non-textual documents. Jim Fullton Jim_Fullton@unc.edu -- eof From ITeX-Mgr@SHSU.edu Fri Jun 26 14:22:27 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10346; Fri, 26 Jun 92 14:22:17 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.EDU (MX V3.1B) with SMTP; Fri, 26 Jun 1992 14:46:18 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA06483 (5.65c/IDA-1.4.4 for ); Fri, 26 Jun 1992 21:10:08 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA03165; Fri, 26 Jun 92 21:09:56 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9206261909.AA03165@hp5.iti.informatik.th-darmstadt.de> Subject: RE: archie (again) To: TWG@SHSU.edu Date: Fri, 26 Jun 92 21:09:55 MESZ In-Reply-To: <2020EED5_000780B0.0095CB016FC9F500$19_1@UK.AC.RHBNC.VAX>; from "CHAA006@VAX.RHBNC.AC.UK" at Jun 26, 92 5:50 pm X-Mailer: ELM [version 2.3 PL11] You wrote: > > 1) Does archie meet our needs? Joachim posits a series of questions > which are the sort of trivia one reads only too often in TeXhax > and which totally overwhelms C.T.T (which is why I've stopped > reading the latter; you can't separate the wood from the trees). > But these are questions that _users_ ask; the sort of questions > which I assert that _we_ (as service providers) ask is "Where can > I find a copy of , This is a subset of the user's questions. Ie, the ftp listings are indexed and may be searched. Besides -- archie is not able to tell you where the reference site is. (To be honest: 3.0 will be.) If the information is indexed (eg, in David's style index), WAIS does answer such questions already. Besides, one can always index ftp listings. > or perhaps something that refers to ?". Hmm, how do you ask this archie? That's exactly the question one can ask WAIS. I must make clear that I have nothing against archie. Since I have one available at 10 MB/sec, I use it quite often -- but I would not want to put to much support in it. The state of affairs must settle down first. > 2) WAIS: it looks wonderful, and I have a copy on my PS/2. But that > references WLIBSOCK.DLL, which is part of a Novell proprietary > network kit, and which I therefore don't have. I append an announcement about a MSDOS WAIS client which works with the Clarkson Packet Drivers. Ie, it's free. Btw, 30 seconds ago I did not have this information. I just queried WAIS about the comp.archives archives. :-) > Conclusions: wouldn't it be better for a few service providers > to pay a fee to licence Archie than for all MS/DOS users to have > to pay a fee to licence Novell? Since MSDOS users don't have to pay a fee to licence Novell, I think I don't need to answer this question... -- Joachim ------ Included file follows: /auto/wuarchive/archives/usenet/comp.archives/volume92/Apr/920423.10 Path: wupost!spool.mu.edu!agate!rhumba.oit.unc.edu!fullton From: fullton@rhumba.oit.unc.edu (Jim Fullton) Newsgroups: comp.archives Subject: [alt.wais] New WAIS/MSDOS Available Message-ID: Date: 23 Apr 92 22:28:56 GMT Article-I.D.: agate.t7dn8INNi0b References: <1992Apr22.173342.28481@samba.oit.unc.edu> Followup-To: alt.wais Organization: University of NC Lines: 16 Approved: adam@soda.berkeley.edu NNTP-Posting-Host: soda.berkeley.edu X-Original-Newsgroups: alt.wais X-Original-Date: 22 Apr 92 17:33:42 GMT Archive-name: auto/alt.wais/New-WAIS-MSDOS-Available New WAIS/MSDOS Version Available Version 1.02 of WAIS for MSDOS/Clarkson Packet Drivers is available from ftp.oit.unc.edu, in pub/wais/UNC/DOS. This version fixes a few bugs and provides cleaner access for those without a mouse. The next release will provide a mechanism for dealing with non-textual documents. Jim Fullton Jim_Fullton@unc.edu -- eof From ITeX-Mgr@SHSU.edu Fri Jun 26 15:17:15 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10702; Fri, 26 Jun 92 15:17:05 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 31304; Fri, 26 Jun 1992 16:13:27 CDT Date: Fri, 26 Jun 1992 16:11:30 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095CAF3.8C32F060.31304@SHSU.edu> Subject: RE: (183) checksum program for VAX VMS, and zip vs zoo On Fri, 26 Jun 92 18:39:44 MESZ, Joachim Schrod posted: > Philip Taylor wrote: > > > > Even more remarkable, > > the resulting image is in stream-LF format, whereas in the combined > > experience of I and two colleagues, totalling well over thirty man- > > years of VAX/VMS, we have _never_ seen an image in other than fixed-512 > > format. > > > What has happened to this great VMS utility named FILE I was used to use? > > It allows to record file attributes and to change them at will. Eg, if I > needed to preserve file attributes, I recorded them, changed them to 512 > fixed block (good to transfer with file type image), transferred them over > which-ever-system-I-wanted, and put back the file attributes. Worked like a > charm. Once I transferred backup savesets (with these ugly record length of > 32768) over PC floppies... As Phil's already noted, the file *didn't* have to be changed! This retention of file characteristics (even though they may not appear to the DIR/FULL on VMS if you do a platform to platform to platform transfer) is the over-riding reason why I am so impressed with ZIP. If the file was right when it was ZIPped, it stays right! > FILE was available on each DECUS tape. It's a Great Thing (tm)! (I can look > if I can dig it out, if it's not available. Should have it on some tape...) No need. You can use SENDME FILE and get a VMS_SHARE set of the sources, or ftp to Niord.SHSU.edu (192.92.115.8) and get [FILESERV.FILE]FILE_SOURCES.ZIP (a ZIP file of all source files) or cd to [FILESERV.FILE.SOURCES] and get the individual source files. I've been toying with this as a suggested component of the VMS port of the mirror software as this is the only way I am aware of the change the time of the file. Still can't get a true VMS working version of mirror up, but I'm blindly hacking away at the perl involved. By the way, we have a VMS port of perl, if anyone's interested, in [FILESERV.PERL]. Regards, George (yes, undoubtedly the strangest ftp collection) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Sat Jun 27 10:12:11 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17530; Sat, 27 Jun 92 10:12:09 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.EDU (MX V3.1B) with SMTP; Sat, 27 Jun 1992 11:11:28 CDT Via: uk.ac.rhbnc.vax; Sat, 27 Jun 1992 17:10:54 +0100 Date: Sat, 27 JUN 92 17:11:13 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: RE: archie (again) Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <2021203C_0033ABE8.0095CBC50D7428C0$27_2@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) >>> Hmm, how do you ask this archie? That's exactly the question one can >>> ask WAIS. More to the point, how do you ask WAIS ?! I have now imported Jim Fullton's DOS version (many thanks for the reference; Jim himself failed to tell me about it when I asked him about WLIBSOCK.DLL), but the README and HELP files tell one almost nothing. There seems to be a rather strange convention at the moment that one automatically knows (a) what things do, and (b) how to use them (e.g. just press `About' in any Windows-3 application: the _last_ thing it tells you is anything useful _about_ the facility; instead, it tells you a version number and similar pointless facts). S, please: now that I have WAIS, what the h@ll do I do with it, and how do I use it ? ** Phil. From ITeX-Mgr@SHSU.edu Mon Jun 29 03:41:06 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00414; Mon, 29 Jun 92 03:41:02 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from serv02.ZIB-Berlin.DE by Niord.SHSU.EDU (MX V3.1B) with SMTP; Mon, 29 Jun 1992 04:37:13 CDT Received: from dagobert.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/7.11.91 ) id AA28331; Mon, 29 Jun 92 11:22:22 +0200 Received: from quattro.ZIB-Berlin.DE by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/6.5.92 ) id AA21786; Mon, 29 Jun 92 11:22:17 +0200 Date: Mon, 29 Jun 92 11:22:17 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9206290922.AA21786@sc.zib-berlin.dbp.de> Received: by quattro.ZIB-Berlin.DE (4.1/SMI-4.1) id AA19088; Mon, 29 Jun 92 11:22:05 +0200 To: TWG@SHSU.edu Subject: Lots of answers Reply-To: TWG@SHSU.edu Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin This weekend I've finally found the time to go through the accumulated TWG mail and cook up an answer to some of the issues raised. Let me begin with a proposal for a scheme for file storage in the archives: 1) Case: all names should be either lowercase (like on Unix), or uppercase (like on VMS). 2) Length: In my opinion, this is only an issue for file names, not for directory names. File names should stick to the 8+3 limit, or at least be unique when truncated to 8+3. 3) Version numbers: These should be encoded in directory names. Using, e.g., VMS version numbering is not a solution, as it is restricted to a certain subset of the integers, and they are not so easy to enforce all the times. I don't think file name length is an issue for the archive machines. Re: George's question about mirroring: My strategy is to ignore VMS version numbers completely, as they are more or less random, as far as mirroring is concerned. 4) Line length: From my experience, a limit of 72 characters per line should be maintained. The rule is that lines with no more than that length can easily be transferred over any network I have worked with, and be viewed with any editor I have seen. Also, all files should contain a character table. 5) Tree structure: I agree with most of the points raised up to now. Some comments about ``category errors'': Though this is a valid point in principle, it is of little practical use. The tree structure should facilitate access rather than only follow an abstract scheme. Users tend to expect those things that they think are important on a higher level of the tree. Example: last year I received an email message complaining that emtex was concealed in the Stuttgart archive. It's place is tex/machines/pc/emtex, what I (and judging from the ongoing discussion, most of you as well) think is a reasonable place. Therefore, it is important to have, e.g, LaTeX on a higher level than phyzzx and ytex, though they are on the same logical level. I object to having latex-style below extensions, same for AMS. 6) Re: Barbara's concern about the name of the root directory of e-math.ams.com: I don't see why the AMS's archive tree needs to start with tex-archive. It's a dedicated archive for the ams, so I think it's enough to say that this is just the subtree that is called, say tex-archive/ams in the complete archives. 7) Compressing/encoding schemes: At present, I have two objections against zip, in favor of zoo: zoo runs on mainframes (does zip run on macs?), and I have had some problems with transferring zip files between machines, but I had never had those with zoo files. Mind you, I'm not arguing against zip, I'm only saying that it is not yet ready -- in this respect. Also, we should investigate which one has the better compression scheme. Nelson reported that zoo archives are longer, but this is only true for versions before 2.1. Also, his remark that it cannot pack whole directory structures is, in my opinion, not of great importance, as one can always write "find -print | zoo aI". This works even on MS-DOS (not that the latter is an important issue for the archives). In response to David's question about vvencode/vvdecode: These should be out real soon, version 1.0 is finished, but the test suite and documentation need a bit of work (so I'm told). I have version 0.6, and it is running very nicely, apart from a few minor problems. 8) Some more specific comments on the tree structure: 8a) tex-archive/fonts: I think there should be subdirectories pk, vf, tfm, perhaps gf, ... that contain all the relevant files. For pk and gf, this means that there is one subdirectory per output device. If there are subdirectories with such files elsewhere, symbolic links (for Phil: secondary file pointers) should be used. We should make heavy use of these anyway. Another problem in this area is the naming of font files. gf and pk files are most often named .pk, where number is given by (resolution times maginification). As Karl Berry has mentioned, this is longer than 8+3 in many cases. Let me propose another naming scheme that is currently used by one of the Atari implementations: have one directory for every output device, containing one directory for every magnification, which in turn contains files with names .pk. The magnification directories are called mag____1.000, mag.____1.095, mag____1.440, etc. 8b) REVTEX: this is an extension to LaTeX, and should therefore go into that tree. 8c) Why is developers a subdir of user-groups? 8d) A minor point re: /tex-archive/web-sources: shouldn't there be also subdirs for webware and texware? 8e) I find the supported/unsupported distinction immensely useful, since people see the distinction before they fetch the file. You can't have this if all files are in one directory, since you will find then it can be found out only after you have feteched all the files. An INDEX file is only of help if there are not too many files in that directory. 8f) I'm not sure that the distinction between printer drivers and previewers is a useful one. What do you do with programs that offer both choices? 8g) Why is macmakeindex a subdir of bibtex and not located under systems? More generally, I propose to use links for such items. Especially drivers that where developed for one particular type of machine should go both under system/system-name/drivers/driver-name and drivers/driver-name. Rainer Schoepf From ITeX-Mgr@SHSU.edu Mon Jun 29 09:15:24 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03210; Mon, 29 Jun 92 09:15:18 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 2879; Mon, 29 Jun 1992 09:44:42 CDT Date: Mon, 29 Jun 1992 09:44:26 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: twg@SHSU.edu Message-Id: <0095CD18.F8E73960.2879@SHSU.edu> Subject: The proposed IAFA standards -- NOT! % Please consider extracting and LaTeXing this file. I have hardcoded a % version of fullpage.sty into the preamble -- all that should be required % is base LaTeX, with article.sty and art11.sty. This outputs a document % of five pages. --- GDG % checksum = "58893 292 2402 15415" \documentstyle[11pt]{article} \topmargin 0pt \advance \topmargin by -\headheight \advance \topmargin by -\headsep \textheight 8.9in \oddsidemargin 0pt \evensidemargin \oddsidemargin \marginparwidth 0.5in \textwidth 6.5in % For users of A4 paper: The above values are suited for American 8.5x11in % paper. If your output driver performs a conversion for A4 paper, keep % those values. If your output driver conforms to the TeX standard (1in/1in), % then you should add the following commands to center the text on A4 paper: % \advance\hoffset by -3mm % A4 is narrower. % \advance\voffset by 8mm % A4 is taller. \nofiles % Don't need them, so why use them? \begin{document} \title{Why the IAFA Draft Standards are Inadequate for Our Task} \author{George D. Greenwade {\tt }} \date{June 29, 1992} \maketitle \section{Introduction} This is in response to Joachim Schrod's\footnote{{\tt }, archived from {\tt } on Fri, 26 Jun 1992 14:23:44 CDT, Message-ID: {\tt <9206261914.AA03228@hp5.iti.informatik.th-darmstadt.de>}, Subject: General structure/admin. of ftp archives (fwd)} stated opinion that the present work of the Internet Anonymous FTP Archives Working Group (the IAFA), once submitted to the RFC Editor and published as an Internet RFC, will become the {\em de facto} standard for anonymous ftp structures.\footnote{The current (June, 1992) drafts of this working group's proposal may be found in the files {\tt [FILESERV.IAFA]DRAFT.PART\_I} and {\tt [FILESERV.IAFA]DRAFT.PART\_II} on {\tt Niord.SHSU.edu [192.92.115.8]}.} It is my {\em strongly-held} position that the only way that this document will become a standard is of a subtle transposition in letters --- ``compliant'' versus ``complaint'' --- are taken into account immediately.\footnote{I have attempted on 11 different occasions (beginning in January, 1992) to subscribe to the general discussion list provided for this Internet Engineering Task Force (IETF), {\tt }, via the provided -Request address, {\tt }, and have been unsuccessful each time. Any relevant information included in this document which anyone can get through to the node {\tt cc.mcgill.ca} will be sincerely appreciated.} \section{Background and Research Findings} For approximately 7 weeks prior to creating the current TWG list\footnote{{\tt }, the discussion support list for the Technical Advisory Council of the \TeX\ Users Group's Working Group on \TeX\ Archive Guidelines (WG 92-05).}, I studied what the existing or developing alternatives were to any work which this group might undertake. Clearly, if an acceptable present or developing standard were available, it would save everyone some work, in addition to complying with that standard. Simple promulgation of that standard would suffice. Admittedly, seven weeks is not a long time and my research was not exhaustive. However, I attempted to review past {\em TUGboat}\footnote{{\em TUGboat} is the official Communications of the TeX Users Group.} and {\tt tex-archive}\footnote{Nelson Beebe's \TeX\ archiving list, {\tt }.} notes, present \TeX\ archive structures, existing RFC documents, and the on-going work of the IAFA. The following observations arose from this: \begin{enumerate} \item It was not totally clear but could be extrapolated from the {\tt tex-archive} archives that most sites would very likely agree to follow archival guidelines, provided that they are consistent, well-known, and agreeable in structure. \item Also from {\tt tex-archive}, it was apparent that, as a group, \TeX\ archivists possess quite possibly the broadest and most comprehensive grasp of the multi-platform problem in filename and directory structure conventions. I assume that this understanding is a result of at least two factors: \begin{enumerate} \item \TeX, by its design, is platform independent. Admittedly, each operating system requires a different flavor of the underlying executable but, for the most part, what works on one system ({\em sans} executables) works on all systems. This is a tribute to Knuth's foresight, as well as consistency followed by various standards committees, to which we are all indebted. \item Two of the three major \TeX\ repositories with long-term experiences (Aston and YMIR) are VMS-based.\footnote{Although SHSU is also VMS, I exclude it for two reasons. First, although we are extraordinarily busy, our directory structure is dictated by the design requirements of {\tt FILESERV}; for FTP purposes, our directory structure is not a practical alternative. However, over the past 45 days, we have averaged in excess of 575 file transfers a day via e-mail (approximately one every 2.5 minutes over an 1,100 hour time span) and our communications machine, {\tt Niord.SHSU.edu}, has been operating at an average of 82\% CPU capacity during that period. Additionally, our FTP logs indicate that we have been handling approximately 425 outbound file transfers daily, even with this impractical directory structure. Therefore, until some agreement at least in basic form can be reached (assuming that one can), I hesitate to change things. Second, and much more important, SHSU is still the ``newbie'' on the block --- our 20 months of existence is but a blip when compared to the longer-running Aston, Stuttgart, and YMIR.} If I understand Don Hosek correctly, the \TeX\ archives presently on YMIR will soon migrate to a Unix platform; however, I know he has an understanding of VMS constraints and assume that he will support concepts associated with what would be required to run a VMS site. While SHSU will support both a VMS-based and a Unix-based \TeX\ archive in the very near future, I would much rather serve as administrator of two consistent directory and filename structures. \end{enumerate} \item From TUGboat, it is apparent that a semi-consistent user interface, especially with respect to mail handling and mailer encoding, is desired. This is a topic not completely dealt with yet by TWG. \item Existing Internet RFC documents have nothing of significant consequence, as far as I can tell, for the goals of this working group, as stipulated in its mandate.\footnote{That mandate may be found in the file {\tt [FILESERV.TWG]TWG.MANDATE} on {\tt Niord.SHSU.edu}.} \item The IAFA is wholly geared toward Unix FTP sites and, at least in its present format, is largely unacceptable for the purpose of providing consistent multi-platform FTP support of electronic archives, including \TeX-related archives. I personally attribute this to the apparent system-centricism of the Archie group, which appears to be the majority of the IAFA working group. \end{enumerate} \section{Critical Questions} Given the fact that \TeX\ archives are both Unix-based and VMS-based, the following two questions have an imperative answer of ``yes.'' \begin{itemize} \item Should \TeX\ archive sites be able to handle files from one another as easily, automatically, and painlessly as possible? \item Should it be as transparent as possible to the end FTP archive user which of the archival machines they are on? \end{itemize} The answer to the first question above is of less importance as it can be handled via proper parsing routines; however, these parsing routines do not now exist and if a standard can be agreed to in advance and followed, why bother? Moreover, this is an archivist question, rather than an archive user question. If the answer to the second question above is ``no,'' then I propose that we gracefully adjourn and I will prepare, for your consideration and comment, a final document from TWG 92-05 stating in essence, ``there is no interest at the present time in coordinating the archives in an effort to assist archivists nor the end users of known \TeX-related archives." \section{Is the IAFA Draft Acceptable?} As with any group effort of this magnitude, I am simultaneously impressed and depressed by the IAFA drafts of June, 1992. Among these documents, the commentary of the importance of anonymous FTP, the rationale for institutionally supporting anonymous FTP facilities, security considerations, standardized information files, and general concept for coordination is of the highest merit and I am quite impressed. With that in mind, I recommend that this TWG consider being compliant in providing the suggested information. Alone, as a skeleton, this is where these documents should end. The extension into practical application is among the most depressing work I have seen in its system-centrism. At this point, the transposition of compliant to complaint occurs, in at least three areas. First, after seven months of work, beginning in November, 1991, VMS as an operating system for anonymous FTP continues to be mentioned only once between the two draft documents --- on line 298 of {\tt draft.part.I} (the IAFA's an choice for this file's name --- an unacceptable VMS filename!) as an afterthought or a to-do: \begin{verbatim} [VMS] [other OS?] \end{verbatim} After a marvelous discussion of the esoterica associated with anonymous FTP facilities, VMS is a platform which will theoretically have to comply, but is not considered in design --- COMPLAINT!!\footnote{I cannot answer this question, but does anyone know how many VMS-based anonymous FTP machines exist on the Internet? After looking at the Internet's {\tt hosts.txt} file, my guess is that it is not a trivial number --- quite possibly as large as any one given ``flavor'' of Unix!} Second, a serious limitation of the drafts are their clear distinction and reliance on case-sensitivity in filenames. From {\tt draft.part.II} (line 318{\em ff}): \begin{verbatim} A file of the given name will exist for each category listed in Part I. For the sake of consistency across operating systems and for the ability to distinguish them from non-configuration files of the same name, the filenames will be in all uppercase letters. Because of restrictions on some systems, filenames will be kept to a maximum of 14 characters. \end{verbatim} Show me how this can be achieved on a VMS platform and I will comply, else this is a complaint. Since the apparent drift of the documents are ``if you don't have a Unix like ours, get one,'' I cannot comprehend the 14 character filename limitation. Clearly, the drafts allow for some systemic limitations, and it is obvious that the limitation provided for here is most likely a result of one of the IAFA members complaining he or she will be left out if longer filenames have to be provided for. Note that VMS would not cause this restriction! The draft should be consistent --- ``get a machine as absolutely flexible as ours or don't play this game,'' or ``since we will allow for systemic limitations, we will allow for all probable systemic limitations, at least among the two major types of systems now running anonymous FTP services.'' Alternately, and just as naively, I propose that all anonymous FTP sites be able to handle files such that their attributes are handled consistently and that complete support for RMS indexed files be required. Neither my naive proposal, nor the clearly Unix-specific proposals, are in the best interest of the Internet. A consistent, basically platform-independent, design, with all probabilities taken into account as the standard is developed is {\em the} prerequisite for a ``{\em de facto} standard.'' Third, while certain characters are provided for and reserved as having ``special significance'' (i.e., `@', `!', `$\mid$', or`\_'), the period (`.') is omitted. From {\tt draft.part.I} (line 393{\em ff}): \begin{verbatim} f) Care should be taken when naming or renaming files in archives. The truism that names should be meaningful takes on a greater significance in this environment since this is often all that the remote user has to work with when trying to discover the contents of the file without actually retrieving it. If one is caching a file from another FTP site, renaming is usually not recommended since the ability to determine if the two files contain identical information can be lost. Some operating systems allow the use of whitespace and non printable characters in filenames but their use is strongly discouraged since this can make the file inaccessible to the remote user. Additionally, characters such as '@', '!', '|', or "_" may not be available or may have special significance on remote systems and should be used with caution. \end{verbatim} Under VMS, the period is a {\em very special} character as each filename must have {\em one and only one} in it --- again, a (quite serious!) complaint. I believe that our implicit agreement to utilize consistent file dates across archival sites is a much more practical solution. Additionally, if we consider the actual limitations various filenames can cause and realistically work to preclude them, this problem is solved. \section{Closing} I have already gone on too long on this. I apologize if I have bored you, but the three points immediately above --- {\em alone!} --- lead me to believe that much more work is required on the IAFA draft, if it is to indeed be a ``{\em de facto} standard.'' It is my opinion that, in its brief existence, TWG has already successfully addressed more meaningful coordination aspects than the IAFA has even begun to think about. There are more faults and limitations, some being very picky in nature (I do not believe any of the above is picky --- technical, yes; picky, no), and that in its present form, the information included, rather than the structure proposed, is the real meat of the IAFA drafts. Creating a draft which assumes the world will standardize to Unix is equally as impractical and wasteful as creating a draft which assumes the world will standardize to VMS --- I desire neither; I desire a standard which is, by default, useful to all. Ultimately, I would hope that the TWG 92-05 could provide a proposal to the TUG Technical Council, to be passed on to the TUG Board of Directors, a standard, which TUG, the Technical Council, or the TWG could provide to the RFC editors as the definitive and authoritative RFC on how \TeX-related archives should be structured and managed. This, however, is not a pressing goal as I believe we have more work to do on a variety of topics. As noted early on, I would very much appreciate it if my thoughts could be passed along. From my experience, I either cannot connect to {\tt cc.mcgill.ca} or it to {\tt SHSU}; or the IAFA simply has decided to exclude me for some reason; or the IAFA has decided to work without regard to standards as they can be applied across multiple platforms. In closing, please allow me to thank you for your time, patience, and assistance in allowing me to state the following: it is my opinion that this group is {\em very} far ahead of the game with respect to the real topics anonymous FTP sites need to consider for true integration. \end{document} From ITeX-Mgr@SHSU.edu Mon Jun 29 13:00:49 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05010; Mon, 29 Jun 92 13:00:44 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.EDU (MX V3.1B) with SMTP; Mon, 29 Jun 1992 13:42:55 CDT Received: from plot79.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04847; Mon, 29 Jun 92 12:41:33 MDT Date: Mon, 29 Jun 92 12:41:33 MDT From: "Nelson H. F. Beebe" Reply-To: TWG@SHSU.edu To: twg@shsu.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Remarks on IAFA guidelines, and on George Greenwade's comments Message-Id: I have just finished reading George Greenwade's comments on the IAFA guidelines for anonymous ftp sites. I too had several reservations and criticisms of their drafts, and sent six messages to them over the weekend. Their documents indeed do emphasize UNIX systems, and say little about other operating systems. I was unhappy at their proposal for the use of letter case in distinguishing certain files, because most non-UNIX file systems ignore letter case. I feel strongly that Internet anonymous ftp archives should be available to everyone, not just those who run a particular operating system. The 14-char limit on filenames that they propose is because some AT&T UNIX derivatives still have this as a holdover from UNIX implementations of the early 1970s on PDP-11 systems. Our Stardent 1520 is one example. POSIX regrettably requires only 14 in a name, and 255 in a path. Fortunately, the major UNIX vendors, including DEC, HP, IBM, Silicon Graphics, and Sun, have all added support for long file names (generally 1024 chars in the complete path, and 256 chars in a single name). Such severe limitations are regrettable; we have learned from 36 years of Fortran that 6-char names are a significant barrier to code development, and 14 aren't enough either. As an informative experiment on our Sun file server (about 1100 users), I scanned the fast-find data base that is reconstructed nightly and found 298054 files; just listing their names takes 15.4MB. Of these files, 21458 (7%) had names (exclusive of path) longer than 14 chars. The frequency of name lengths is itself interesting; here is a multicolumn table of pairs of (name-length number-of-files-with-that-name-length): 77 1 57 2 47 3 39 61 31 598 23 470 15 3909 07 29690 70 1 54 1 46 5 38 40 30 471 22 537 14 7202 06 24992 67 1 53 2 45 5 37 93 29 497 21 651 13 9770 05 22402 64 1 52 1 44 7 36 57 28 348 20 830 12 20887 04 13374 63 1 51 2 43 8 35 68 27 540 19 1441 11 27990 03 7033 61 2 50 3 42 26 34 193 26 388 18 1867 10 34689 02 2084 60 2 49 4 41 16 33 205 25 421 17 2522 09 36375 01 590 59 2 48 5 40 22 32 184 24 320 16 3662 08 40477 00 2 58 1 The two files with length zero are files named by one or more blanks; this is an artifact of the awk program used to produce this table, which by default discarded blanks. The number of files with quite long names is perhaps surprising; the longest is this one of 77 chars: !home!csc-sun!c!fogelson!plat!ring2d!full2d!dr10b_d3!nmsol!commun!ns!sprfor.f It is a lock file created by GNU Emacs to record an edit-in-progress of the corresponding file with ! replaced by /. Some other long ones are Copying_and_Moving_Directories_and_Files matm0.lst-c-sun-sparcstation-2-noopt-cg89 human-computer-interaction:A Human Activity Approach to User Interfaces RegisterTextBufferScanFunctions.3 Although I've tried to limit the use of long names in the anonymous ftp tree, of the 3924 files in that tree I found 467 files (12%) with names longer than 14 chars. 365 of these files have more than one period in them; all but 28 of these 365 have the .z (== .Z) compression suffix. As for file name character sets, UNIX assigns special significance only to / and ; thus, with an 8-bit character set, there are 254 legal filename characters. Of course, some of these are hard (or impossible) to type, and several receive special interpretation by command shells, so they must be quoted in practice. Although most UNIX compilers enforce certain naming conventions of particular dotted suffixes for files, the UNIX filesystem itself has no such requirements. On DEC operating systems (RSX, RT11, TOPS-10, TOPS-20, VMS, and likely others), periods have always been significant in file names, and limited in number to one or two. CP/M and MS DOS file naming conventions seem to be derived from DEC's early systems, and they too limit use of periods. The apparent inability of George to get subscribed to the IAFA mailing list is upsetting; I'd be inclined to get on the telephone with one of the committee members to find out why. I saw nothing to indicate that the list membership should be restricted, and even if it were, maintainers of sizable archives should still be permitted to be members. Nevertheless, I think we should view the IAFA guidelines as a start, and offer the committee constructive criticism. On Saturday, I therefore added these files IAFA-DESCRIPT IAFA-LARCHIVE IAFA-MAILLISTS IAFA-SERVICES IAFA-SITEINFO to ~ftp/pub on ftp.math.utah.edu (via anonymous ftp, "cd pub"). My experiences preparing them led to the several feedback messages alluded to earlier. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: +1 801 581 5254 FAX: +1 801 581 4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Sat Jun 27 16:32:00 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24446; Sat, 27 Jun 92 16:31:56 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.EDU (MX V3.1B) with SMTP; Sat, 27 Jun 1992 17:31:23 CDT Received: from plot79.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22598; Sat, 27 Jun 92 16:19:25 MDT Date: Sat, 27 Jun 92 16:19:25 MDT From: "Nelson H. F. Beebe" Reply-To: TWG@SHSU.edu To: tex-archive@math.utah.edu, twg@shsu.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: zoo 2.10 -- new ports available Message-Id: I've installed zoo 2.10 on SunOS 4.1.1 and DECstation ULTRIX 4.2 today, and made new ports to Silicon Graphics IRIX 4.0.1 and Stardent 1520 OS 2.2. The new versions are available on ftp.math.utah.edu in ~ftp/pub/misc (with anonymous ftp, "cd pub/misc"): -rw-r--r-- 1 beebe staff 5358 Jun 27 16:00 zoo-2-10.tar-lst -rw-r--r-- 1 beebe staff 256345 Jun 27 16:00 zoo-2-10.tar.z -rw-r--r-- 1 beebe staff 227010 Jun 27 15:58 zoo-2-10.zip -rw-r--r-- 1 beebe staff 7015 Jun 27 15:59 zoo-2-10.zip-lst -rw-r--r-- 1 beebe staff 299951 Jun 27 15:44 zoo-2-10.zoo -rw-r--r-- 1 beebe staff 5955 Jun 27 15:56 zoo-2-10.zoo-lst Via e-mail, "send index from ftp/misc" to tuglib@math.utah.edu. That directory also contains a directory subtree zoo/v2-01 and zoo/v2-10 with individual source files for bootstrapping convenience for sites that lack tar, zip, and zoo. The zoo210.exe file is a self-unbundling archive for IBM PC DOS; it does NOT incorporate the source changes for today's port. The changed files in zoo/v2-10 are: -rw-r--r-- 1 beebe staff 10624 Jun 27 15:44 makefile -rw-r--r-- 1 beebe staff 1628 Jun 27 15:32 machine.c -rw-r--r-- 1 beebe staff 2783 Jun 27 14:39 portable.h -rw-r--r-- 1 beebe staff 9170 Jun 27 14:34 options.h and the zoo/v2-10/RCS directory contains earlier versions under rcs control. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Fri Jun 26 11:07:45 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04711; Fri, 26 Jun 92 11:07:37 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.EDU (MX V3.1B) with SMTP; Fri, 26 Jun 1992 11:51:39 CDT Via: uk.ac.rhbnc.vax; Fri, 26 Jun 1992 17:50:43 +0100 Date: Fri, 26 JUN 92 17:50:57 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: RE: archie (again) Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <2020EED5_000780B0.0095CB016FC9F500$19_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) Many of Joachim's points ring true. But there are two with which I would take issue: 1) Does archie meet our needs? Joachim posits a series of questions which are the sort of trivia one reads only too often in TeXhax and which totally overwhelms C.T.T (which is why I've stopped reading the latter; you can't separate the wood from the trees). But these are questions that _users_ ask; the sort of questions which I assert that _we_ (as service providers) ask is "Where can I find a copy of , or perhaps something that refers to ?". And while Archie isn't perfect for this, it's a darn sight better than nothing! 2) WAIS: it looks wonderful, and I have a copy on my PS/2. But that references WLIBSOCK.DLL, which is part of a Novell proprietary network kit, and which I therefore don't have. So, a summary as of this moment: Archie works, and is free (to users); it's presumably still free to providers if they don't want to upgrade. WAIS doesn't work, because it lacks a vital proprietary bit for MS/DOS users; to make it work, it would cease to be free. Conclusions: wouldn't it be better for a few service providers to pay a fee to licence Archie than for all MS/DOS users to have to pay a fee to licence Novell? Philip Taylor, RHBNC. From ITeX-Mgr@SHSU.edu Tue Jun 30 04:08:37 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04624; Tue, 30 Jun 92 04:08:35 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from dir.nott.ac.uk by Niord.SHSU.EDU (MX V3.1B) with SMTP; Tue, 30 Jun 1992 05:05:36 CDT Received: from mips.nott.ac.uk by dir.nott.ac.uk with SMTP (PP) id <9196-0@dir.nott.ac.uk>; Tue, 30 Jun 1992 11:05:18 +0100 To: TWG@shsu.edu Subject: Re: archie (again) In-Reply-To: Message from CHAA006@uk.ac.rhbnc.vax of 27 Jun 92 17:11:13 BST X-Organization: Cripps Computing Centre, University of Nottingham X-Postal: University Park, Nottingham NG7 2RD, UK X-Phone: +44 (602) 484848 ext 2064 Date: Tue, 30 Jun 92 11:05:18 +0100 Message-Id: <9360.709898718@mips.nott.ac.uk> From: David Osborne Reply-To: TWG@SHSU.edu In message <2021203C_0033ABE8.0095CBC50D7428C0$27_2@UK.AC.RHBNC.VAX> of 27 Jun 92 17:11:13 BST, CHAA006@uk.ac.rhbnc.vax said: > S, please: now that I have WAIS, what the h@ll do I do with it, and > how do I use it ? Get the Mac version... intuitively easy to use ;-) (and has some decent documentation) --Dave From ITeX-Mgr@SHSU.edu Tue Jun 30 04:28:15 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04711; Tue, 30 Jun 92 04:28:12 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.EDU (MX V3.1B) with SMTP; Tue, 30 Jun 1992 05:27:30 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA07657; Tue, 30 Jun 1992 06:27:23 -0400 Received: by claude.cs.umb.edu (5.65c/1.34) id AA05856; Tue, 30 Jun 1992 06:27:22 -0400 Date: Tue, 30 Jun 1992 06:27:22 -0400 From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <199206301027.AA05856@claude.cs.umb.edu> To: TWG@SHSU.edu Subject: Re: Totally trivial question Creating a (moderated) tex-announce list, and setting up a gateway to comp.text.tex.announce (if possible, after the usual Usenet discussion, I suppose), seems like a good idea to me. Perhaps @math.utah.edu? (Nelson?) This brings up another question: mailing lists are scattered everywhere around the world. I wonder if it would be possible to have one central site which knows about them all (and just relays incoming messages to the right place). I suppose it might be too much mail, and/or too much work to postmaster it, though. We should be discussing this on tex-archive. From ITeX-Mgr@SHSU.edu Tue Jun 30 04:55:33 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06565; Tue, 30 Jun 92 04:55:30 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from serv02.ZIB-Berlin.DE by Niord.SHSU.EDU (MX V3.1B) with SMTP; Tue, 30 Jun 1992 05:53:02 CDT Received: from dagobert.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/7.11.91 ) id AA02846; Tue, 30 Jun 92 11:27:35 +0200 Received: from quattro.ZIB-Berlin.DE by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/6.5.92 ) id AA22993; Tue, 30 Jun 92 11:27:28 +0200 Date: Tue, 30 Jun 92 11:27:28 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9206300927.AA22993@sc.zib-berlin.dbp.de> Received: by quattro.ZIB-Berlin.DE (4.1/SMI-4.1) id AA22112; Tue, 30 Jun 92 11:27:16 +0200 To: TWG@SHSU.edu Subject: Re: Totally trivial question In-Reply-To: <0095CD73.212CB940.4654@SHSU.edu> References: <0095CD73.212CB940.4654@SHSU.edu> Reply-To: TWG@SHSU.edu Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin For a big archive I don't think it sensible to announce every item, for the simple reason that the volume of such an announcement list is too high -- both for the people who write the announcements as well as for the people who have to read them. The latter will soon stop reading the announcements, the former be bothered with writing them instead of doing more work on the archives themselves. I don't say that nothing should be announced, but not every single update to a four-line style file. More generally, I doubt that this kind of announcement should be done by mail. Mail should be used for more personal messages, and bulletin board systems for announcements that should be generally available, but are not of interest to all. Back to the point: At Stuttgart, I have given up sending around announcements by mail. Instead, I generate a list of all new files automatically every night (by simply running "grep" on the complete archive listing). This list is available for anonymous FTP. The mail server has a command "last " which sends back the contents of the last n nights' files. At the moment this is restricted to a maximum of 7; I did this after I noticed that some people tried "last 365" shortly after a major restructuring of the archive. One idea that might be worth implementing is the BITNET/EARN Listserv FUI/AFD feature: This allows users to request either update File Update Information (FUI), or Automatic File Distribution (AFD) whenever a certain file changes. Listserv implements this on a file basis, but one could, of course, implement the idea of package updates, or whatever. Rainer Sch"opf From ITeX-Mgr@SHSU.edu Tue Jun 30 07:49:08 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07116; Tue, 30 Jun 92 07:49:02 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.EDU (MX V3.1B) with SMTP; Tue, 30 Jun 1992 08:47:43 CDT Received: from plot79.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07104; Tue, 30 Jun 92 07:47:25 MDT Date: Tue, 30 Jun 92 07:47:25 MDT From: "Nelson H. F. Beebe" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 In-Reply-To: Your message of Mon, 29 Jun 1992 20:29:48 CDT Subject: NO to yet another archive list Message-Id: My own preference for announcements of new software is to use existing lists, like TeXhax, comp.text.tex, uktex, et al, rather than create yet another list. Our Usenet newsfeed brings in 1630 newsgroups at present. This volume of material is overwhelming. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: +1 801 581 5254 FAX: +1 801 581 4148 Internet: beebe@math.utah.edu ======================================================================== From ITeX-Mgr@SHSU.edu Tue Jun 30 08:02:46 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07202; Tue, 30 Jun 92 08:02:35 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.EDU (MX V3.1B) with SMTP; Tue, 30 Jun 1992 09:01:05 CDT Via: uk.ac.rhbnc.vax; Tue, 30 Jun 1992 14:58:59 +0100 Date: Tue, 30 JUN 92 14:59:22 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <2020A4A4_00076930.0095CE0E21940320$18_3@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: $TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) >>> Get the Mac version... intuitively easy to use ;-) >>> (and has some decent documentation) Sorry, tried that: DOS reports `%SYSTEM-F-INVOPCODE, image contains invalid opcode -IMAGEACT-W-NONNATIVE, non native mode code, -IMAGEANAL-I-RAINWEAR, Macintosh images cannot run on real computers.' ** P. From ITeX-Mgr@SHSU.edu Tue Jun 30 08:22:11 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07308; Tue, 30 Jun 92 08:22:07 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from MATH.AMS.COM by Niord.SHSU.EDU (MX V3.1B) with SMTP; Tue, 30 Jun 1992 09:15:25 CDT Received: from MATH.AMS.COM by MATH.AMS.COM (PMDF #2306 ) id <01GLTKWXW6HS8WW802@MATH.AMS.COM>; Tue, 30 Jun 1992 10:14:25 EST Date: 30 Jun 1992 10:14:24 -0400 (EDT) From: bbeeton Reply-To: TWG@SHSU.edu Subject: Re: NO to yet another archive list In-Reply-To: To: TWG@SHSU.edu Message-Id: <709913664.795481.BNB@MATH.AMS.COM> Content-Transfer-Encoding: 7BIT Mail-System-Version: i find the current postings on *major* packages useful (though sometimes the multiple copies are a bit much). for smaller items, individual announcements would be overkill, but i like rainer's "last n days" approach, and also the ability to be put on a listserv to get update information on selected items. if such facilities are publicized in a prominent section of the tex faq (or family of faqs, as it's now growing to be), and the faqs are prominently publicized in headers or trailers of the existing lists, perhaps people can be encouraged to do their own research. i realize i probably have a bit more "elbow room" for disk storage than many users, but i find certain local facilities to be useful to others here at ams, and not just me. every few months i get a listing of what's at several archives (so far: labrea, aston and stuttgart in full, selective areas from shsu and ymir, though if i found a full current files list at either place, i'd ftp it back), install it in an known area, and publicize it to the local tech/tex group. then if we're looking for something, we can check the listings locally before resorting to ftp. by the way, it shouldn't be assumed that every list is a newsgroup; we still don't have news access, and must resort to secondary routes. blessings on george greenwade, info-tex, and ctt-digest. -- bb From ITeX-Mgr@SHSU.edu Tue Jun 30 08:47:40 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07407; Tue, 30 Jun 92 08:47:31 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.EDU (MX V3.1B) with SMTP; Tue, 30 Jun 1992 09:27:08 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA41995 (5.65c/IDA-1.4.4 for ); Tue, 30 Jun 1992 16:26:48 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA10463; Tue, 30 Jun 92 16:26:47 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9206301426.AA10463@hp5.iti.informatik.th-darmstadt.de> Subject: Re: your mail To: TWG@SHSU.edu Date: Tue, 30 Jun 92 16:26:46 MESZ In-Reply-To: <2020A4A4_00076930.0095CE0E21940320$18_3@UK.AC.RHBNC.VAX>; from "CHAA006@VAX.RHBNC.AC.UK" at Jun 30, 92 2:59 pm X-Mailer: ELM [version 2.3 PL11] Phil wrote: > > >>> Get the Mac version... intuitively easy to use ;-) > >>> (and has some decent documentation) > > Sorry, tried that: DOS reports > > `%SYSTEM-F-INVOPCODE, image contains invalid opcode > -IMAGEACT-W-NONNATIVE, non native mode code, > -IMAGEANAL-I-RAINWEAR, Macintosh images cannot run on real computers.' Hey! Where is this DOS system available per ftp? (I asked archie for VMS-DOS, and did not found anything. ;-) After all, VMS comes close to a real system... Oh no, I forgot: Not for free, and it will surely be too expensive. Alone the documentation will cost $$$$... :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) -- Joachim PS: Is this nonsense (I like nonsense :-) archived somewhere? From ITeX-Mgr@SHSU.edu Tue Jun 30 09:07:28 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07524; Tue, 30 Jun 92 09:07:11 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 6390; Tue, 30 Jun 1992 10:04:29 CDT Date: Tue, 30 Jun 1992 10:04:17 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095CDE4.E9509E20.6390@SHSU.edu> Subject: Re: your mail On Tue, 30 Jun 92 16:26:46 MESZ, Joachim Schrod posted: > Hey! Where is this DOS system available per ftp? (I asked archie for > VMS-DOS, and did not found anything. ;-) After all, VMS comes close to a > real system... Oh no, I forgot: Not for free, and it will surely be too > expensive. Alone the documentation will cost $$$$... VMS-DOS was called CP/M, a very fine, but now dead OS which I continue to champion (I really champion strange things, don't i?) 8-) > PS: Is this nonsense (I like nonsense :-) archived somewhere? Assuming you mean the TWG discussions, they are in the directory [FILESERV.TWG] on Niord.SHSU.edu [192.92.115.8] as TWG.yyyy-mm (i.e, TWG.1992-06 is the June, 1992, archives of our discussion so far; tomorrow, we will begin TWG.1992-07). Tomorrow (or soon, anyway), I will run my indexer program on the TWG.1992-06 file to generate an index alphabetized by subjects listing indicating associated line numbers and place it in TWG.1992-06-INDEX. Regards, George (who likes nonsense, too, especially among technically adept people who are working too hard on a volunteer effort) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From ITeX-Mgr@SHSU.edu Tue Jun 30 09:54:03 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07888; Tue, 30 Jun 92 09:54:00 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from serv02.ZIB-Berlin.DE by Niord.SHSU.EDU (MX V3.1B) with SMTP; Tue, 30 Jun 1992 10:46:42 CDT Received: from dagobert.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/7.11.91 ) id AA04278; Tue, 30 Jun 92 17:37:14 +0200 Received: from quattro.ZIB-Berlin.DE by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/6.5.92 ) id AA23298; Tue, 30 Jun 92 17:37:08 +0200 Date: Tue, 30 Jun 92 17:37:08 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9206301537.AA23298@sc.zib-berlin.dbp.de> Received: by quattro.ZIB-Berlin.DE (4.1/SMI-4.1) id AA23344; Tue, 30 Jun 92 17:36:58 +0200 To: TWG@SHSU.edu Subject: Re: your mail In-Reply-To: <0095CDE4.E9509E20.6390@SHSU.edu> References: <0095CDE4.E9509E20.6390@SHSU.edu> Reply-To: TWG@SHSU.edu Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin "George D. Greenwade" writes: > Regards, George (who likes nonsense, too, especially among technically > adept people who are working too hard on a volunteer effort) Have all of you already a copy of "The New Hacker's Dictionary", ed. Eric S. Raymond, cover by Duane Bibby? This might be useful prerequisite for *any* discussion. (Ever seen what happens when a water powered computer dumps core?) Rainer From ITeX-Mgr@SHSU.edu Tue Jun 30 09:57:37 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07937; Tue, 30 Jun 92 09:57:33 MDT Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.EDU (MX V3.1B) with SMTP; Tue, 30 Jun 1992 10:29:08 CDT Via: uk.ac.rhbnc.vax; Tue, 30 Jun 1992 16:28:06 +0100 Date: Tue, 30 JUN 92 16:28:29 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: VMS for DOS: this part _not_ a joke ... Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <2020A4A4_0030EBF8.0095CE1A9447E920$18_9@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) >>> Hey! Where is this DOS system available per ftp? (I asked archie for >>> VMS-DOS, and did not found anything. ;-) After all, VMS comes close >>> to a real system... Oh no, I forgot: Not for free, and it will surely >>> be too expensive. Alone the documentation will cost $$$$... >From WENDIN: PCVMS\tm: The Personal Operating System for Applications Programmers. Wendin Inc., Box 266 Cheney, WA 99004 U.S.A. My copy's dated 1985: I don't know if it's still extant. ** Phil. From ITeX-Mgr@SHSU.edu Tue Jun 30 09:11:54 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07551; Tue, 30 Jun 92 09:11:49 MDT Message-Id: <9206301511.AA07551@math.utah.edu> Errors-To: ITeX-Mgr@SHSU.edu Errors-To: ITeX-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.EDU (MX V3.1B) with SMTP; Tue, 30 Jun 1992 09:41:07 CDT Via: uk.ac.rhbnc.vax; Tue, 30 Jun 1992 15:39:27 +0100 Date: Tue, 30 Jun 92 15:39 BST From: "Philip Taylor (RHBNC) " Reply-To: TWG@SHSU.edu To: TWG Subject: RE: NO to yet another archive list >>> My own preference for announcements of new software is to use existing >>> lists, like TeXhax, comp.text.tex, uktex, et al, rather than create >>> yet another list. Our Usenet newsfeed brings in 1630 newsgroups at >>> present. This volume of material is overwhelming. I hate to disagree with Nelson [well, in public :-)], but my preference would be for the converse. I really do feel that there is such a duplication of material pertaining to announcements (and some other topics) at the moment that a gigantic overhaul is required. On the other hand, the time may not yet be ripe for such a change. If our work in TWG is successful, and if we succeed in establishing mirroring for the major TeX archives, then I do believe that a single list containing all archive announcements will be highly beneficial. In the meantime, I would advocate two changes: 1) A reduction in the content of announcements. Deprecated: has kindly sent me a new copy of his/her latest release of , which I have added to the archive. is a package which performs , and which is compatible with and . Separate versions for and have been created. The new files are Preferred: New version of . Files updated: 2) No cross-posting. it is not clear to me why (e.g.) UK-TeX carries announcements about some archives other than Aston (but not others). UK-TeX should (IMHO) restrict itself to UK matters; there are quite enough other lists for interested parties to track other archives. If necessary, summarise the other mailing lists in the trailers. In the future: find some way to filter out the dross! C.T.T. is plagued by trivial queries, the answers to almost all of which could be found in a FAQ. For years I have advocated (a lone voice in the wilderness) that LaTeX & TeX queries warrant separate lists: I would now add to that a wish that anomolous implementations (e.g. some of the Macintosh implementations) should be filtered out to a list of their own (as emTeX is already, and emTeX isn't even anomolous, apart from its ability to use FLI files!). Only-slightly-tongue-in-cheek suggestion: shut down _all_ the generic TeX lists (C.T.T, TeXhax, TeX-Archive, UK-TeX, ...) and start again: TeX.Generic.Trivia platform-independent queries TeX.Generic.Advanced " ditto for LaTeX " TeX.for.Macintoshes platform-specific queries TeX.for.PCs " etc. ** Phil. From TWG-Mgr@SHSU.edu Wed Jul 1 01:13:26 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01711; Wed, 1 Jul 92 01:13:23 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from CBROWN.CLAREMONT.EDU by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 01 Jul 1992 02:02:56 CDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GLU1CA5ZEI9FM7K3@HMCVAX.CLAREMONT.EDU>; Tue, 30 Jun 1992 17:46 PDT Date: Tue, 30 Jun 1992 17:46 PDT From: Don Hosek Reply-To: TWG@SHSU.edu Subject: Files list at ymir To: TWG@SHSU.edu Message-Id: <01GLU1CA5ZEI9FM7K3@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"TWG@SHSU.edu" With regard to Barbara's posting which mentioned her desire for a complete file listing for ymir, the big problem is simply that such a listing was _huge_ when I discontinued it. Far too big for almost every mailer to handle and big enough that it couldn't make it through some FTP gateways as well. Given the current diskspace shortage at ymir, this is not likely to change anytime soon. -dh From TWG-Mgr@SHSU.edu Wed Jul 1 07:58:32 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03469; Wed, 1 Jul 92 07:58:26 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 8830; Wed, 01 Jul 1992 08:55:52 CDT Date: Wed, 01 Jul 1992 08:55:11 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095CEA4.6C3BBB20.8830@SHSU.edu> Subject: RE: NO to yet another archive list On Tue, 30 Jun 92 15:39 BST, Philip Taylor posted: > I really do feel that there is such a duplication of material pertaining to > announcements (and some other topics) at the moment that a gigantic > overhaul is required. On the other hand, the time may not yet be ripe for > such a change. If our work in TWG is successful, and if we succeed in > establishing mirroring for the major TeX archives, then I do believe that a > single list containing all archive announcements will be highly beneficial. Which is why I brought the topic up -- I wanted this type of debate and feedback. I agree that there is enormous overlap (and I am a major perpetrator). However, if the mirroring is successful, along with a maintained FAQ family and Macro Index, virtually every question of "where do I get to do ; I looked at and its files were completely out-of-date or missing" will be easily answered by "look at the , then get them from your nearest mirror site" possibly including a list of sites involved in the mirroring network. Note, though, that the time for this may not be right now as the mirroring is an absolutely necessary (if not sufficient) condition for this suggestion to work. This, in my view, is a result to be considered from the project. > In the meantime, I would advocate two changes: > > 1) A reduction in the content of announcements. > > Deprecated: has kindly sent me a new copy of his/her > latest release of , which I have added to the archive. > is a package which performs , and which is compatible > with and . Separate versions for and > have been created. The new files are > > Preferred: New version of . Files updated: I disagree with this, to an extent. For pure updates (especially frequent updates, such as new betatest files to emTeX), the "Preferred" example above is completely proper. However, I have found that quite often, this is, at best, cryptic for new files and new packages. The practice I follow (which can certainly be changed; nothing is carved in stone as far as I am concerned) of creating a comprehensive description file, posting it, then retaining it for remote users to retrieve is sort of a best of both worlds. First, the package is described and advertised ("you mean someone really did that; great!, it exactly answers my needs so I better look at it"). Second, it is there for future reference. The top-level *.DESCRIPTION files on Niord are these, and they are returned via e-mail as a result of a DIRECTORY/LIST package_name request command to FILESERV. As Rainer pointed out, creating such files is time-consuming. I have found that well over 70% of new submissions to SHSU are accompanied by an announcement from the author, though. Since it's their package, they are usually more than willing to properly (and semi-concisely) describe it to the public. In these cases, my editing time is usually under two minutes, primarily focusing on spelling, proper command sequence, and the file listing. In other cases, I often use the already-included README files as a template. Those might take up to 10 minutes. Even Barbara has guessed (bnb: I'm not committing you to anything here!) that the AMS might write and provide better descriptive documentation if a known directory structure and file placement scheme were in place across all archives. If that monolith might move in that direction, I imagine we can get others to do similarly. Who wants their package to look bad? A possible solution, if mirroring can be established, is a weekly or semi-monthly digest of description files, as a separate list to those interested. Unless I have missed my calculations completely, with 8 mirror sites, everything ought to be on every machine within 42 hours under normal circumstances. Therefore, if, once a package has been loaded on its home machine in the mirror network (i.e., the firt site to load the package), the announcement is not made for, say, 60 hours (i.e., the lag for inclusion in my proposed digest of updates), every mirror site ought to have the files handy by the time they are openly and publicly announced. For this, I would propose the creation of a newsgroup, comp.text.tex.archives to be linked to a mail distribution (for those who do not have news access, have unreliable access, or simply prefer a single mail posting to reading news -- about half of the ctt-Digest subscribers have news, but prefer the daily digestified format, BTW). > 2) No cross-posting. it is not clear to me why (e.g.) UK-TeX carries > announcements about some archives other than Aston (but not others). > UK-TeX should (IMHO) restrict itself to UK matters; there are quite > enough other lists for interested parties to track other archives. > If necessary, summarise the other mailing lists in the trailers. Again, I am probably the major perpetrator here. I submit what I submit for the editors to do with as they please. What's interesting (at least to me) is that about 20% of our general FILESERV activity is UK-based. This is even true when the same issue of UKTeX includes a statement that the files are now at Aston and I can see from the lag in activity that those retrieving the files are probably doing so as a result of the UKTeX article. > In the future: find some way to filter out the dross! C.T.T. is plagued by > trivial queries, the answers to almost all of which could be found in a > FAQ. For years I have advocated (a lone voice in the wilderness) that LaTeX > & TeX queries warrant separate lists: I would now add to that a wish that > anomolous implementations (e.g. some of the Macintosh implementations) > should be filtered out to a list of their own (as emTeX is already, and > emTeX isn't even anomolous, apart from its ability to use FLI files!). I hesitate to join in this criticism. I agree that an awful lot of c.t.t could be easily answer by simply reading the FAQ family, but news is news. I really hesitate to separate LaTeX from TeX discussions as quite a few LaTeX users are often unaware of the TeX implications/features at their disposal (I will openly admit that I didn't realize that I could TeX within LaTeX for about 18 months -- I was using LaTeX, not TeX, so....). What may be needed is (a) mailing support lists to be created for those special implementations which ought to have them, and emTeX has been a model here; and (b) a more comprehensive listing of what lists do exist -- I fear that far too many users are unaware of the resources which already exist. Topic (a) above requires some time, causes some splintering, and requires some network resources (as I have learned first-hand). Topic (b) could easily be recitfied by a routine inclusion (say, every tenth issue ending with a 5) as a trailer to UKTeX or TeXhax (who really cares about the long-winded distribution network still included in TeXhax now that it's moved to a non-LISTSERV site? -- I know LISTSERV still plays a large role, but it even states that it's a best guess and not a known distribution system). I can make the list of TeX-related lists Barbara provided to me available to anyone with an interest -- I may soon carry it as a routine posting on ctt-Digest. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From TWG-Mgr@SHSU.edu Wed Jul 1 14:29:11 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06495; Wed, 1 Jul 92 14:29:05 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 01 Jul 1992 11:41:36 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA27933; Wed, 1 Jul 1992 12:40:42 -0400 Received: by claude.cs.umb.edu (5.65c/1.34) id AA06818; Wed, 1 Jul 1992 12:40:40 -0400 Date: Wed, 1 Jul 1992 12:40:40 -0400 From: karl@cs.umb.edu (Karl Berry) Message-Id: <199207011640.AA06818@claude.cs.umb.edu> To: TWG@SHSU.edu In-Reply-To: Rainer Schoepf's message of Mon, 29 Jun 92 11:22:17 +0200 <9206290922.AA21786@sc.zib-berlin.dbp.de> Subject: Lots of answers Reply-To: TWG@SHSU.edu 1) Case: all names should be either lowercase (like on Unix), or uppercase (like on VMS). I agree with Rainer that names should be monocase. I further feel strongly that they should be lowercase; on all-uppercase systems, lowercase names will be automatically converted. But on mixed-case systems, uppercase names won't be. File names should stick to the 8+3 limit, or at least be unique when truncated to 8+3. Filenames which are actually used in a .tex or other source file shouldn't need to be truncated; cf. the titlepage/titlepag nonsense. 4) Line length: From my experience, a limit of 72 characters per line 72? It would be difficult for me, at least, to restrict myself to this. I use 79, since Emacs doesn't display 80-character lines properly. Are there really mailers which munge lines of length between 72 and 80? Users tend to expect those things that they think are important on a higher level of the tree. But different users think different things are important. Not everything can be at the top-level. Therefore, it is important to have, e.g, LaTeX on a higher level than phyzzx and ytex I disagree. I think a scheme which puts packages into their logical places will be easier, in the long run, for users to use and maintainers to maintain. 8a) tex-archive/fonts: I think there should be subdirectories pk, vf, tfm, perhaps gf, ... that contain all the relevant files. For pk and gf, this means that there is one subdirectory per output device. Per Metafont mode, really. I think the modes should be the top level, with pk, vf, tfm, etc. below. Who cares all the PK files in the world, per se? 8c) Why is developers a subdir of user-groups? Personally, I thought that was a nice idea. 8e) I find the supported/unsupported distinction immensely useful, since people see the distinction before they fetch the file. Do you actually want to know *before* you fetch the file? I'm only interested in this when I find a bug or have a suggestion. It's not going to affect my decision about whether to get the file or not. 8f) I'm not sure that the distinction between printer drivers and previewers is a useful one. What do you do with programs that offer both choices? I agree, the drivers/ directory (like all others), I think, should simply have subdirectories for each package. From TWG-Mgr@SHSU.edu Thu Jul 2 10:01:36 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16395; Thu, 2 Jul 92 10:01:33 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 02 Jul 1992 06:13:20 CDT Via: uk.ac.rhbnc.vax; Thu, 2 Jul 1992 12:12:15 +0100 Date: Thu, 2 JUL 92 12:12:43 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: RE: Lots of answers Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <202120E0_001832B0.0095CF892E585DA0$17_6@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) [It's nice to agree with Karl again; I feel I've been disagreeing with him far too often recently :-)] >>> I further feel strongly that they should be lowercase; Agree. >>> Filenames which are actually used in a .tex or other source file >>> shouldn't need to be truncated; cf. the titlepage/titlepag nonsense. Not sure what this means: if I \input PostScript on my VMS system, I get PostScript.TeX; if I \input PostScript on my MS/DOS system, I get PostScri.TeX, which is just fine, since when I copy PostScript.TeX to my MS/DOS system, it ends up being called PostScri.TeX automatically (courtesy of DOS); what could be better ? >>> 72? It would be difficult for me, at least, to restrict myself to this. I feel the same about 79! But if we're _really_ trying to solve problems for others, then it's no harder for me to wrap at 72 than at 79 or 80; why is 72 a problem for you, Karl? >>> I disagree. I think a scheme which puts packages into their logical >>> places will be easier, in the long run, for users to use and >>> maintainers to maintain. Strongly agree. >>> Per Metafont mode, really. I think the modes should be the top level, >>> with pk, vf, tfm, etc. below. Who cares all the PK files in the world, >>> per se? But TFMs are mode-independent, and therefore can't come below mode: Fonts -> MF -> Tfm -> Mode -> PK -> GF -> PS etc ? >>> I agree, the drivers/ directory (like all others), I think, should >>> simply have subdirectories for each package. Agree. ** Phil. From TWG-Mgr@SHSU.edu Thu Jul 2 16:39:57 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20011; Thu, 2 Jul 92 16:39:51 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from serv02.ZIB-Berlin.DE by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 02 Jul 1992 14:17:03 CDT Received: from dagobert.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/7.11.91 ) id AA11766; Thu, 2 Jul 92 11:55:43 +0200 Received: from quattro.ZIB-Berlin.DE by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/6.5.92 ) id AA25132; Thu, 2 Jul 92 11:55:36 +0200 Date: Thu, 2 Jul 92 11:55:36 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9207020955.AA25132@sc.zib-berlin.dbp.de> Received: by quattro.ZIB-Berlin.DE (4.1/SMI-4.1) id AA25993; Thu, 2 Jul 92 11:55:21 +0200 To: TWG@SHSU.edu Subject: Re: Lots of answers In-Reply-To: <199207011640.AA06818@claude.cs.umb.edu> References: <199207011640.AA06818@claude.cs.umb.edu> <9206290922.AA21786@sc.zib-berlin.dbp.de> Reply-To: TWG@SHSU.edu Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin Karl Berry writes: > 4) Line length: From my experience, a limit of 72 characters per line > > 72? It would be difficult for me, at least, to restrict myself to > this. I use 79, since Emacs doesn't display 80-character lines > properly. Are there really mailers which munge lines of length between > 72 and 80? I don't know for sure that they still exist, but that's only part of the problem: Lines with a length of more than 72 are not so easily or not properly displayed on some machines. So, for the same reason that Karl advocates <=79, I advocate <=72. By the way, I normally use a linelength of 120 in emacs. To restrict myself to at most 72 characters, I use features like auto-fill-mode, and immediately prior to release some elisp code that shows me the long lines. I'm sure that other editors have similar features. > 8a) tex-archive/fonts: I think there should be subdirectories pk, vf, > tfm, perhaps gf, ... that contain all the relevant files. For pk > and gf, this means that there is one subdirectory per output device. > > Per Metafont mode, really. I think the modes should be the top level, > with pk, vf, tfm, etc. below. Who cares all the PK files in the world, > per se? Why should tfm files go below modes? They don't depend on the mode, do they? Where do you put, say, pk-files generated from PostScript outlines? How do they fit into the Metafont modes directory structure? > 8c) Why is developers a subdir of user-groups? > > Personally, I thought that was a nice idea. I still don't understand it. I regard this as a ``category error' as Phil calls it. > 8e) I find the supported/unsupported distinction immensely useful, > since people see the distinction before they fetch the file. > > Do you actually want to know *before* you fetch the file? I'm only > interested in this when I find a bug or have a suggestion. It's not > going to affect my decision about whether to get the file or not. Yes, I do want to know. I use unsupported files only with great reluctance, and I suppose this is true for many others, especially if they are not programmers or don't have the TeX expertise to fix things that are broken. Rainer Sch"opf From TWG-Mgr@SHSU.edu Fri Jul 3 11:07:23 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26292; Fri, 3 Jul 92 11:07:21 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 03 Jul 1992 09:02:05 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA25496; Fri, 3 Jul 1992 06:31:55 -0400 Received: by claude.cs.umb.edu (5.65c/1.34) id AA10773; Fri, 3 Jul 1992 06:31:53 -0400 Date: Fri, 3 Jul 1992 06:31:53 -0400 From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <199207031031.AA10773@claude.cs.umb.edu> To: TWG@SHSU.edu Subject: font hierarchy It was a dumb idea to propose TFM's under each mode. I didn't intend to propose that, the words just slipped out. How about this: subdirectories in fonts/ for each typeface, or perhaps each vendors. Subdirectories under each of those for MF, TFM, PK, etc: fonts/ fonts/euler fonts/euler/tfm fonts/euler/pk ... fonts/adobe fonts/adobe/times fonts/adobe/times/tfm fonts/adobe/times/pk ... I would suggest using my abbreviations from the `Font naming scheme', but I fear they are too cryptic for most users. From TWG-Mgr@SHSU.edu Fri Jul 3 11:15:55 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26332; Fri, 3 Jul 92 11:15:52 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 03 Jul 1992 09:02:15 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA25507; Fri, 3 Jul 1992 06:34:02 -0400 Received: by claude.cs.umb.edu (5.65c/1.34) id AA10776; Fri, 3 Jul 1992 06:34:01 -0400 Date: Fri, 3 Jul 1992 06:34:01 -0400 From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <199207031034.AA10776@claude.cs.umb.edu> To: TWG@SHSU.edu Subject: line length I think an 80 character line length is by orders of magnitude the most common limit. If so, it will be impossible to get the millions of people who use that to restrict themselves to 72. I don't think we can control this in advance, anyway. Are you really going to turn files away because they have lines longer than 72 characters? I sure hope not. I tried disciplining myself to 72 characters for a while in Eplain, but it was just impossible. I can't explain why (I mean, I literally can't). Sorry. From TWG-Mgr@SHSU.edu Fri Jul 3 11:39:47 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26519; Fri, 3 Jul 92 11:39:44 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 16382; Fri, 03 Jul 1992 10:44:46 CDT Date: Fri, 03 Jul 1992 10:44:44 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095D046.0EF345C0.16382@SHSU.edu> Subject: RE: font hierarchy On Fri, 3 Jul 1992 06:31:53 -0400, Karl Berry posted: > subdirectories in fonts/ for each typeface, or perhaps each vendors. > Subdirectories under each of those for MF, TFM, PK, etc: I'm glad this topic is finally being discussed. As you saw in my earlier naive proposal, I really haven't a clue compared to the font specialists we have here. On a related topic: > I would suggest using my abbreviations from the `Font naming scheme', but I > fear they are too cryptic for most users. I disagree! We can easily make the font naming scheme document available for users to retrieve as a reference (either in help or in the top level of fonts). If the archival sites follow that structure and users have to use it to get what they want, acceptance of a standardized naming scheme may be easier to pursue (unless these are unacceptable proposed standards, which I do not think that they are). --George From TWG-Mgr@SHSU.edu Fri Jul 3 11:44:11 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26560; Fri, 3 Jul 92 11:44:09 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 03 Jul 1992 12:42:17 CDT Via: uk.ac.rhbnc.vax; Fri, 3 Jul 1992 18:41:19 +0100 Date: Fri, 3 JUL 92 18:41:50 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: RE: font hierarchy Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <22C00636_00076838.0095D088B49856E0$55_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) Karl --- >>> How about this: >>> subdirectories in fonts/ for each typeface, or perhaps each >>> vendors. Subdirectories under each of those for MF, TFM, PK, etc: >>> fonts/ >>> fonts/euler >>> fonts/euler/tfm >>> fonts/euler/pk >>> ... >>> fonts/adobe >>> fonts/adobe/times >>> fonts/adobe/times/tfm >>> fonts/adobe/times/pk >>> ... I think this omits a vital element: the underlying font generation mechamism. I'd extend it to: fonts/ fonts/metafont fonts/postscript fonts/metafont/concrete fonts/metafont/computer-modern fonts/metafont/euler fonts/metafont/levy-greek fonts/postscript/adobe fonts/postscript/itc fonts/postscript/monotype fonts/metafont/computer-modern/gf fonts/metafont/computer-modern/mf fonts/metafont/computer-modern/pk fonts/metafont/computer-modern/tfm fonts/metafont/computer-modern/pk/canon fonts/metafont/computer-modern/pk/ricoh fonts/metafont/computer-modern/pk/linotronic >>> I would suggest using my abbreviations from the `Font naming scheme', >>> but I fear they are too cryptic for most users. I'd agree! ** Phil. From TWG-Mgr@SHSU.edu Fri Jul 3 11:51:08 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26602; Fri, 3 Jul 92 11:51:05 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 03 Jul 1992 09:02:30 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA25614; Fri, 3 Jul 1992 06:40:20 -0400 Received: by claude.cs.umb.edu (5.65c/1.34) id AA10782; Fri, 3 Jul 1992 06:40:19 -0400 Date: Fri, 3 Jul 1992 06:40:19 -0400 From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <199207031040.AA10782@claude.cs.umb.edu> To: TWG@SHSU.edu Subject: directory hierarchy Developers are users, aren't they? They are group of TeX-ies with a common interest, hence udner user-groups seems reasonable. Rainer, your philosophy and mine differ dramatically, I think -- I want to absolutely minimize the number of top-level directories (and other directories), and you want to put the most common things (latex, say) at the top. I think George's directory structure even now has too many top-level directories, even before we start adding latex/, developers/, ... I would like to put all of books, tutorials, periodicals under a single doc/, for example. Maybe put bibliography, indexing, graphics under a new directory aux-support/, although I feel less sure of myself about that. As for the supported/unsupported distinction, it would have to be made for every directory. It seems a waste to me to force everyone to go through an extra directory layer to get to what they want. Also, I know some people (don't know if it's most) don't have any idea whether something is supported or not; heck, for most macro files, I wouldn't myself. This means they have to guess which directory to look in first. Half the time they'll guess wrong. Therefore, my feeling was, eliminate the distinction. Then the archive users won't have to guess, and get frustrated trying to find things. K From TWG-Mgr@SHSU.edu Fri Jul 3 12:08:20 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26660; Fri, 3 Jul 92 12:08:17 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from MATH.AMS.COM by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 03 Jul 1992 13:04:33 CDT Received: from MATH.AMS.COM by MATH.AMS.COM (PMDF #2306 ) id <01GLXZ9J07BK8ZE20P@MATH.AMS.COM>; Fri, 3 Jul 1992 13:50:18 EST Date: 03 Jul 1992 13:50:18 -0400 (EDT) From: bbeeton Reply-To: TWG@SHSU.edu Subject: Re: line length In-Reply-To: <199207031034.AA10776@claude.cs.umb.edu> To: TWG@SHSU.edu Message-Id: <710185818.236810.BNB@MATH.AMS.COM> Content-Transfer-Encoding: 7BIT Mail-System-Version: regarding limits on line length, 80 may be the most common limit, but there are gateways that split lines *between 79 and 80*. if the character in column 80 just happens to be a period, that can be quite detrimental to the remainder of the file. (there are also gateways that simply truncate. i really hate dealing with files that have been attacked in either way because the creator of the file wasn't careful, and it's one of the most senseless time-wasters that i've run across.) too bad if the restriction is inconvenient to some users, it really should be enforced (though i don't know how) for the general good and the sanity of the archivists, who are going to be getting the questions when something goes wrong. -- bb From TWG-Mgr@SHSU.edu Fri Jul 3 19:31:04 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02046; Fri, 3 Jul 92 19:31:02 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from theory.lcs.mit.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 03 Jul 1992 19:54:13 CDT Received: from GYRFALCON.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA03085; Fri, 03 Jul 92 20:53:56 EDT From: dmjones@theory.lcs.mit.edu (David M. Jones) Reply-To: TWG@SHSU.edu Received: by gyrfalcon.lcs.mit.edu (5.65c/TOC-1.2C) id AA24838; Fri, 03 Jul 92 20:53:43 EDT Date: Fri, 03 Jul 92 20:53:43 EDT Message-Id: <199207040053.AA24838@gyrfalcon.lcs.mit.edu> To: TWG@SHSU.edu In-Reply-To: Joachim Schrod's message of Fri, 26 Jun 92 18:15:14 MESZ <9206261615.AA02878@hp5.iti.informatik.th-darmstadt.de> Subject: archie (again) Joachim, Thanks for the information about archie, even if the news was distressing. One comment, though: > Btw, someone mentioned that Stuttgart would not be in the >database. The database stores always the primary name. So Stuttgart >is not listed as ftp.uni-stuttgart.de or rusinfo.rus.uni-stuttgart.de, >but as rusmv1.rus.uni-stuttgart.de. Actually, this doesn't quite solve the mystery. As of 16 Jun 1992 the only machine with "stuttgart" in the name listed by quiche.cs.mcgill.ca is ifi.informatik.uni-stuttgart.de [129.69.211.1]. David. From TWG-Mgr@SHSU.edu Fri Jul 3 19:33:46 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02073; Fri, 3 Jul 92 19:33:41 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from theory.lcs.mit.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 03 Jul 1992 19:27:05 CDT Received: from GYRFALCON.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA03059; Fri, 03 Jul 92 20:26:52 EDT From: dmjones@theory.lcs.mit.edu (David M. Jones) Reply-To: TWG@SHSU.edu Received: by gyrfalcon.lcs.mit.edu (5.65c/TOC-1.2C) id AA24657; Fri, 03 Jul 92 20:26:40 EDT Date: Fri, 03 Jul 92 20:26:40 EDT Message-Id: <199207040026.AA24657@gyrfalcon.lcs.mit.edu> To: TWG@SHSU.edu In-Reply-To: "George D. Greenwade"'s message of Mon, 22 Jun 1992 12:35:00 CDT <0095C7B0.A4244660.13194@SHSU.edu> Subject: Filedates > Using Unix's touch utility (I assume Unix calls >such things utilities), Actually, I think the proper term is "utlts". (Sorry, just a little UNIX humor.) >This brings me to a few critical questions. I'm going to be presumptuous and respond to this, mostly in hopes that when I expose my ignorance someone will correct all my misconceptions and I'll get a better idea of how the proposed mirroring scheme would work. >1. I assume that in mirroring, a common time is desired. If so, shall the >time of original deposit to an archive site (say, in the incoming directory >-- which I omitted in the last outline of the directory structure) or the >time of the classification into the proper directory be the one reported? As I understand it, there are basically two ways that a file can come into a CTA: 1) It is deposited there by the author of the macros, much as most macros find their ways onto archives currently. 2) The CTA automatically picks it up from one of the STA's that it mirrors. In the case 2, the filedate from the the STA should be preserved. In case 1, it seems simplest to just use the time at which the files are classified into the proper directory, since the files will be effectively invisible until then. (One could make a case that the filedate used should be the one on the copy on the author's machine, but how would you implement such a thing?) However, I have another question: in the mirroring scheme that George outlined earlier, it might take as long as 60 hours for a new version of a file to make it to one of the CTA's. What will be the effect of dumping a file on a machine with a write date 60 hours in the past? In particular, how would this effect the schemes for automatically compiling lists of all files added in the last 24 hours? >2. What is a suggested procedure for handling the case of parallel file >names (such as subeqn.sty). Shall the author be notified and (s)he >requested to re-name it, shall it be something unilateral by an archive >maintainer, or shall holy intervention preclude such things from occurring? I think we should implement the holy intervention protocol. Are there any deities on the list? Barring that, contacting the author seems like the right idea. It occurs to me that there are other (less serious?) things that might warrant contacting the author, namely, 1) lack of some sort of standardized header containing "sufficient" information about the package (even if we haven't agreed upon the syntax of the headers yet, I hope we all agree that some sort of standard set information is necessary) 2) violations of reasonable file format limits, like lines > 72 characters long. 3) file names that violate the 8+3 limit 4) bad coding practices (Ok, ok, I'm kidding.) >3. Will one site be responsible for classifying all incoming files into a >"proper" directory and filename or will each site classify the files it >receives? Presumably this should be done by the first CTA to receive the package. Why do this 8 times? This brings up another question: to what extent can the classification be made automatic? I suppose that if everyone had Beebe-style headers, you could write a program to examine the header and place the file in the correct place. Presumably for at least some files on some STA's the classification will be automatic: anything showing up in e-math.ams.com:ams/amslatex/inputs belongs in the AMS-LaTeX inputs directory, for example. David. From TWG-Mgr@SHSU.edu Sat Jul 4 06:49:43 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05715; Sat, 4 Jul 92 06:49:41 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Sat, 04 Jul 1992 06:28:29 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA06732; Sat, 4 Jul 1992 07:27:06 -0400 Received: by claude.cs.umb.edu (5.65c/1.34) id AA11397; Sat, 4 Jul 1992 07:27:05 -0400 Date: Sat, 4 Jul 1992 07:27:05 -0400 From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <199207041127.AA11397@claude.cs.umb.edu> To: TWG@SHSU.edu Subject: RE: font hierarchy Peter, Why is the font generation mechanism vital, as in fonts/metafont fonts/postscript In fact, I'm not entirely sure what you mean by `font generation mechanism'. I can't imagine when there would be a conflict. No doubt this is just a lack of imagination on my part. Please enlighten me. PostScript files can go in a subdirectory ps/ or postscript/ or pfa/ or something, by analogy with pk/, tfm/, etc. Ditto for Bitstream's speedo/ fonts, Sun's F3 format, etc., etc. From TWG-Mgr@SHSU.edu Sat Jul 4 06:53:52 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05721; Sat, 4 Jul 92 06:53:50 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Sat, 04 Jul 1992 07:03:42 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA06838; Sat, 4 Jul 1992 07:43:40 -0400 Received: by claude.cs.umb.edu (5.65c/1.34) id AA11425; Sat, 4 Jul 1992 07:43:39 -0400 Date: Sat, 4 Jul 1992 07:43:39 -0400 From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <199207041143.AA11425@claude.cs.umb.edu> To: TWG@SHSU.edu Subject: Re: line length Barbara, There is a big difference for me between <80 and <73. I don't have any trouble respecting the former limit; I have lots of trouble with the latter. tex.web and thousands of other existing files have lines > 72. I trust we are not proposing that they all be rewritten! Have the archivists received numerous complaints about lines >72? If not, I suggest this is a non-issue, and we should simply stick to <80. If so, then how are the offending files being dealt with now? Are the files in the archives now with lines >79 characters? If so, then how many people complain about those? That will tell us how strictly we should enforce such a limit. From TWG-Mgr@SHSU.edu Sat Jul 4 06:54:34 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05726; Sat, 4 Jul 92 06:54:32 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Sat, 04 Jul 1992 07:03:29 CDT Received: from claude.cs.umb.edu by cs.umb.edu (5.65c/1.34) id AA06743; Sat, 4 Jul 1992 07:30:17 -0400 Received: by claude.cs.umb.edu (5.65c/1.34) id AA11403; Sat, 4 Jul 1992 07:30:16 -0400 Date: Sat, 4 Jul 1992 07:30:16 -0400 From: karl@cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <199207041130.AA11403@claude.cs.umb.edu> To: TWG@SHSU.edu Subject: RE: font hierarchy George, you suggest that my fontnames can be used for the directory names. My feeling was that there's no reason for the user to have to learn these cryptic abbreviations to get to the typeface we want; we've already agreed that the archive directory names will be longer than 8 characters. On the other hand, the font files themselves should probably follow ``my'' scheme (I wish I had named it, I always feel like I'm being so egotistical when I call it mine, ~rwhen so many other people contributed), since they (the font files) should be restricted to 8+3 where possible. I exclude widely-available fonts which already have well-established names, like Computer Modern and Euler. It would be pointless to change those names in the archive. From TWG-Mgr@SHSU.edu Sat Jul 4 07:26:08 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05876; Sat, 4 Jul 92 07:26:06 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from VAX01.AMS.COM by Niord.SHSU.edu (MX V3.1B) with SMTP; Sat, 04 Jul 1992 08:26:55 CDT Received: from MATH.AMS.COM by MATH.AMS.COM (PMDF #2306 ) id <01GLZ50HPPCW8WVYVC@MATH.AMS.COM>; Sat, 4 Jul 1992 09:25:11 EST Date: 04 Jul 1992 09:25:10 -0400 (EDT) From: bbeeton Reply-To: TWG@SHSU.edu Subject: Re: line length In-Reply-To: <199207041143.AA11425@claude.cs.umb.edu> To: TWG@SHSU.edu Message-Id: <710256310.957355.BNB@MATH.AMS.COM> Content-Transfer-Encoding: 7BIT Mail-System-Version: karl, i believe there are indeed some files in the archives with lines >79 characters; i certainly receive messages via ctt-digest that have longer lines, and i know those are now archived at shsu. i'm not actually advocating changing files that are now in the archives, but setting up guidelines for authors (and others) who submit files to the archives. perhaps a volunteer could be found to check new submissions to see that they follow the guidelines, and if they don't, to ask for repairs before installation. as for items i receive through the mail that are trashed because of longer lines, i don't usually complain unless the object was something i requested directly -- i simply haven't got time. fortunately, i can usually use ftp to retrieve files, so my problems are minimized, but i used to be in the mail-or-kermit class, and i remember it too well. i believe that problems are likely to be greatest when the gateways involved include ibm mainframes, as is often the case with bitnet transmissions, so more weight should be given to the opinion of someone with firsthand knowledge of that milieu. any takers? -- bb From TWG-Mgr@SHSU.edu Sat Jul 4 10:53:54 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06319; Sat, 4 Jul 92 10:53:40 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Sat, 04 Jul 1992 11:54:20 CDT Received: from plot79.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06314; Sat, 4 Jul 92 10:52:53 MDT Date: Sat, 4 Jul 92 10:52:53 MDT From: "Nelson H. F. Beebe" Reply-To: TWG@SHSU.edu To: twg@shsu.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Line lengths in archives Message-Id: Recent discussions have debated whether it is feasible to limit line lengths in archive files to no more than 72 or 80. There are three objections to long lines: (1) Some deficient mail gateways, notably on IBM mainframe systems, truncate mail messages to 80 chars (because such messages are foolishly stored in fixed-length record files, which is definitely not a necessity on those operating systems). (2) Except on windowing systems, the standard character display width on terminals and personal computers is 80 characters. Lines that are longer than the display width may be wrapped, or worse, truncated by display software and text editors. (3) Long lines seriously detract from readability. In my view, (1) and (2) are technological limits that are rapidly disappearing. A mail server such as tuglib automatically encodes files with long lines to avoid truncation loss. No FTP systems that I am aware of cause such loss. The most important really is (3); it does not matter for files that are generally read only by computer programs (e.g. LaTeX .aux, .toc, .lot, .lof, .ind, and .idx files). To find out what the status quo is, I wrote a couple of small awk programs to find files with lines longer than 80 chars in our TeX, Metafont, and Web2C directories. I found no such lines in tex/ams/amstex, tex/ams/amslatex, tex/ams/amstex/doc, mf/macros, or web2c subdirectories other than those listed below. Here are file names and the length of the longest line in the file; there are 87 such files. Directory tex/latex: cropmark.sty: 99 texindex.pas: 85 mf-errata.doc: 95 vdm.doc: 85 tex-errata.doc: 93 vdm.sty: 85 espo.sty: 91 moretext.sty: 83 uut11.sty: 91 supertab.doc: 83 latexinfo.sty: 89 clscmemo.sty: 82 ltexpprt.tex: 89 merge.sty: 82 oval.ltx: 89 numinsec.sty: 82 lcl-fixes.sty: 88 siam10.sty: 82 local-fixes.sty: 88 siam11.sty: 82 00dir.lst: 87 vdm.tex: 82 00tdir.lst: 87 dvialw.sty: 81 lfonts.scaled-fonts-tex: 87 fixup.sty: 81 lfonts.scaled: 87 latex.dif: 81 sampl1.ltx: 86 uuthesis.sty: 81 supertab.sty: 85 Directory tex/inputs: vgrindefs: 97 ptexpprt.tex: 84 psfig.tex: 88 psfonts.sty: 82 dvialw.ini: 86 latex-page-layout.ltx: 81 calendar.tex: 85 pagelayout.ltx: 81 life.tex: 85 siamptex.sty: 81 Directory tex/ams/amslatex/doc: amslatex.tex: 89 testart.tex: 84 amsart.doc: 85 Directory web2c/src-5.851c/bibtex: convert: 81 small.diff: 81 Directory web2c/src-5.851c/mf: mf.web: 83 mfd.h.bak: 81 cmf.ch: 82 small.diff: 81 mf.ch: 82 Directory web2c/src-5.851c/mf/MFwindow: sun-suntools.c: 93 uniterm.c: 85 Directory web2c/src-5.851c/mfware: gftodvi.web: 86 Directory web2c/src-5.851c/tex: small.diff: 82 Directory web2c/src-5.851c/lib: alloca.c: 92 getopt.c: 81 texmfmem.h: 82 Directory web2c/src-5.851c/man: mf.man: 97 Directory web2c/src-5.851c/web2c: web2c.yacc: 83 Directory mf/cm: Makefile.imagen: 95 msxm7.mf: 82 cyrrem.mf: 93 msxm8.mf: 82 cyruc.mf: 91 msxm9.mf: 82 cyrlc.mf: 90 msym10.mf: 82 cyrnum.mf: 88 msym5.mf: 82 punkl.mf: 88 msym6.mf: 82 cyrpunc.mf: 86 msym7.mf: 82 punkae.mf: 85 msym8.mf: 82 mkf: 83 msym9.mf: 82 ysymbols.mf: 83 punkg.mf: 82 cyrspec.mf: 82 punkp.mf: 81 msxm10.mf: 82 punksl.mf: 81 msxm5.mf: 82 xsymbols.mf: 81 msxm6.mf: 82 ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: +1 801 581 5254 FAX: +1 801 581 4148 Internet: beebe@math.utah.edu ======================================================================== From TWG-Mgr@SHSU.edu Sat Jul 4 12:31:44 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06446; Sat, 4 Jul 92 12:31:41 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from math.utah.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Sat, 04 Jul 1992 13:25:23 CDT Received: from plot79.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06439; Sat, 4 Jul 92 12:23:59 MDT Date: Sat, 4 Jul 92 12:23:59 MDT From: "Nelson H. F. Beebe" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 X-Fax: (801) 581-4148 Subject: Re: Line lengths in archives In-Reply-To: Your message of 04 Jul 1992 13:24:41 -0400 (EDT) Message-Id: Thanks for pointing out the obsolescent *.mf files; they were indeed old, and I've moved them into an `old' subdirectory: v old total 310 -rw-r--r-- 1 beebe staff 2311 Aug 15 1985 msxm10.mf -rw-r--r-- 1 beebe staff 2280 Aug 15 1985 msxm5.mf -rw-r--r-- 1 beebe staff 2275 Aug 15 1985 msxm6.mf -rw-r--r-- 1 beebe staff 2265 Aug 15 1985 msxm7.mf -rw-r--r-- 1 beebe staff 2283 Aug 15 1985 msxm8.mf -rw-r--r-- 1 beebe staff 2308 Aug 15 1985 msxm9.mf -rw-r--r-- 1 beebe staff 2311 Aug 15 1985 msym10.mf -rw-r--r-- 1 beebe staff 2280 Aug 15 1985 msym5.mf -rw-r--r-- 1 beebe staff 2275 Aug 15 1985 msym6.mf -rw-r--r-- 1 beebe staff 2271 Aug 15 1985 msym7.mf -rw-r--r-- 1 beebe staff 2283 Aug 15 1985 msym8.mf -rw-r--r-- 1 beebe staff 2308 Aug 15 1985 msym9.mf -rw-r--r-- 1 beebe staff 61092 Aug 11 1985 xsymbols.mf -rw-r--r-- 1 beebe staff 60002 Aug 11 1985 ysymbols.mf There are no references to them in any of the cm/*.mf or cm/Makefile files. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: +1 801 581 5254 FAX: +1 801 581 4148 Internet: beebe@math.utah.edu ======================================================================== From TWG-Mgr@SHSU.edu Sun Jul 5 13:55:50 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11873; Sun, 5 Jul 92 13:55:39 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 18930; Sun, 05 Jul 1992 14:55:57 CDT Date: Sun, 05 Jul 1992 14:55:56 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095D1FB.7B543380.18930@SHSU.edu> Subject: Re: line length On Sat, 4 Jul 1992 07:43:39 -0400, Karl Berry posted: > There is a big difference for me between <80 and <73. I don't have any > trouble respecting the former limit; I have lots of trouble with the > latter. > > Have the archivists received numerous complaints about lines >72? If not, > I suggest this is a non-issue, and we should simply stick to <80. If so, > then how are the offending files being dealt with now? > > Are the files in the archives now with lines >79 characters? If so, then > how many people complain about those? That will tell us how strictly we > should enforce such a limit. Yes. Editing. Yes. A more than few, but primarily me. The issue of line length is one which is clearly important, but creates a whole other area which I had hoped to avoid (clearly, we haven't). I had hoped to avoid it because it is more an issue of how to properly prepare files moreso than how to write or archive files. Clearly, some appropriate outline of what we expect to be deposited, at least in suggested format, is in order. In this regard, I would support some statement such as (a) keep your line lengths to some agreed to maximum whenever possible, (b) use the standardized file headers, (c) include checksums, and (d) provide somewhere (at a minimum) at least a low level of description and examples of usage. The issue of line length is one which has impact on mailer-oriented archiving, but little on ftp-related archiving (at least as far as I am aware). Line lengths come into play (BTW, in answer to David's question, as far as I am concerned, everyone on this list rates as a diety -- at best, I'm a mere distributor of your dieties' work) (a) when it includes a "." in column 81 and nothing is subsequent columns, which wraps to a single line containing a "." in it and nothing else (the SMTP signal for end of file), or (b) when you hit a gateway/mailer which refuses to wrap anything and abends the line at column 80 (which a few do, although this is in violation of RFC 822). In fact, I would guess that well over 90% of the problems I encounter are related to DNS problems, host registration, inadequate disk storage for requested files, etc., than file lengths and EOF problems. I am the first to know when a file fits criterion (a) above since I get all bounced mail from FILESERV. Immediately, I go in and somehow edit the line(s) causing the EOF signal. Occasionally, this means padding the line, breaking the line, or concatenating prior lines somehow to fit "better". I handle enough mail daily not to be generating error messages knowingly. When criterion (b) is involved, I attempt to contact the postmaster (cc'ing the user) to inform them that their mail is inappropriately behaving. The (a)s of the world are controllable; the (b)s are not. This brings me to a related point -- I don't have the TUGboat cite handy, but (*very* large assumption here) assuming that the CTAs have a somewhat parallel mail user interface, mightn't we ought to use VV*CODE (or some other ASCII'izer encoder) by default on everything which is outbound? This would solve many (if not all) of the line-length-related problems, although I admit that it does make one more step in the file retrieval process for the end user. In other words, while a number of sites presently support an "encode" (or something similar) option, I would propose that encoding be automagic and a "no-encode" option be provided. Ultimately, just how a person writes a file is that person's business. Clearly, we can shape that business, but accepting or not accepting a file because of line length seems a little hard-nosed (unless we follow the comp.sources. distributions and place everything into it's own archive, which is then handled its own way -- I vote NO on this!). If, in the proposed 4 point guidelines file I discussed earlier (there are bound to be more than those 4 points, but those are the important ones which come to mind on a hot Sunday afternoon), we stress the idea of manageable line length, I imagine we can shape future submissions. I personally use a line length of 78 since it gets through mail and allows at least one space for the 79-character emacs (if you wish, I will reduce it). However, when I get into, say, TPU (which, by design, handles line breaks awfully, if at all) I use line lengths of up to 400 characters. The 72 a few of you have discussed seems a little terse -- I can understand less than 80, and in my experience 78 has been a reasonable alternative. I can be swayed on this, but the creation of a proper "submissions guide", which takes the largest probabilities of problems, into account is the nexus to everything. Also, remember that we are discussing the future in this -- then things which now exist will continue to exist; it is those which are not here yet which I am most concerned about as this is the work I hope we can help spawn. --George From TWG-Mgr@SHSU.edu Tue Jul 7 05:25:44 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26561; Tue, 7 Jul 92 05:25:40 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 07 Jul 1992 06:26:05 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA33656 (5.65c/IDA-1.4.4 for ); Tue, 7 Jul 1992 13:24:09 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA05909; Tue, 7 Jul 92 13:24:08 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9207071124.AA05909@hp5.iti.informatik.th-darmstadt.de> Subject: TeX announcements To: twg@shsu.edu (TUG TWG --- Archives) Date: Tue, 7 Jul 92 13:24:07 MESZ X-Mailer: ELM [version 2.3 PL11] George asked about the creation of a mail-list / TeX announcement newsgroup (in this mail I will hitherto call it a `group') where additions to the major archives can be posted. This list should be intended for the general user, not for archivists (that's the intent of tex-archive, as far as I understand). In principle, I'm in favor of such a mailing-list/group; under a minor condition: The announcements *must* not be cross-posted / gatewayed to any other list. I'm in favor of such a group because I would *not* subscribe to it (as we all do, I read tex-archive). IMO this is a valid reason: I hope that such a group would cut down the traffic in other groups I read. Btw, for the same reason I has always raised my voice against a split of comp.text.tex. Most people would not know where to post their questions and would crosspost them anyhow. -- Joachim From TWG-Mgr@SHSU.edu Tue Jul 7 07:16:16 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26958; Tue, 7 Jul 92 07:16:09 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 23643; Tue, 07 Jul 1992 08:15:24 CDT Date: Tue, 07 Jul 1992 08:15:16 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095D355.D74211C0.23643@SHSU.edu> Subject: RE: TeX announcements On Tue, 7 Jul 92 13:24:07 MESZ, Joachim Schrod posted: > George asked about the creation of a mail-list / TeX announcement newsgroup > (in this mail I will hitherto call it a `group') where additions to the > major archives can be posted. This list should be intended for the general > user, not for archivists (that's the intent of tex-archive, as far as I > understand). > > In principle, I'm in favor of such a mailing-list/group; under a minor > condition: > > The announcements *must* not be cross-posted / gatewayed to any > other list. Precisely! The idea was to create a source for this information aimed at the end user only. Moreover, given a single list address, it is possible to restrict posting by anyone other than a well-known pre-defined set of users, at least on the mail side (how I handle ctt-Digest), such as only >From a CTA archive coordinator. One assumption I am continually operating under here is that a network of CTA's can be created, with each CTA being responsible for routinely polling and updating from its specified STAs (if that's not a workable assumption, please point it out). The presence of this assumption clears an awful lot of work since what can be announced for one site can effectively be announced for all CTA sites, in addition to the authoritative STA site (won't that be network Nirvana?). In that context, it may be that we can eventually get *all* announcements isolated to this list, since I am making the very heroic assumption that authors of packages will desire to be in their authoritative STA (which someone coordinating a CTA simply needs to know about -- i.e., one and only one post from the author to a single coordinator), as well as the CTA network. For coordinators of CTAs, the announcements will be trivial as the files will already be at their sites (however, coordinators might want to know what the updates are and this will provide a source of information on that). I am not attempting to minimize tex-archive as I hope that, once the groundwork is laid by TWG, the main TeX-related archiving discussion can return to tex-archive's broader audience and TWG can serve as an archival network-related support list only (i.e, primarily populated by CTA coordinators and a few others with significant interest). If we are successful in this venture, the present ways of getting information about archives, packages, who is up-to-date and who isn't, announcing changes, etc., will all go the way of the Edsel -- a few uninitiated might keep the old ways, but we can change the behavior of a large part the population we service. Please keep this in mind -- we are potentially shaping the next millenium of TeX archiving (if not a framework for network archiving in whole) and it can easily be quite different than what we have experienced over the past two decades if we are successful. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From TWG-Mgr@SHSU.edu Tue Jul 7 14:09:54 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01136; Tue, 7 Jul 92 14:09:47 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 07 Jul 1992 13:50:18 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA34891 (5.65c/IDA-1.4.4 for ); Tue, 7 Jul 1992 20:47:32 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA07657; Tue, 7 Jul 92 20:47:30 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9207071847.AA07657@hp5.iti.informatik.th-darmstadt.de> Subject: Re: Archie clients To: TWG@SHSU.edu Date: Tue, 7 Jul 92 20:47:29 MESZ In-Reply-To: <0095C4A7.3078E6A0.2299@SHSU.edu>; from "George D. Greenwade" at Jun 18, 92 3:49 pm X-Mailer: ELM [version 2.3 PL11] George wrote: > > Anyway, would anyone have any objection to including the sources (or maybe > the precompiled executables) for Archie clients in the archive-tools area? Yes. (Seems to be my day for disagreements with George... ;-) In general, Archie clients should not be in the TeX tree of an AFA. They have simply nothing to do with TeX. They should be placed somewhere beside it. Eg, we carry archie clients in pub/networking/misc/. Perhaps I will move them to pub/networking/information-retrieval/archie/ in the future (after my holiday :-). The TeX area is really no place for such stuff. But anyhow, I would neither put compression software in the TeX area. These are general tools to be placed in a sibbling tree. -- Joachim From TWG-Mgr@SHSU.edu Tue Jul 7 14:23:39 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01211; Tue, 7 Jul 92 14:23:32 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 07 Jul 1992 14:07:50 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA24790 (5.65c/IDA-1.4.4 for ); Tue, 7 Jul 1992 21:05:26 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA07739; Tue, 7 Jul 92 21:05:23 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9207071905.AA07739@hp5.iti.informatik.th-darmstadt.de> Subject: Re: Filedates To: TWG@SHSU.edu Date: Tue, 7 Jul 92 21:05:21 MESZ In-Reply-To: <0095C7B0.A4244660.13194@SHSU.edu>; from "George D. Greenwade" at Jun 22, 92 12:35 pm X-Mailer: ELM [version 2.3 PL11] Wading through the backlog, I found some notes on filedates. I wanna add some minor comments, how mirror (the perl version from me) handles filedates. First: there is no possibility to get _really_ the same filedates. The ftp protocol has no possibility to ask for a normalized timestamp, let's say in UT (aka GMT). So mirror uses the timestamps it receives from the 'dir' listing as _if_ they were local timestamps. Of course this is reproducable. Except -- when daylight saving times comes into play. Therefore mirror allows a timestamp difference of an hour. That algorithm is not foolproofed -- I had (rare) occasions where mirror fetched files although they were not changed. It was some weird come-together of our DTZ change and the reference hosts change. (I did not care -- mirror transfers each night about 50 MB stuff to Darmstadt anyhow...) -- Joachim From TWG-Mgr@SHSU.edu Tue Jul 7 14:25:42 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01227; Tue, 7 Jul 92 14:25:35 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 07 Jul 1992 14:46:30 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA21536 (5.65c/IDA-1.4.4 for ); Tue, 7 Jul 1992 21:15:53 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA07753; Tue, 7 Jul 92 21:15:51 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9207071915.AA07753@hp5.iti.informatik.th-darmstadt.de> Subject: renaming files To: twg@shsu.edu (TUG TWG --- Archives) Date: Tue, 7 Jul 92 21:15:50 MESZ X-Mailer: ELM [version 2.3 PL11] Yet another note concerning file names: While I'm in favour of guidelines how to setup portable archive names, I'm against changing archive names of foreign packages as long as the underlying operating system allows it. My reasons: 1. It's work. mirror configuration files must be maintained. (I prefer the simple four-line files...) Don't underestimate this maintainance. One needs a strategy from the beginning. Eg, currently I mirror about 150 packages. Don't believe that I know each one by name, not to say by heart... Each mirror configuration file with renaming is a potential source of work. 2. IMHO end users will often not expect it. Eg, if I see latexinfo-v1_4.tar_z on a VMS AFA I think `Ah, only one dot available.' If I see such a file on a UNIX AFA I ask myself what the administrator has done here -- and I'll fetch it from somewhere else where I can be sure it will be the original archive... -- Joachim From TWG-Mgr@SHSU.edu Tue Jul 7 15:21:00 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01855; Tue, 7 Jul 92 15:20:51 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 07 Jul 1992 13:13:52 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA04513 (5.65c/IDA-1.4.4 for ); Tue, 7 Jul 1992 20:11:09 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA07470; Tue, 7 Jul 92 20:11:08 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9207071811.AA07470@hp5.iti.informatik.th-darmstadt.de> Subject: YES to IAFA proposal! To: twg@shsu.edu (TUG TWG --- Archives) Date: Tue, 7 Jul 92 20:11:06 MESZ X-Mailer: ELM [version 2.3 PL11] Hello, This is my last longer statement for a while, because I go on a long US trip on Thursday for 5 weeks. Sorry, but I won't be able to answer to any comments on this statement after Wednesday evening. But as I expect to see several of you in Portland, I would suggest a BOF discussion there. Who will be attending? Anyhow, I didn't want to leave without giving a response to George's statement on the IAFA draft standards. Let me first give you some information on my background. Well, here in Darmstadt, I organize an RS6000 based ftp server with 2 GB material (expecting 3 GB next year), our TeX subarchive is only a very small part with its 100 MB. For the server as a whole, IAFA compliance is of great relevance. In general, if the server as a whole is organized compliant, I won't have a subpart that is not. This, I think, will hold for all the big servers with TeX archives only being part of it. The administrators probably won't be free to choose or will have big argumentative problems to explain why they want another organization, if it is obviously possible for the rest of the server. Btw, concerning the needs of VMS: I was a VMS cluster system administrator for almost 2 years and work with VMS since 9 years, so I think I can talk about its requirements quite well. Now to George's comments on the IAFA paper, I'm under the impression that they were very emotional. George, too much stress with the exams? I can't confirm your problems to get on the list: I was added on request after 3 days. So something must have gone wrong --- I would follow Nelsons proposal of a telephone call. To point out again why I announced the IAFA paper on this list: a) The paper contains hints to the coding of meta informations (description/configuration files, internal descriptions). This seemed of interest to the group -- at least in connection with our discussion about BibTeX vs RFC822 analogous formats. (IAFA suggests the latter :-) b) The paper suggests standard names for some meta files which serve for automatic fetching by retrieval tools like Archie etc. Topic (b) is the one that is of concern for the critique of George. He writes: > Second, a serious limitation of the drafts are their clear > distinction and reliance on case-sensitivity in filenames. I cannot interpret the draft in this way. The IAFA paper contains only a few positive rules about file names. Especially, concerning the non-configuration files, there is only a hint on being careful with renaming. Explicite naming conventions are only given for the configuration files. George cited the corresponding paragraph, here it is again: > For the sake of consistency across operating systems and for the > ability to distinguish them from non-configuration files of the same > name, the filenames will be in all uppercase letters. Because of > restrictions on some systems, filenames will be kept to a maximum of > 14 characters. Though the way this is expressed may be a little bit awkward, to me the intention is clear: Not reliance on case sensitivity, but, on the contrary, specifying that these special files `must always and everywhere be accessible as in all uppercase'. I.e., 'dir' and 'get' must work with the names given in all uppercase to support automatic fetching. Even, more specific, 'dir' should output these files in uppercase (since the listing will be searched). And the restriction to 14 characters is a POSIX restriction. After all, DEC also has commited to POSIX! To show that these demands are no problem on VMS, look at the following ftp log: ftp> dir iafa-descript 200 Port 130,83,5,31,13,224 Okay. 125 File status okay; about to open data connection. THD$HRZHDSK:[YD3P]IAFA-DESCRIPT.;1 1/3 7-JUL-1992 11:12 226 Closing data connection. ftp> get IAFA-DESCRIPT 200 Port 130,83,5,31,13,225 Okay. 125 File status okay; about to open data connection. 226 Closing data connection. 47 bytes received in 0.06 seconds (0.72 Kbytes/s) As you can see, VMS will output the uppercase filename at the 'dir' command and VMS will have no problem with the uppercase filename at the 'get' command. (Of course, it has also no problem with the 14 letter restriction.) So the intended result is here: We can automatically look for the meta files and can fetch them automatically without any problems. To another point of Georges critique: The citation of the only mentioning of VMS is (IMHO) taken out of context. The point that is discussed in the paper there handles security holes for ftp servers and how to avoid them in server installations. This is split up in system specific sections, and the VMS section (and others) is not yet filled up. This may be critizised but has nothing to do with our topic here. In summary, I can't see why George condemns the standard draft. In the points relevant to our problems here, there don't arise any problems. As for the setting up of ftp servers in general, may be you can add something from your VMS experiences to the IAFA group (if you succeed in getting contact ;-), but we should concentrate on setting up rules for (TeX) archive management here. And I suggest to stay compliant with the IAFA draft in the very few points that are relevant for us -- configuration file names and format of such files. -- Joachim PS: It might be that you'll receive a `vacancy' message from me -- that's because I'm already away officially. :-) But I'll read my mail 'till Wednesday evening (early afternoon in the US)... From TWG-Mgr@SHSU.edu Tue Jul 7 15:25:57 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01890; Tue, 7 Jul 92 15:25:47 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 24577; Tue, 07 Jul 1992 14:37:34 CDT Date: Tue, 07 Jul 1992 14:37:25 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095D38B.3A668580.24577@SHSU.edu> Subject: RE: YES to IAFA proposal! On Tue, 7 Jul 92 20:11:06 MESZ, Joachim Schrod posted a defense of the IAFA drafts: > This is my last longer statement for a while, because I go on a long US > trip on Thursday for 5 weeks. Sorry, but I won't be able to answer to any > comments on this statement after Wednesday evening. Hope you trip is fruitful. As things stand now, there is a good chance I will not be in attendance at Portland as I very likely will be in Austin fussing with some legislative committees regarding funding enhancements for our communications network. If at all possible, I will be in attendance and pay at the door, if necessary, as a get-together with those I have imposed myself on would be good for all of us. To be quite honest, I am unaware of the explicit details of everyone's various OS backgrounds. Joachim, I didn't intend to offend you (or anyone!) by even inferring ignorance on any given platform. For the most part, those of you on this list are professionals in various areas of computer-based applications. Indeed, I have very little doubt that I am among the most computer naive among this group. I can tell you many, many things about VMS and MS-DOS, with just enough knowledge of Unix to be dangerous and adequately cursory knowledge of VM/CMS to at least make the machine do the basic things I might want it to (assuming I had to get on one of those). I appreciate Joachim's position to a point. If I am successful in getting the funding we are requesting, TeX (while large) will be but a portion of the SHSU electronic archives. Further, I completely agree that compliance with some standard between archival sites, in general, as well as in particular areas, such as TeX archives, is more than desireable. I fully hope that all area standards will be in accord with the general standards and will work in every manner possible to see to it that this concordance is reached. Regarding the coding of the standard meta information files into BibTeX- or RFC822-type format, I could really care less. Either approach will work, so long as it is a known standard which provides adequate upward flexibility. I've looked at Nelson's filehdr package and it ought to be trivial to design something similar for any construct. The TPU-based variant I am working on now has a somewhat similar design and modifications to fit any given format can be incorporated relatively quickly. Regarding the naming of files, I do get picky! Moreover, I will always be picky on this for any file in a public area. Joachim notes that casing of names is indeed consistent. True. However, I would expect that, more than casing, consistency in what the meta information files are *named* should be of prime importance. While you can SHIFT TO CAPS, why bother??? Among the positive rules about file names, there is still no consistency with respect to portability in file names (again, returning to the "special significance" characters -- bull!). As Joachim notes: > Especially, concerning the non-configuration files, there is only a hint on > being careful with renaming. Why not draft a standard (the equally consistent, but VMS-unusable, filename of draft.part.III possibly?) on the creation of a network standard file parsing translator, which can be built into ftp clients/servers across all platforms? My guess is that this would be incorporated by developers so quickly it would spin your head. Until such a standard for parsing exists, hinting at "careful with renaming" is not adequate. I am of the somewhat strong opinion that files in archives should NEVER be renamed -- period. Among the ftp-specific packages we support, they are in as original shape as I can get them; the FILESERV stuff (which just happens to be in the ftp area) has a hard naming convention I have to meet to make it run. This is being fixed by the authors of our mail/fileserver package as I write this. That opinion opined, the only available option is to create a filename syntax which presents absolutely no reason to ever *have* to rename a file (want to, maybe; have to, no!). Even if this means packing everything in an archive file conformant with prescribed standards which is then unarchived to whatever name you please, it is a possible solution which is more tasteful than having to deal with impossible filenames or (worse, still) two huge files containing parallel material because someone decided to be cute with a filename. If you want to include POSIX as a constraint, fine -- filenames all in a consistent case, containing not more than one period, nor any of the identified "special significance" characters, and limited to 14 characters total. While not happy with this totally, I can live with it. My concern of the lack of VMS (or any other OS) in the present draft is a concern because, from this, I infer (a) not only hasn't this been considered, no real consideration is planned (remember, this is supposed to be *final* in November of this year), (b) it isn't a concern and won't be because we are making Archie-compilant tools which just happen to fit into the context of "network standardization", or (c) the group is working in blissful ignorance, gleefully assuming that everyone will migrate to the Unix standard, no matter how technically impossible it might be on any other platform. I provide that the opinion that what we are trying to accomplish -- sharing coordinated information across continents with a somewhat common interface to end users -- is the real goal any group working on standards *ought* to be addressing. Creating standardized files, defining the contents of those standardized files, and designing a structure which adequately addresses the present and expected future limitations of commonly-used operating systems has to be the proper focus to achieve this. To that end, I agree with the IAFA draft (and Joachim, if I read his message correctly). Given that the IAFA's work is scheduled to be submitted to the RFC editor (in essence, a formal working paper, which could conceivably become an absolute standard -- few achieve this final status), it is very relevant to *a portion* of what we have to deal with. By no means do I want to have any TeX archivist have to argue for running a non-network-standard area on any server. At the same time, if standards are being developed, I don't want to see network standards be factionalized along the lines of operating systems, which is how I see the in-work status of the IAFA at this time. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From TWG-Mgr@SHSU.edu Wed Jul 8 05:18:30 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11744; Wed, 8 Jul 92 05:18:28 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 08 Jul 1992 06:18:29 CDT Via: uk.ac.rhbnc.vax; Wed, 8 Jul 1992 12:16:34 +0100 Date: Wed, 8 JUL 92 12:17:14 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: Re: Archie clients Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <202010F7_00198330.0095D440CE465900$15_4@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) Joachim --- >>> In general, Archie clients should not be in the TeX tree of an AFA. >>> They have simply nothing to do with TeX. They should be placed >>> somewhere beside it. >>> Eg, we carry archie clients in pub/networking/misc/. Perhaps I will >>> move them to pub/networking/information-retrieval/archie/ in the >>> future (after my holiday :-). The TeX area is really no place for >>> such stuff. >>> But anyhow, I would neither put compression software in the TeX >>> area. These are general tools to be placed in a sibbling tree. But there may be archives which are TeX-only; should there not be provision for them too to carry the tools ? ** Phil. From TWG-Mgr@SHSU.edu Wed Jul 8 07:33:12 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12184; Wed, 8 Jul 92 07:33:08 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 26726; Wed, 08 Jul 1992 08:32:58 CDT Date: Wed, 08 Jul 1992 08:32:54 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095D421.788FFF80.26726@SHSU.edu> Subject: Re: Archie clients In response to a posting by Joachim Schrod, Phil Taylor posted: > But there may be archives which are TeX-only; should there not be provision > for them too to carry the tools ? I promise I'm not choosing to pick on Joachim -- his invaluable input as a major network archivist is really appreciated. However, I agree with Phil on this, but for {\em all} archives. My strategy is to support TeX-only archives (such as Aston) with a logical placement within a master tree, as well as supporting the end user. It is easy to link files in Unix or SET FILE/ENTER in VMS. I'll admit you have to be somewhat careful when doing this, but most archival tools I have sugested for inclusion are relatively stable and not numerically large in magnitude. Also, wouldn't it be so much nicer if you, as the end user, could find the right tool within your current tree instead of having to wonder off into some other directory structure which is foreign to you. If we're going to use archival tools, such as compression (zip, zoo, lzw, whatever), archiving sets (DOSTAR, VMSTAR, VMS_SHARE, shareset), encoding (UU*CODE, VV*CODE, atob-btoa), and others, I think it would be beneficial to support them within the proposed standard tree, even if they do not physically reside there. Reagrds, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From TWG-Mgr@SHSU.edu Wed Jul 8 08:57:54 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12546; Wed, 8 Jul 92 08:57:52 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 08 Jul 1992 09:30:43 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA34976 (5.65c/IDA-1.4.4 for ); Wed, 8 Jul 1992 16:28:51 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA09806; Wed, 8 Jul 92 16:28:49 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9207081428.AA09806@hp5.iti.informatik.th-darmstadt.de> Subject: Re: Archie clients To: TWG@SHSU.edu Date: Wed, 8 Jul 92 16:28:48 MESZ In-Reply-To: <202010F7_00198330.0095D440CE465900$15_4@UK.AC.RHBNC.VAX>; from "CHAA006@VAX.RHBNC.AC.UK" at Jul 8, 92 12:17 pm X-Mailer: ELM [version 2.3 PL11] Phil wrote: > > >>> In general, Archie clients should not be in the TeX tree of an AFA. > >>> But anyhow, I would neither put compression software in the TeX > >>> area. These are general tools to be placed in a sibbling tree. > > But there may be archives which are TeX-only; should there not be provision > for them too to carry the tools ? ???? I did never write that they should not carry the tools -- in contrary. For pure TeX archives it's often even simpler, since they know exactly which tools they will need (probably, due to their policy). What I meant is: We consider at the moment the proposal for a logical TeX archive's directory structure. The top-level directory is named tex-archive. (Btw, why not simply tex? Most existing TeX archives use this name already.) This top-level directory is placed somewhere in the AFA tree. -- Sometimes it will be at the very top, ie., it will be /tex-archive (or [TEX-ARCHIVE]). -- More often it will be one level below; like /pub/tex-archive, /soft/tex-archive, or [ANONYMOUS.TEX-ARCHIVE] What's the problem in placing tools (aka utilities), archie software, etc. in a neighbour directory? /tools, /pub/tools, /archie, /pub/archie, /tools/archie, wherever? In my experience a directory starter, placed at a very high level (ie, in /starter or /pub/starter) is also a Good Thing. There users can find all the tools they need for the beginning. We have just created such a directory in Darmstadt. A README can/should be added to give users hints, what they have to do with retrieved files. (As an example, check out /pub/machines/ms-dos/starter/README in Darmstadt. A similar README will be placed in /pub/starter -- Real Soon Now ;-) -- Joachim From TWG-Mgr@SHSU.edu Wed Jul 8 10:29:56 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13259; Wed, 8 Jul 92 10:29:50 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 08 Jul 1992 10:25:31 CDT Via: uk.ac.rhbnc.vax; Wed, 8 Jul 1992 16:23:46 +0100 Date: Wed, 8 JUL 92 16:24:25 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: Re: Archie clients Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <202010F7_00074B40.0095D463566B2140$37_1@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) >>> What's the problem in placing tools (aka utilities), archie software, >>> etc. in a neighbour directory? /tools, /pub/tools, /archie, >>> /pub/archie, /tools/archie, wherever? What I was suggesting (admittedly rather poorly) is that in a TeX-only archive, there may be no provision for `neighbour directories'; i.e. management may have said ``OK, you may export the TeX hierarchy; but I don't want this taken as a precedent, and find next week that you are exporting InterNet-Tools, X-Rated-Pix, etc.'' :-( ** P. From TWG-Mgr@SHSU.edu Wed Jul 8 10:57:29 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13410; Wed, 8 Jul 92 10:57:23 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 08 Jul 1992 10:15:54 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA28807 (5.65c/IDA-1.4.4 for ); Wed, 8 Jul 1992 17:13:49 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA09933; Wed, 8 Jul 92 17:13:43 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9207081513.AA09933@hp5.iti.informatik.th-darmstadt.de> Subject: RE: YES to IAFA proposal! To: TWG@SHSU.edu Date: Wed, 8 Jul 92 17:13:42 MESZ In-Reply-To: <0095D38B.3A668580.24577@SHSU.edu>; from "George D. Greenwade" at Jul 7, 92 2:37 pm X-Mailer: ELM [version 2.3 PL11] George wrote: > > Regarding the naming of files, I do get picky! Moreover, I will always be > picky on this for any file in a public area. Joachim notes that casing of > names is indeed consistent. True. However, I would expect that, more than > casing, consistency in what the meta information files are *named* should > be of prime importance. While you can SHIFT TO CAPS, why bother??? Among > the positive rules about file names, there is still no consistency with > respect to portability in file names (again, returning to the "special > significance" characters -- bull!). Sorry, I don't understand it (literally). What's your position now? When reading your first mail, I thought you would complain that too much is said about file names (especially, too much UNIX specific stuff). Now it seems to me that you complain that too few is said about file names. Seems that my English is not good enough to follow you, may you please elaborate it a bit? I'll try to make my position clearer: -- I want to separate the file name discussion between (1) configuration/meta file names and (2) `other' file names. -- I want to engage in discussion (1), not in (2). -- So, concerning meta file names: -- The portability issue is really important here (IMHO), since such files are accessed (read: checked and fetched) automatically over a wide range of systems. -- For systems with case-sensitive file names, we must define a definitive writing. What are our guidelines? -- On many systems files with uppercase names are at the top of directory listings. Therefore informational files are often named in uppercase. Therefore it is appropriate here to use uppercase. -- The name should not be so long, to be portable over many systems. -- For systems with case-insensitive file names, it does not care which case is used for them, as long as they are listed in the chosen case and we can fetch them (the latter should never be any problem). Since we have no problems with uppercase names, we can use them. My personal viewpoint: Although the proposed names IAFA-DESCRIPT, etc., are representable and accessible on all machines I know, I do not really like them. I think the string '00' (or 'AA') should be attached at the start of the name. Then they would be first on the directory listing of a case-insensitive file name system, too. ('00' is not good, since some systems don't allow file names starting with digits.) > Why not draft a standard (the equally consistent, but VMS-unusable, > filename of draft.part.III possibly?) on the creation of a network standard > file parsing translator, which can be built into ftp clients/servers across > all platforms? My guess is that this would be incorporated by developers > so quickly it would spin your head. My guess is: no, it would not. I would even bet a good bottle of wine (eg, a St.Emillion Grand Cru Class\'e, or something at this level...) on this topic. The SGML standards group (ISO 8879) tried to set up such file name conversion strategies. They abandoned it, unsuccessfully. Remember: standardization should also concentrate on pinning down existing practice; it should be careful in creating new practice, not tried on many systems over a larger time. This is told in many ISO and ANSI rationales, and I find it always a good hint. -- Joachim Btw, concerning SGML: Interessents should note that Darmstadt carries one of the five systematic SGML archives in the world. PD translators to TeX enclosed... I'll post something on that to tex-archive/info-tex when I'm back from holiday. From TWG-Mgr@SHSU.edu Wed Jul 8 11:38:06 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13740; Wed, 8 Jul 92 11:38:03 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from CBROWN.CLAREMONT.EDU by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 08 Jul 1992 12:23:03 CDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GM4S5M2GN49LVFCX@HMCVAX.CLAREMONT.EDU>; Wed, 8 Jul 1992 10:21 PST Date: Wed, 8 Jul 1992 10:21 PST From: Don Hosek Reply-To: TWG@SHSU.edu Subject: Re: YES to IAFA proposal! To: TWG@SHSU.edu Message-Id: <01GM4S5M2GN49LVFCX@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"TWG@SHSU.edu" Regarding 00 at the beginning of file names, which systems do not allow this? The only one that I'm aware of is MVS, not exactly a mover and shaker in the Internet world. I know that I can use it on VMS, Unix, MS-DOS, Tops-20, OS/2, Macintosh, AmigaDOS. Is there much else? Remember that it's only really a concern for systems which aer FTP-connected. And even there it's not too big a deal. Remember that we're not catering to the lowest common denominator but the lowest _reasonable_ common denominator. Never forget that the real LCD file name size is 6+3. (Remember sail?) -dh From TWG-Mgr@SHSU.edu Wed Jul 8 12:47:15 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14235; Wed, 8 Jul 92 12:47:11 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from VAX01.AMS.COM by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 08 Jul 1992 13:33:47 CDT Received: from MATH.AMS.COM by MATH.AMS.COM (PMDF #2306 ) id <01GM50H7ZIW09GV9B2@MATH.AMS.COM>; Wed, 8 Jul 1992 14:31:40 EST Date: 08 Jul 1992 14:31:39 -0400 (EDT) From: bbeeton Reply-To: TWG@SHSU.edu Subject: Re: YES to IAFA proposal! In-Reply-To: <01GM4S5M2GN49LVFCX@HMCVAX.CLAREMONT.EDU> To: TWG@SHSU.edu Message-Id: <710620299.928794.BNB@MATH.AMS.COM> Content-Transfer-Encoding: 7BIT Mail-System-Version: don hosek asks what systems don't allow digits at the beginning of file names. i agree that mvs is the only one i know of. however, please keep in mind that some of the european sta's are still running on ibm mainframes. i think it unfriendly to cause them problems if it's avoidable. -- bb From TWG-Mgr@SHSU.edu Wed Jul 8 20:28:29 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22229; Wed, 8 Jul 92 20:28:24 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from rs2.hrz.th-darmstadt.de by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 08 Jul 1992 20:08:38 CDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA16435 (5.65c/IDA-1.4.4 for ); Thu, 9 Jul 1992 03:07:09 +0200 Received: by hp5.iti.informatik.th-darmstadt.de (16.6/Server-1.2/HRZ-THD) id AA13882; Thu, 9 Jul 92 03:07:06 +0200 From: Joachim Schrod Reply-To: TWG@SHSU.edu Message-Id: <9207090107.AA13882@hp5.iti.informatik.th-darmstadt.de> Subject: Re: General info (fwd) To: twg@shsu.edu (TUG TWG --- Archives) Date: Thu, 9 Jul 92 3:07:05 MESZ X-Mailer: ELM [version 2.3 PL11] Hi, While reading my mail for the last time, I received the blurb below. Thought it might be of interest for some of you. See you in Portland or meet you in Cyberspace afterwards. :-) -- Joachim PS: I leave the phone number at the end of the message -- for George. Alan is also the person in charge for the IAFA mailing list... ---------------- Included message follows: From: bajan@bunyip.com (Alan Emtage) Date: Wed, 8 Jul 1992 18:35:10 -0400 To: archie-people@cc.mcgill.ca > Q. How long before Archie 3 will be ready? RSN I hope. > Q. What will be its new features? Taken straight from the Bunyip blurb on 3.0: User Configurable databases allow you to offer: o Resource Directory Services o Directories of Anonymous FTP archives o Large text databases, indexed using WAIS o Interfaces to additional database systems Multiple user interfaces, including: o telnet o electronic mail o WAIS (for appropriate databases) archie (Prospero) client interface Other Features: o Network access controls o On-line help facility o Support for Digital signatures (in future releases) Internet Archives Database: o Storage of collections from hundreds or even thousands of sites o Support for UNIX and common VMS formats o Improved search speeds o Expanded range of search methods o Ability to restrict search by host, domain and other conditions o Automatic server-server data exchange o Increased database robustness and reliability o Improved systems administration support > Q. Are there any sites set up along IAFA guidelines that I might peruse. They aren't any to my knowledge yet at least. We should be going into final draft mode for the FTP sys admin documents next week. A few more rounds with the mailing list then we can submit it for RFC FYI status. archie will be using this if it catches on probably in the 3.1 version. -- -Alan +1 (514) 398-8117 From TWG-Mgr@SHSU.edu Wed Jul 8 20:43:41 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22397; Wed, 8 Jul 92 20:43:31 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from theory.lcs.mit.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Wed, 08 Jul 1992 20:34:41 CDT Received: from GYRFALCON.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA15387; Wed, 08 Jul 92 21:33:09 EDT From: dmjones@theory.lcs.mit.edu (David M. Jones) Reply-To: TWG@SHSU.edu Received: by gyrfalcon.lcs.mit.edu (5.65c/TOC-1.2C) id AA28342; Wed, 08 Jul 92 21:32:51 EDT Date: Wed, 08 Jul 92 21:32:51 EDT Message-Id: <199207090132.AA28342@gyrfalcon.lcs.mit.edu> To: twg@SHSU.edu Subject: TeX Macro Index Greetings. I think the time has come for me to solicit an advisory board of sorts for the TeX Macro Index. So, I'm starting a mailing list for the discussion of the future development of the Index. I'd like to invite all of you to join. I don't expect the list to have very high volume, so I hope it won't be too much of a burden on anyone. The basic purpose of the list will be to help me make decisions that I can't make on my own, at least not wisely. Some of the immediate issues that need discussing are 1) What should the file that the Index resides in be called? (Several of you have already pointed out problems with "TeX-index".) 2) How should the Index be arranged? The current hierarchy of headings and subheadings can surely be improved on. 3) What formats should the Index be available in? So far I've optimized for ease of reading as a text file, without much thought of how to make the Index easily accessible to database programs. There has also been some interest in a TeXable version of the Index. 4) How can I keep the Index up-to-date with the holdings of the various TeX archives? 5) Conversely, how can I keep the copies of the Index on the various archives up-to-date with my copy? 6) What other ways are there of making the Index available to people? Sebastian Rahtz has already contacted me about making it available via WAIS, and this should be a reality as soon as we work out a couple of technical details. I recently found out that the archie servers have a "whatis" database. I haven't contacted them yet, but it sounds like the Index would probably fit in there well. What other media are there? There may be other important issues that I'm overlooking. [Note that some of these impinge directly on the work of the TWG list, especially (4) and (5) and, to a lesser extent, (1) and (2). Should such discussions be cross-posted? If so, I can try to juggle my mail list to keep people from getting duplicate messages.] I'll wait a day or two before initiating any discussion on the list, to see who wants to join. There will also be archives available for any late joiners. Yours, David. From TWG-Mgr@SHSU.edu Fri Jul 10 10:59:50 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19885; Fri, 10 Jul 92 10:59:47 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 10 Jul 1992 11:46:09 CDT Received: from claude.cs.umb.edu by cs.umb.edu with SMTP id AA15476 (5.65c/IDA-1.4.4 for ); Fri, 10 Jul 1992 12:44:38 -0400 Received: by claude.cs.umb.edu (5.65c/1.34) id AA00842; Fri, 10 Jul 1992 12:44:36 -0400 Date: Fri, 10 Jul 1992 12:44:36 -0400 From: karl@claude.cs.umb.edu (Karl Berry) Message-Id: <199207101644.AA00842@claude.cs.umb.edu> To: TWG@SHSU.edu In-Reply-To: CHAA006@VAX.RHBNC.AC.UK's message of Thu, 2 JUL 92 12:12:43 BST <202120E0_001832B0.0095CF892E585DA0$17_6@UK.AC.RHBNC.VAX> Subject: Lots of answers Reply-To: TWG@SHSU.edu if I \input PostScript on my MS/DOS system, I get PostScri.TeX Yes. The problem is the other direction: if someone writing an original document on DOS doesn't know the full name of the file, they would say \input postscri which won't work on systems with longer names. But I think we have essentially agreed that such problems are really up to the authors of the packages to deal with, not the archivers. We should just archive what we get (and complain to the authors if we see a conflict). Or am I wrong about this? From TWG-Mgr@SHSU.edu Fri Jul 10 11:44:34 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20307; Fri, 10 Jul 92 11:44:31 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 10 Jul 1992 12:29:27 CDT Via: uk.ac.rhbnc.vax; Fri, 10 Jul 1992 18:27:41 +0100 Date: Fri, 10 JUL 92 18:17:47 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: RE: Lots of answers Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <20203E3D_00074948.0095D605815CA240$5_2@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) >>> But I think we have essentially agreed that such problems are really up >>> to the authors of the packages to deal with, not the archivers. We >>> should just archive what we get (and complain to the authors if we see a >>> conflict). Or am I wrong about this? No, I like this approach. And I withdraw my earlier comments about 72/80/$n$ characters per line; I had forgotten (or not realised) that we were suggesting rejecting or modifying files which did not conform to these criteria, rather than simply _asking_ people to abide by them in future. ** Phil. From TWG-Mgr@SHSU.edu Fri Jul 10 12:17:26 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20490; Fri, 10 Jul 92 12:17:22 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 1127; Fri, 10 Jul 1992 12:59:18 CDT Date: Fri, 10 Jul 1992 12:58:29 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095D5D8.E7098220.1127@SHSU.edu> Subject: Filenames and tex-archive directory name On Fri, 10 Jul 1992 12:44:36 -0400, Karl Berry posted: > if I \input PostScript on my MS/DOS system, I get PostScri.TeX > > Yes. The problem is the other direction: if someone writing an original > document on DOS doesn't know the full name of the file, they would say > \input postscri > which won't work on systems with longer names. > > But I think we have essentially agreed that such problems are really up to > the authors of the packages to deal with, not the archivers. We should > just archive what we get (and complain to the authors if we see a > conflict). Or am I wrong about this? That was my understanding, as well. However, in one of the readme-type files in either the incoming area or the help area, I believe it is absolutely imperative that we stress that a preferred syntax, due to portability, for names is the old standard 8+3 with one and only one period. Ultimately, I guess we're going to have to decide upon some consistent parsing of multiple periods for the VMS hosts. I have the archives here, but am too lazy to pull them up (working on a TPU variant of filehdr presently, a sick cat, my spouse out of town, and starting the second summer term today sort of has me behind on everything). Two quick comments on two prior posts from (I am pretty sure) Joachim. First, regarding the naming of filename.tar_z on a Unix archive -- I really think that once everyone knows that we are enforcing a one period rule in the TeX archive network (another note in a readme-type file in help), no one will have a problem with it. As we migrate into an enforced one period syntax on all CTAs, people may have a few problems and the concerns you note. However, but eventually (I would posit relatively quickly, if we can indeed be comprehensive in holdings) people will accept and expect it. Recall that the archival name does not necessarily have to be the operational name (i.e., our HP-UX wouldn't even try to uncompress filename.tar_z), just as the directory names do not necessarily have to be (more specifically, generally won't be) the operational directories. Second, someone asked about why I proposed (and I believe most of us have agreed to) the name tex-archive, as opposed to tex, as the root of the archival tree. True, virtually every site with TeX-related holdings now has a tex directory. The idea behind the tex-archive directory name was to (a) standardize it across the nodes of the network, and to (b) indicate that within this structure, the directory and naming structure was consistent with the network. We cannot remove everyone's existing tex directories; moreover, they would very probably tell us to attempt to go genetically reproduce ourselves (don't want to put bad words on the net 8-)) if we attempted to tell them that they needed to rebuild any existing directories. By providing a map (again somewhere in help) of the tree we ultimately decide upon, I believe that most every site which houses a tex-archive tree will follow the propogated structure. Also, site specific tex trees can continue to exist without any possibility of conflict with the CTA structure. Anyone brave (foolish?) enough to want to try out a pre-beta version of my DCL/TPU filehdr variant, tentatively named TPUHEAD as it's nowhere near a "port" of Nelson's work but does get everything in place, let me know and I'll inform you directly when it's finished. No laughing, though!! I hope to have something I can play with constructively by late this afternoon, assuming no interruptions. No promises on this time window, though. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From TWG-Mgr@SHSU.edu Mon Jul 13 17:00:51 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12822; Mon, 13 Jul 92 17:00:44 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 6176; Mon, 13 Jul 1992 18:00:18 CDT Date: Mon, 13 Jul 1992 18:00:15 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: twg@SHSU.edu Message-Id: <0095D85E.8EB8F820.6176@SHSU.edu> Subject: TPUHDR 0.a (beta) available on Niord I have a beta (alpha, possibly) version of TPUHDR available on Niord for anonymous ftp retrieval. Attached is the file TPUHDR.INFO from it. If you do retrieve it, I would very much like to hear comments, suggestions, complaints, etc. No promises that I will (more likely, can) do anything on them, but I will attempt to make a best effort -- promise! --George THIS IS BETA (ALPHA??) LEVEL DOCUMENTATION -- I.E., NOT GOOD TPUHDR is a file header creation package for VAX/VMS which is based on the logic of Nelson Beebe's filehdr package for Emacs Lisp. It is not intended as a port of Beebe's filehdr. Instead, it is based on the inherent languages supported by default in the VMS environment -- Digital Command Language (DCL) and Digital Equipment Corporation's (DEC) Text Processing Utility (TPU) language. The function of TPUHDR is to create, as a stand-alone package, file headers for files already in existence. It is intended to be utilized as a last step in preparing files for archival purposes. Therefore, authors are free to utilize any editor to actually create and work on files. Moreover, TPUHDR was designed to utilize TPU command files so that users who use personalized TPU section files may continue to use them even in the final steps of production. Necessarily, each file must have the following fields: @file-type{ filename = "filename.in-lower-case", date = "date of processing", time = "time of processing, with an optional timezone string", supported = "supported by author field -- either yes or no" } The "file-type" field above is automatically determined by the extension of the file. Additional fields supported include: version = "version of file", author = "author's name", address = "author's mailing address", e-mail = "author's electronic mail address", telephone = "author's telephone number", FAX = "author's FAX number", archived = "sites which are known archives of the file", keywords = "a string of keywords attached to the file", abstract = "a brief abstract of the file's use, purpose, etc., similar to an embedded README-type file, codetable = "which codetable is effective for this file", checksum = "a checksum field, including a CRC-16 checksum, a line count, word count and character count", docstring = "a brief description of the file; if a checksum is included, the following string is automatically appended as the end of the docstring: The checksum field above contains a CRC-16 checksum as the first value, followed by the equivalent of the standard UNIX wc (word count) utility output of lines, words, and characters. This is produced by Robert Solovay's checksum utility." The default ordering of fields created by TPUHDR is: @file-type{ filename = "", version = "", date = "", time = "", author = "", address = "", e-mail = "", telephone = "", FAX = "", supported = "", archived = "", keywords = "", abstract = "", codetable = "", checksum = "", docstring = "" } Since you are placed in an editor following processing, you may make any alterations you desire to this ordering prior to exiting and processing the checksum (if applicable). It is highly suggested to use a left margin of 1 and a right margin of 50 when processing these field-related files outside of the TPUHDR environment as TPUHDR makes no attempt to reconfigure lines -- this allows users to exactly design their headers in a more WYSIWYG-type format for blocks, spaces, examples, etc. TPUHDR makes every attempt to minimize the author's work. The logic of searching for this information is based on a VMS-based searchpath for its information files, looking first to the current default directory, then to the user's login directory. For this reason, it is suggested that users experiment with this on a file in their SYS$LOGIN directory the first time they use it. This will create the files TPUHDR-AUTHOR.TXT TPUHDR-ADDRESS.TXT TPUHDR-EMAIL.TXT TPUHDR-FAX.TXT These files are not deleted upon exiting. If they exist in the user's login directory, they will never have to be touched again and the information will be introduced automatically each time TPUHDR is utilized. Virtually all of other supported fields has a similar TPUHDR-fieldname.TXT file, which is created in the user's current default directory. The user is prompted whether or not to delete these files on exiting TPUHDR. If the file(s) are not deleted, they are automatically included in subsequent applications of TPUHDR. Each of the files associated with TPUHDR may be of any length. Information is prompted for in TPUHDR sessions, whereupon the user is placed into a TPU-based editing session, with margins automatically placed at 1 and 50 -- the appropriate locations for subsequent inclusion. These extra TPUHDR-fieldname.TXT files may be created prior to running TPUHDR, if you choose, and they will be automatically included in the processing of your file. To use TPUHDR, place the files: TPUHDR.COM TPUHDR.TPU TPUCOMM.TPU TPUHDR_CHECKSUM.STANDARD_TXT TPUHDR_ISO-ASCII.STANDARD_TXT in a common directory, which users may have read and executable access to. The LOCAL section of the file TPUHDR.COM should not be altered; rather it provides support and gives guidance for two controlling logicals which sites may prefer to define system-wide -- TPUHDR_DIR (where the files above are retained) and TPUHDR_CHECKSUM (a foreign command symbol pointing to Solovay's checksum utility, which is not compatible with the standard VMS CHECKSUM utility; the SHSU installation has copied the resulting CHECKSUM.EXE of the Solovay output to SYS$SYSTEM:CHECKSUM.NEW and it is defined in this way by default in TPUHDR.COM). If you do not have Solovay's CHECKSUM package, which now supports VAX/VMS and MS-DOS compatibles, as well as most Unix applications, it is available for anonymous ftp retrieval from Niord.SHSU.edu (192.92.115.8) in the directory [FILESERV.CHECKSUM]. The files will soon be available for retrieval from FILESERV@SHSU.edu. To use TPUHDR, simply create a foreign command symbol to TPUHDR, such as: TPUHDR :== @dev:[dir]TPUHDR the, at the DCL-level prompt, type TPUHDR file-to-be.processed TPUHDR is available on Niord.SHSU.edu (192.92.115.8) in the directory [FILESERV.TPUHDR] in a ZIP archive. Once the package gets beyond beta stages, it will be supported as individual files on Niord, as well as on FILESERV. TPUHDR is intended to be a fully supported package. Please forward any comments to its author: George D. Greenwade bed_gdg@SHSU.edu (Internet) BED_GDG@SHSU (BITNET) SHSU::BED_GDG (THENET) Department of Economics and Business Analysis College of Business Administration P. O. Box 2118 Sam Houston State University Huntsville, Texas, USA 77341-2118 (409) 294-1266 -- voice (409) 294-3712 -- FAX From TWG-Mgr@SHSU.edu Tue Jul 21 10:59:56 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23421; Tue, 21 Jul 92 10:59:51 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 25906; Tue, 21 Jul 1992 11:53:56 CDT Date: Tue, 21 Jul 1992 11:52:42 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: spqr@minster.york.ac.uk Cc: twg@SHSU.edu Message-Id: <0095DE74.897B0080.25906@SHSU.edu> Subject: RE: duplicate names On Tue, 21 Jul 92 16:43:47, posted to (the TeX Macro Index list): > i have met the first of what i expect will be many conflicts - the name > "labels". > > i find > 1 label.tex > 2 labels.tex > 3 labels.sty > in the Index, but the 3rd does a different job from 1 and 2. 3 also claims > to be in the Aston archive, but in fact the labels.sty there is a creation > of mine which does the same job as 1 and 2. > > how to resolve such things? it *must* be confusing to have labels.tex and > labels.sty doing quite different things; and how do we distingush between > LaTeX \labels and and sticky ones for envelopes? > > then there is `showlabels` which does a similar job to 3! > > i wonder how difficult it would be to get people to agree to use Jones > Names for things? then the archives could agree to accept nothing that > conflicted with Jones? but that imposes an intolerable burden on David of > validating names of styles! > > thoughts > > sebastian First, this reply is being cc'ed to TWG@SHSU.edu, a loose coalition of archivists and interested parties under the auspices of TeX Users Group Working Group 92-05, working toward developing TeX archive standards. I am forwarding it to this group as it's decisions will largely shape how the archives are maintained in the future, which has a direct impact on the "futurity" versus "presence" of this question. The good and bad news on this is that (I believe) we are looking at a system of mirroring the various TeX-related archives together -- an implied hope of mine (which I believe we've agreed to) is to have parallel directory and filename structures such that it will be largely transparent to the end user of the archives which machine they are logged on to. Good -- this is something which will have to be dealt with, and I'm sure it will; bad -- I don't think we have a mechanism presently in place to address this question. I agree that the sheer workload on any given individual to verify and assign names to the files is overwhelming. I would hope that, in the future, macro, style, and package developers/authors consult with the Index, as well as with the known mirror sites to see if a filename is "free". A very real problem, as you point out, is the number of files presently in existence with the same filename. I have no idea exactly how many there are; my guess is that it is a small proportion of all known and presently-archived TeX-related files -- but even a small proportion of all known and presently-archived TeX-related files has the ability to be a large number. I believe that the current state of affairs which has been tentatively agreed to is, in the future, for the receiving site to get a message back to the author of files with conflicting names requesting a renaming. With the Index in place, a parallel directory and naming structure on known mirror sites, and multiple points of entry into the mirroring network, the workload will be reduced for any one person/site. I fully believe that the problem will minimize over time given these resources. In some areas of the tree, such as latex-style-supported and latex-style-unsupported, there cannot be a conflict (these all are destined to the texinput path!). In other words, while it may be allowable to have parallel names in different directories which are directory-specific (i.e., Makefile, README, etc.), the fact that we are looking at different directories (alone) is inadequate to allow conflicting names in all cases. To Sebastian's current question: Does anyone have a suggestion as to how to re-assign current filenames so that mirroring of the same files under the same filenames can be accomplished? Certainly, it would be good to consult with the authors; however, what do we do if none of the authors involved don't agree to a name change or cannot be contacted? Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From TWG-Mgr@SHSU.edu Tue Jul 21 11:36:23 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23686; Tue, 21 Jul 92 11:36:19 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from sun2.nsfnet-relay.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 21 Jul 1992 12:30:46 CDT Via: uk.ac.rhbnc.vax; Tue, 21 Jul 1992 18:29:02 +0100 Date: Tue, 21 JUL 92 18:30:07 BST From: CHAA006@VAX.RHBNC.AC.UK To: TWG Subject: RE: duplicate names Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <2020BC91_00075F58.0095DEAC0CC891A0$45_2@UK.AC.RHBNC.VAX> Reply-To: TWG@SHSU.edu Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.SHSU::TWG Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) >>> To Sebastian's current question: Does anyone have a suggestion as to how >>> to re-assign current filenames so that mirroring of the same files under >>> the same filenames can be accomplished? Certainly, it would be good to >>> consult with the authors; however, what do we do if none of the authors >>> involved don't agree to a name change or cannot be contacted? I think we just have to accept that there will be many files with the same name, and perhaps ever with similar functionality (as well as those with the same name but different functionality, where some change of name might well be indicated). After all, if I've written (e.g.) PostScript.TeX, which does everything I want a PostScript macro to do, and A.N.Other has written PostScript.TeX, which does everything he or she wants it to do, neither of us are likely to agree to a name change. I therefore suggest that whenever such a conflict occurs, the common name be taken simply as a directory name, and sub-directories created, one for each author. Philip Taylor, RHBNC From TWG-Mgr@SHSU.edu Tue Jul 28 14:02:51 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA08383; Tue, 28 Jul 92 14:02:44 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from cs.umb.edu by Niord.SHSU.edu (MX V3.1B) with SMTP; Tue, 28 Jul 1992 14:56:02 CDT Received: from claude.cs.umb.edu by cs.umb.edu with SMTP id AA29239 (5.65c/IDA-1.4.4 for ); Thu, 23 Jul 1992 07:34:54 -0400 Received: by claude.cs.umb.edu (5.65c/1.34) id AA11660; Thu, 23 Jul 1992 07:34:52 -0400 Date: Thu, 23 Jul 1992 07:34:52 -0400 From: karl@claude.cs.umb.edu (Karl Berry) Reply-To: TWG@SHSU.edu Message-Id: <199207231134.AA11660@claude.cs.umb.edu> To: twg@shsu.edu Subject: supported vs. unsupported In his last message, George referred to latex-style-supported and latex-style-unsupported directories. I had advocated eliminating that distinction before, to decrease the number of directories and directory hierarchies that users have to look in. The information would still be in individual files, of course. My feeling is that the most common use of archives is to try to find something which they know by name, but perhaps nothing else about it. As an article of faith, we should strive to make the most common use as simple as possible. Thus, in my view, we should eliminate the supported/unsupported distinction. Rainer previously said that when he is looking through archives, he doesn't want to retrieve things that are unsupported. So eliminating the distinction at the directory level will make things harder for him. Again, in my (personal & other) experience, many people browsing do not care if something is supported or not when they retrieve it; if it looks interesting, they'll grab it, and worry about support afterwards. So, the question is, I think: am I out to lunch, and Rainer's use of archives typical? If so, every directory must have supported and unsupported branches. Otherwise, I think we should toss the distinction. karl@cs.umb.edu From TWG-Mgr@SHSU.edu Tue Jul 28 15:50:19 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10522; Tue, 28 Jul 92 15:50:17 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: by SHSU.edu (MX V3.1B) id 14705; Tue, 28 Jul 1992 16:47:10 CDT Date: Tue, 28 Jul 1992 16:45:28 CDT From: "George D. Greenwade" Reply-To: TWG@SHSU.edu To: TWG@SHSU.edu Message-Id: <0095E41D.985FFDE0.14705@SHSU.edu> Subject: RE: supported vs. unsupported On Thu, 23 Jul 1992 07:34:52 -0400, Karl Berry posted: >.... > I had advocated eliminating (the [un]supported) distinction before, to > decrease the number of directories and directory hierarchies that users > have to look in. The information would still be in individual files, of > course. >.... The more I think about it, the more I agree with Karl on this one. If the files include the proper headers and indicate supported/unsupported in them (as well as in the Macro Index), I believe we may better off by excluding the distinction since we will save extra levels/branches on directory trees. --George From TWG-Mgr@SHSU.edu Thu Jul 30 08:12:47 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27716; Thu, 30 Jul 92 08:12:44 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from minster.york.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Thu, 30 Jul 1992 08:28:11 CDT From: spqr@minster.york.ac.uk Reply-To: TWG@SHSU.edu Date: Thu, 30 Jul 92 14:01:46 Message-Id: To: TWG@SHSU.edu Subject: directory structure This is going to be quite a long post about directory structures, so bear with me. I have just got into the idea of the TWG, with a bit of a feeling of deja-vu. About 4 years ago, I recall a meeting in Peter Abbott's office where we went over and over the `right` directory hierarchy for hours! Anyway, the reason I am doing this is that I want to do some groundwork for a possible move to (or duplication on) Unix by the UK TeX Archive, so I am setting up an archive on ftp.tex.ac.uk at this moment, and meeting some problems with the suggested hierarchy. What I'll do is go through and comment on the bits that bother me: Where I say `you', by the way, I dont mean any actual person! .TEX-ARCHIVE]BOOKS.DIR dont like this. documentation would cover a wider field .TEX-ARCHIVE]FONTS.DIR .TEX-ARCHIVE]LANGUAGES.DIR so you separate Russian fonts from Russian hyphenation.....(i have no answer to that, by the way!) .TEX-ARCHIVE]MACROS.DIR I *definitely* hate this. if this is the main jumping off point for LaTeX,plain, AMSTeX etc users to get their fix, it must be clearer. I suggest FORMATS, within which each `package' gets a directory .TEX-ARCHIVE]USERS-GROUPS.DIR this is unnecessary. put under HELP or DOCUMENTATION .TEX-ARCHIVE]WEB.DIR again, means nothing to the beginner. anyway, what *is* it for? the generic TeX and MF sources? or literate programming. if the former, call it SOURCE! .TEX-ARCHIVE.ARCHIVE-TOOLS.COMPRESSION]ZIP.DIR .TEX-ARCHIVE.ARCHIVE-TOOLS.ENCODING]ATOB.DIR is it worth the extra levels? why not just package by package under archive-tools? you're bound to find one that does both .TEX-ARCHIVE.BIBLIOGRAPHY]BIBTEX.DIR .TEX-ARCHIVE.BIBLIOGRAPHY]REF2BIB.DIR no! ref2bib must go *under* BibTeX, surely? it is no use on its own! .TEX-ARCHIVE.BIBLIOGRAPHY.BIBTEX]BST.DIR .TEX-ARCHIVE.BIBLIOGRAPHY.BIBTEX]MACBIBTEX.DIR yuck. Macs are horrible enough already without spoiling directory symmetry .TEX-ARCHIVE.BIBLIOGRAPHY.BIBTEX.BST]SUPPORTED.DIR .TEX-ARCHIVE.BIBLIOGRAPHY.BIBTEX.BST]UNSUPPORTED.DIR .TEX-ARCHIVE.BIBLIOGRAPHY.BIBTEX.BST.SUPPORTED]HARVARD.DIR I'll come back to this later. by *supported by who*? i think the only useful distinction to make is between packages that make up a `normal' system, which go with every distribution, and which everyone must assume are present, and packages that you may add at your discretion (whether the author mends them is beside the point). if the maintainer of {bibtex,latex,amstex} has tested the work and wants it there, supported. otherwise all the same .TEX-ARCHIVE.DRIVERS]PRINTERS.DIR .TEX-ARCHIVE.DRIVERS]VIEWERS.DIR HATE it! it is my biggest grouse against the unix TeX tape, this silly distinction between screens and printers. dvips+ghostscript is a good previewer, just to take an example. and Mattes' packages of course show that the whole thing can be integrated .TEX-ARCHIVE.DRIVERS.PRINTERS]DVICONCAT.DIR .TEX-ARCHIVE.DRIVERS.PRINTERS]DVICOPY.DIR .TEX-ARCHIVE.DRIVERS.PRINTERS]DVIDVI.DIR er um, are these (and others) *drivers*? they read dvi files, yes, but only write more of the things .TEX-ARCHIVE.DRIVERS.PRINTERS]TEXTYL.DIR definitely not a driver... .TEX-ARCHIVE.FONTS]AMSFONTS.DIR .TEX-ARCHIVE.FONTS]MF.DIR ams use MF, yes? do you mean CM? .TEX-ARCHIVE.FONTS]UTILITIES.DIR .TEX-ARCHIVE.FONTS.UTILITIES]AFM2TFM.DIR except that afm2tfm comes with dvips... where do i put (from this mornings work) - modes.mf - Berry's font name scheme - sauter system (applies to cm, but also dc and cyrillic) i suggest [.fonts.doc] (or help or ...) .TEX-ARCHIVE.LANGUAGES]BABEL.DIR .TEX-ARCHIVE.LANGUAGES]HYPHENATION.DIR dont see the point of this. hyphen patterns will appear under eg [.portugues] anyway, so why have this extra directory? .TEX-ARCHIVE.MACROS.AMS]AMSLATEX.DIR .TEX-ARCHIVE.MACROS.AMS]AMSTEX.DIR could bb comment on this. are they not just two separate packages? you group them on the basis of authorship, which is weird .TEX-ARCHIVE.MACROS.LATEX-STYLE]BASE.DIR .TEX-ARCHIVE.MACROS.LATEX-STYLE]SUPPORTED.DIR .TEX-ARCHIVE.MACROS.LATEX-STYLE]UNSUPPORTED.DIR why latex-style? surely just latex? ****** i'd suggest .formats.latex] .formats.latex.base] lplain, lfonts etc .formats.latex.styles] .formats.latex.styles.supported] agreed to by authors of LaTeX .formats.latex.styles.contrib] added by Joe public, of whatever quality .formats.latex.styles.contrib.whatever] multi-file package .TEX-ARCHIVE.MACROS.MUSIC]MTEX.DIR .TEX-ARCHIVE.MACROS.MUSIC]MUSICTEX.DIR again, why group on grounds of usage? two separate packages, please .TEX-ARCHIVE.SYSTEMS]AMIGA.DIR .TEX-ARCHIVE.SYSTEMS]ATARI.DIR .TEX-ARCHIVE.SYSTEMS]MAC.DIR .TEX-ARCHIVE.SYSTEMS]MSDOS.DIR .TEX-ARCHIVE.SYSTEMS]UNIX.DIR .TEX-ARCHIVE.SYSTEMS]VAX-VMS.DIR you'll upset the VM/CMS chappies... .TEX-ARCHIVE.WEB]CWEB.DIR .TEX-ARCHIVE.WEB]SPIDERWEB.DIR .TEX-ARCHIVE.WEB]STANDARDS.DIR oh sorry you *did* mean literate programming. to be heretical, this is nothing to do with TeX at all. i am sure WEBery is a wonderful thing, and maybe Knuth is right that it is his big achievement, but for 99% of TeX users, this stuff is a total irrelevance. to put it in because a) TeX is written in in, or b) TeX users will likely program in web-style, is actually rather silly. one might as well add of gnu because they document their stuff using TeX END OF SPECIFIC WHINGING overall points a) please drop the idea of `supported' meaning 'the author replies to email'. I `support' the stuff I have done for LaTex, but it doesnt mean that its an agreed part of international LaTeX. maybe if latex3 chooses to recognize my extensions (ha! some chance), then my stuff can migrate to another directory. b) off the top of my head, i am not sure i see where to put (to take two extremes) - AUC-TeX emacs code - the main TeX and MF source code c) I dont think there has been enough discussion about the principal of archiving vs explosion. clearly the individual macro files need storing as files, but when it comes to fonts, what is the point? it might be better to store any tfm or pk files *only* in compressed clumps for specific platforms, and possibly offer a `creation on demand' service? the `shrink-wrapped' offerings all come with their own stuff anyway the question comes with something like xdvi. do we store this is as exploded files or in a set of packages, one for each architecture than can wants it? I'll stop there and add other points as i think of them. Sebastian From TWG-Mgr@SHSU.edu Fri Jul 31 03:28:06 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13089; Fri, 31 Jul 92 03:28:04 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from VAX01.AMS.COM by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 31 Jul 1992 04:27:49 CDT Received: from MATH.AMS.COM by MATH.AMS.COM (PMDF #2306 ) id <01GN0LNNX4BKAH2RIH@MATH.AMS.COM>; Fri, 31 Jul 1992 05:01:19 EST Date: 31 Jul 1992 05:01:17 -0400 (EDT) From: bbeeton Reply-To: TWG@SHSU.edu Subject: Re: directory structure In-Reply-To: To: TWG@SHSU.edu Cc: spqr@minster.york.ac.uk Message-Id: <712573277.79942.BNB@MATH.AMS.COM> Content-Transfer-Encoding: 7BIT Mail-System-Version: (as i am reading mail from a location remote from ams, with rather slooooow equipment, i wouldn't ordinarily respond, except sebastian asked an explicit question of me; i will probably be cut off after this until about august 10, as i'm traveling for a week following the tug meeting, just finished.) sebastian asks me to comment on the proposed directory structure: .TEX-ARCHIVE.MACROS.AMS]AMSLATEX.DIR .TEX-ARCHIVE.MACROS.AMS]AMSTEX.DIR and whether they are not just two separate packages, grouped on the basis of authorship. yes, these are really just two separate packages. i asked earlier that this configuration be considered, for the reason that the ams is trying to maintain a reliable archive of the packages that are distributed by ams (e-math.ams.com), and this is made simpler by the archives mirroring e-math maintaining the same structure used within e-math. we realize that this leads to apparent anomalies in other archives, but if all archives have the ams files in the same relative structure, then we at ams can create a single set of documentation for users that will be accurate regardless of the (archive) source >From which they may retrieve any package originating at ams. we believe that this is a desirable goal, and know of no other means of achieving it. -- bb From TWG-Mgr@SHSU.edu Fri Jul 31 04:18:10 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13493; Fri, 31 Jul 92 04:18:05 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from minster.york.ac.uk by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 31 Jul 1992 05:18:16 CDT From: spqr@minster.york.ac.uk Reply-To: TWG@SHSU.edu Date: Fri, 31 Jul 92 11:03:32 Message-Id: To: TWG@SHSU.edu Subject: Re: directory structure In-Reply-To: <712573277.79942.BNB@MATH.AMS.COM> References: <712573277.79942.BNB@MATH.AMS.COM> bbeeton writes: > sebastian asks me to comment on the proposed directory structure: > .TEX-ARCHIVE.MACROS.AMS]AMSLATEX.DIR > .TEX-ARCHIVE.MACROS.AMS]AMSTEX.DIR > and whether they are not just two separate packages, grouped on the > basis of authorship. > yes, these are really just two separate packages. i asked earlier > that this configuration be considered, for the reason that the ams > is trying to maintain a reliable archive of the packages that are > distributed by ams (e-math.ams.com), and this is made simpler by the > archives mirroring e-math maintaining the same structure used within > e-math. we realize that this leads to apparent anomalies in other i see the point, but if one lets one organization break the structure, everyone else will want to as well... the AMS must, i see, be able to objectively describe the structure of any archive for its customers, but is it too late to ask the ams to change its structure to come into line with the TUG recommendations (if they come into existence)? we are going to ask everyone else to do so, after all. sebastian From TWG-Mgr@SHSU.edu Fri Jul 31 21:42:53 1992 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01223; Fri, 31 Jul 92 21:42:51 MDT Errors-To: TWG-Mgr@SHSU.edu Errors-To: TWG-Mgr@SHSU.edu X-Listname: TUG Technical Working Group -- Archives (WG-92-05) Received: from VAX01.AMS.COM by Niord.SHSU.edu (MX V3.1B) with SMTP; Fri, 31 Jul 1992 22:42:30 CDT Received: from MATH.AMS.COM by MATH.AMS.COM (PMDF #2306 ) id <01GN1N4GAJ2OAH2SCO@MATH.AMS.COM>; Fri, 31 Jul 1992 23:20:20 EST Date: 31 Jul 1992 23:20:20 -0400 (EDT) From: bbeeton Reply-To: TWG@SHSU.edu Subject: Re: directory structure In-Reply-To: To: TWG@SHSU.edu Message-Id: <712639220.656942.BNB@MATH.AMS.COM> Content-Transfer-Encoding: 7BIT Mail-System-Version: sebastian asks, after hearing the explanation of why the ams would prefer a uniform structure for ams-sourced files across all the tex archives, if it is too late to ask ams to change its structure to come into line with the tug recommendations. this is my personal opinion, which has not even been discussed with anyone in charge of the ams archive: it's certainly worth asking. please remember that there were absolutely no guidelines, much less agreed-on recommendations, when the ams archive was created. if there had been, i believe they would at least have been looked at carefully. while i also believe that, because of the interdependencies between the ams packages, it would be considered advisable not to mix any of these files in with files from other sources, changes in directory names may be more negotiable. no promises, but i'm sure we have no desire to be unreasonable. -- bb