13-Feb-1996 13:18:56-GMT,1551;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id GAA17613 for ; Tue, 13 Feb 1996 06:18:54 -0700 (MST) Received: from lumiere.idris.fr by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I15LKTB0VK000CPE@AXP14.AMS.ORG>; Tue, 13 Feb 1996 06:38:58 -0500 (EST) Received: from murnau.idris.fr (murnau.idris.fr [130.84.8.20]) by lumiere.idris.fr (8.7.3/8.7.3) with ESMTP id MAA12324 for ; Tue, 13 Feb 1996 12:38:40 +0100 Received: (from gaulle@localhost) by murnau.idris.fr (8.7.3/8.7.1) id MAA01562; Tue, 13 Feb 1996 12:38:37 +0100 Date: Tue, 13 Feb 1996 12:38:37 +0100 From: Bernard GAULLE Subject: Drivers design about VF To: TEX-IMPLEMENTORS@MATH.AMS.ORG Message-id: <199602131138.MAA01562@murnau.idris.fr> Content-transfer-encoding: 7BIT Having recently completed 100 virtual fonts and using them with few drivers, i'm surprised to see how drivers handle virtual fonts. May be there is a basic technical reason i don't see but i'm wondering... The three well known drivers i have used are loading all fonts mapped inside a vf file, even there is no need of them, even no chars are used nor printed at all. Is it really a perfect design? or is it because vf aren't extensively used? IMHO i thought they could progress, but i'm wrong don't hesitate to convince me. Could someone tell me about a driver that is more sophisticated than those i used and which is able to load the only required fonts? Thanks, --bg 13-Feb-1996 21:41:30-GMT,2354;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id OAA23236 for ; Tue, 13 Feb 1996 14:41:05 -0700 (MST) Received: from athens.emi.net (ns.emi.net) by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I163DSB5TC000KZP@AXP14.AMS.ORG>; Tue, 13 Feb 1996 15:08:52 -0500 (EST) Received: from toledo.emi.net (toledo.emi.net [204.181.45.9]) by athens.emi.net (8.6.10/8.6.10) with ESMTP id PAA13987; Tue, 13 Feb 1996 15:15:36 -0500 Received: (from kinch@localhost) by toledo.emi.net (8.6.10/8.6.10) id PAA11358; Tue, 13 Feb 1996 15:05:23 GMT Date: Tue, 13 Feb 1996 15:05:23 +0000 (GMT) From: Richard Kinch Subject: Re: Drivers design about VF In-reply-to: <199602131138.MAA01562@murnau.idris.fr> from "Bernard GAULLE" at Feb 13, 96 12:38:37 pm To: gaulle@idris.fr (Bernard GAULLE) Cc: TEX-IMPLEMENTORS@MATH.AMS.ORG Message-id: <199602131505.PAA11358@toledo.emi.net> X-Mailer: ELM [version 2.4 PL23] Content-type: text Content-transfer-encoding: 7BIT > Could someone tell me about a driver that is more sophisticated > than those i used and which is able to load the only required fonts? TrueTeX uses a recursive algorithm to load all TFMs in virtual fonts. As you suggest, a demand-based algorithm might be more efficient instead of pre- loading all the fonts in a document. The only reason I can imagine otherwise is that once the fonts are loaded there will be no surprises in the middle of a rendering pass (difficult to handle in a window-painting thread), should a font be missing on the system. But primarily, preloading all fonts (the naive approach) is just easier to code. Perhaps the VF definition should have specified demand loading as part of the standard, since one might to have various sets of fonts, some not available, switched in and out of a document by switching VF files or the environment pointer. In TrueTeX we will be implementing optimizations for font loading which include demand-loading of VF's, as part of an upgrade presently underway for Unicode DVI interpretation. Kinch Computer Company Publishers of TrueTeX (R) brand of software Richard J. Kinch kinch@holonet.net 6994 Pebble Beach Court Tel (407) 966-8400 Lake Worth FL 33467 USA FAX (407) 966-0962 Info at http://www.emi.net/~kinch 13-Feb-1996 22:58:13-GMT,3376;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id PAA24333 for ; Tue, 13 Feb 1996 15:58:10 -0700 (MST) Received: from math.Berkeley.EDU by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I168PXFUNK000H2W@AXP14.AMS.ORG>; Tue, 13 Feb 1996 17:41:13 -0500 (EST) Received: from tashkent.berkeley.edu by math.berkeley.edu (8.7.1/1.33(math)Ow.2) id OAA06098; Tue, 13 Feb 1996 14:40:21 -0800 (PST) Received: (from vojta@localhost) by tashkent.berkeley.edu (8.7.1/8.7.1) id OAA11265; Tue, 13 Feb 1996 14:40:20 -0800 (PST) Date: Tue, 13 Feb 1996 14:40:20 -0800 (PST) From: vojta@math.berkeley.edu (Paul Vojta) Subject: Re: Drivers design about VF To: gaulle@idris.fr, kinch@emi.net Cc: TEX-IMPLEMENTORS@MATH.AMS.ORG Message-id: <199602132240.OAA11265@tashkent.berkeley.edu> Content-transfer-encoding: 7BIT On Tue Feb 13 04:11:50 1996, Bernard GAULLE wrote: > Having recently completed 100 virtual fonts and using them with > few drivers, i'm surprised to see how drivers handle virtual fonts. > May be there is a basic technical reason i don't see but i'm wondering... > The three well known drivers i have used are loading all fonts mapped > inside a vf file, even there is no need of them, even no chars are used > nor printed at all. Is it really a perfect design? or is it because > vf aren't extensively used? IMHO i thought they could progress, but > i'm wrong don't hesitate to convince me. I agree with you. In fact, as I see it, the three drivers you mention above (which ones are the guilty parties?) do it wrong. I refer you to DEK's article in TUGBoat, Vol. 11, No. 1. On page 14, he writes, "The latter files [gf or pk] should not be loaded immediately, but only on demand, because the process is recursive." See also the example recurse.vpl on page 23. If you tweaked that example just a little bit, so that "A" was a character from an actual font instead of a rule, then, as I see it, the three drivers you mention would get stuck in an infinite loop. > Could someone tell me about a driver that is more sophisticated > than those i used and which is able to load the only required fonts? xdvi does. (That's the "OEM" xdvi, not xdvik, which at least at one time did not.) On Tue Feb 13 12:33:34 1996, Richard Kinch responded: > > TrueTeX uses a recursive algorithm to load all TFMs in virtual fonts. TFM's?? I guess you might not get into an infinite loop when loading those, but a dvi driver should be more interested in PK's. > As you > suggest, a demand-based algorithm might be more efficient instead of pre- > loading all the fonts in a document. The only reason I can imagine otherwise > is that once the fonts are loaded there will be no surprises in the middle > of a rendering pass (difficult to handle in a window-painting thread), should > a font be missing on the system. > > But primarily, preloading all fonts (the naive approach) is just easier to > code. Agreed... > Perhaps the VF definition should have specified demand loading as part > of the standard, since one might to have various sets of fonts, some not > available, switched in and out of a document by switching VF files or the > environment pointer. It does require demand loading, at least for pixel files (see above). --Paul Vojta, vojta@math.berkeley.edu 14-Feb-1996 3:18:40-GMT,2297;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id UAA26265 for ; Tue, 13 Feb 1996 20:18:31 -0700 (MST) Received: from 198.68.32.51 by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I16HM2Y3WW000TOD@AXP14.AMS.ORG>; Tue, 13 Feb 1996 21:57:14 -0500 (EST) Received: from usr2.primenet.com (root@usr2.primenet.com [198.68.32.12]) by mailhost1.primenet.com (8.7.3/8.7.1) with ESMTP id TAA19538 for ; Tue, 13 Feb 1996 19:54:45 -0700 (MST) Received: (from quixote@localhost) by usr2.primenet.com (8.7.3/8.7.3) id TAA22809; Tue, 13 Feb 1996 19:54:46 -0700 (MST) Date: Tue, 13 Feb 1996 18:53:25 -0800 (PST) From: dhosek@quixote.com (Don Hosek) Subject: Re: default TeX input path To: tex-implementors@MATH.AMS.ORG Reply-to: dhosek@quixote.com (Don Hosek) Message-id: <199602140254.TAA22809@usr2.primenet.com> X-Mailer: PMMail v1.1 UNREGISTERED SHAREWARE Content-transfer-encoding: 7BIT On Tue, 13 Feb 1996 18:02:17 -0500 you wrote: >I've seen this suggestion before, but I've resisted putting .. in the >default path for the web2c implementation since it's fairly >untraditional. And I don't especially want to make a change that will >make web2c differ from other implementations, either. On the other >hand, I'm not terrifically opposed to the idea. >So, my question for this list is whether we should include the parent >directory in the TeX (and Metafont and MetaPost?) search paths by default. Why not make this a switch on the tex command line? When I was working on the VMS change file with Brian Hamilton Kelly, we did this to allow a number of extensions which we disagreed about the correct interpretation of (and conceivably others might as well). Under VMS it was actually quite simple to make the majority of parameters which an admin might want to configure options which could be stored in the CLD file and set without ever recompiling TeX (that was a big goal of ours--to avoid the requirement that admins have to change the change file). -dh -- Don Hosek dhosek@quixote.com 909-621-1291 fax: 909-625-1342 Quixote Digital Typography http://www.quixote.com/ Publishers of _Serif: The Magazine of Type and Typography_ 14-Feb-1996 9:53:54-GMT,1621;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id CAA29164 for ; Wed, 14 Feb 1996 02:53:49 -0700 (MST) Received: from bescot.cl.cam.ac.uk by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I16UE1619C000P7T@AXP14.AMS.ORG>; Wed, 14 Feb 1996 04:01:41 -0500 (EST) Received: from cl.cam.ac.uk [128.232.33.33] (maj) by bescot.cl.cam.ac.uk with esmtp (Exim 0.37 #2) id E0tmd22-0000jD-00; Wed, 14 Feb 1996 08:57:46 +0000 Date: Wed, 14 Feb 1996 08:57:39 +0000 From: Martyn Johnson Subject: Re: default TeX input path In-reply-to: Your message of Tue, 13 Feb 1996 18:02:17 -0500. <199602132302.AA03628@terminus.cs.umb.edu> To: "K. Berry" Cc: tex-implementors@MATH.AMS.ORG, Martyn.Johnson@cl.cam.ac.uk Message-id: MIME-version: 1.0 X-Mailer: exmh version 1.6.4+cl+patch 10/10/95 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT > So, my question for this list is whether we should include the parent > directory in the TeX (and Metafont and MetaPost?) search paths by default. I think this is not a good idea. You just have no idea what might be lurking in the parent of the current directory. It might not even belong to the user running the command. It could lead to all kinds of unexpected behaviour. Obviously searching ".." is something that people might well want to do, but I feel quite strongly that it should not happen by default. -- Martyn Johnson maj@cl.cam.ac.uk University of Cambridge Computer Lab Cambridge UK 14-Feb-1996 12:01:53-GMT,2085;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id FAA29670 for ; Wed, 14 Feb 1996 05:01:42 -0700 (MST) Received: from thphy.uni-duesseldorf.de (xerxes.thphy.uni-duesseldorf.de) by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I16Z1USDVK000D60@AXP14.AMS.ORG>; Wed, 14 Feb 1996 06:15:25 -0500 (EST) Received: from macbeth.uni-duesseldorf.de (macbeth.thphy.uni-duesseldorf.de) by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA04230; Wed, 14 Feb 96 12:15:36 +0100 Received: by macbeth.uni-duesseldorf.de (5.x/SMI-SVR4) id AA04802; Wed, 14 Feb 1996 12:13:59 +0100 Date: Wed, 14 Feb 1996 12:13:59 +0100 From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth) Subject: Re: default TeX input path In-reply-to: <199602141059.KAA15698@cadair.elsevier.co.uk> (message from Sebastian Rahtz on Wed, 14 Feb 1996 10:59:09 +0000 (GMT)) To: s.rahtz@elsevier.co.uk Cc: kb@cs.umb.edu, tex-implementors@MATH.AMS.ORG Message-id: <9602141113.AA04802@macbeth.uni-duesseldorf.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit Sebastian wrote: > I reported this from Don last summer, and opinion was against it at > the time for inclusion in the TDS, I recall. I certainly don't think it > belongs in the TDS recommendations, but if Karl makes it the default > in web2c, thats up to him. This is what tds-0.999 says about it: --- cut --- We recommend all implementations have default search paths that start with the current directory (e.g., `\path|.|'). Allowing users to include the parent directory (e.g., `\path|..|') is also helpful. --- cut --- I think this wording is a good compromise. As long as it is possible to configure the search path, i.e. in texmf.cnf or via an environment variable, it doesn't matter that much. Personally, I prefer something like TEXINPUTS=.:./figs:~/lib/tex: i.e. allowing to put all figures in a subdirectory ./figs below the current directory. That's another way to organize one's work, but definitely not the only one. Cheers, Ulrik. 14-Feb-1996 12:05:10-GMT,1584;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id FAA29719 for ; Wed, 14 Feb 1996 05:05:06 -0700 (MST) Received: from skiddaw.elsevier.co.uk by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I16YIPCIY8000JVC@AXP14.AMS.ORG>; Wed, 14 Feb 1996 05:59:53 -0500 (EST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id KAA13205 for ; Wed, 14 Feb 1996 10:58:22 GMT Received: from cadair.elsevier.co.uk (actually host cadair) by snowdon with SMTP (PP); Wed, 14 Feb 1996 10:59:15 +0000 Received: (from srahtz@localhost) by cadair.elsevier.co.uk (8.6.12/8.6.12) id KAA15698; Wed, 14 Feb 1996 10:59:09 GMT Date: Wed, 14 Feb 1996 10:59:09 +0000 (GMT) From: Sebastian Rahtz Subject: Re: default TeX input path In-reply-to: <199602132302.AA03628@terminus.cs.umb.edu> To: kb@cs.umb.edu Cc: tex-implementors@MATH.AMS.ORG Message-id: <199602141059.KAA15698@cadair.elsevier.co.uk> Content-transfer-encoding: 7BIT References: <199602132302.AA03628@terminus.cs.umb.edu> I reported this from Don last summer, and opinion was against it at the time for inclusion in the TDS, I recall. I certainly don't think it belongs in the TDS recommendations, but if Karl makes it the default in web2c, thats up to him. I personally think its a mistake to give special attention to just one method of organizing one's work - no doubt its a sensible way, but its not the only one sebastian 14-Feb-1996 13:44:14-GMT,1351;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id GAA00231 for ; Wed, 14 Feb 1996 06:44:06 -0700 (MST) Received: from ALPHA1.RHBNC.AC.UK by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I170ZBGM5C000JYM@AXP14.AMS.ORG>; Wed, 14 Feb 1996 07:10:38 -0500 (EST) Date: Wed, 14 Feb 1996 12:10:25 +0000 (GMT) From: Philip Taylor (RHBNC) Subject: default TeX input path To: tex-implementors@MATH.AMS.ORG Cc: CHAA006@alpha1.rhbnc.ac.uk Reply-to: P.Taylor@alpha1.rhbnc.ac.uk Message-id: <960214121025.21e254b1@vms.rhbnc.ac.uk> Content-transfer-encoding: 7BIT [Suggestion from DEK in re .;.. v. . as initial element of TeX_Inputs] >> So, my question for this list is whether we should include the parent >> directory in the TeX (and Metafont and MetaPost?) search paths by default. An analogous situation already exists in the emTeX world, where MFJOB creates sub-directories in which it then runs; it is therefore necessary to ensure that MF_Inputs _and_ MF_Bases include to ensure that all works as expected. Since TeX might also be referencing font metrics from the current directory, TeX_font_metrics too may need augmentation. (and perhaps others as well; this clearly needs a lot of thought...). ** Phil. 14-Feb-1996 18:31:40-GMT,2207;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id LAA03474 for ; Wed, 14 Feb 1996 11:30:27 -0700 (MST) Received: from pppl.gov by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I17AD5AHXC000GW8@AXP14.AMS.ORG>; Wed, 14 Feb 1996 11:38:55 -0500 (EST) Received: from draco.pppl.gov (karney@draco.pppl.gov [198.35.6.44]) by pppl.gov (8.7.1/8.7.1) with ESMTP id LAA15697; Wed, 14 Feb 1996 11:38:50 -0500 (EST) Received: (from karney@localhost) by draco.pppl.gov (8.7.3/8.7.3) id LAA12012; Wed, 14 Feb 1996 11:38:47 -0500 (EST) Date: Wed, 14 Feb 1996 11:38:47 -0500 (EST) From: Charles Karney Subject: Re: default TeX input path In-reply-to: <199602132302.AA03628@terminus.cs.umb.edu> (kb@cs.umb.edu) To: kb@cs.umb.edu Cc: tex-implementors@MATH.AMS.ORG Reply-to: karney@princeton.edu Message-id: <199602141638.LAA12012@draco.pppl.gov> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT I think that most users would find including ".." in the default TEXINPUTS to be confusing. There are cases where a facility like this might be useful but it would be best to have the user explicitly request it. On a (slightly) related subject, I would like to raise the suggestion I made to the tex-k mailing list a year ago, namely that it should be easy to PREVENT TeX from opening a file in other than the current directory (or in the directory specified by TEXMFOUT). The motivation is that I would like a safe way of running TeX (and related) programs on a file of suspect origins and I don't want TeX attempting to write into ~/.rhosts etc. Possibly this could be the DEFAULT way that TeX operates, since in all cases that I know about TeX/LaTeX only attempts to open files in the current directory. As Karl has pointed out to me, this is a simple change to make in the web2c sources, which I confess that I haven't done yet. But I would like to see the issue discussed a bit first. -- Charles Karney Plasma Physics Laboratory E-mail: Karney@Princeton.EDU Princeton University Phone: +1 609 243 2607 Princeton, NJ 08543-0451 FAX: +1 609 243 2662 14-Feb-1996 18:39:42-GMT,1731;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id LAA03606 for ; Wed, 14 Feb 1996 11:39:33 -0700 (MST) Received: from june.cs.washington.edu by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I17CN7M3NK000MHK@AXP14.AMS.ORG>; Wed, 14 Feb 1996 12:44:46 -0500 (EST) Received: (mackay@localhost) by june.cs.washington.edu (8.7.2/7.2ju) id JAA10841; Wed, 14 Feb 1996 09:18:36 -0800 Date: Wed, 14 Feb 1996 09:18:36 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Subject: Re: Drivers design about VF To: TEX-IMPLEMENTORS@MATH.AMS.ORG, gaulle@idris.fr Message-id: <199602141718.JAA10841@june.cs.washington.edu> Content-transfer-encoding: 7BIT A more selective approach was promised for dvips at the Florida meeting of TUG. I don't know where that has gone since. %=======================================================================% | N O T I C E | | Please note the changes in address and telephone number below. | | There is no Northwest Computing Support Center any longer. | | Until further notice, I shall be continuing to provide tape | | distributions and whatever other services I can. | | | %=======================================================================% Email concerned with UnixTeX distribution software may be sent To: mackay@cs.washington.edu Pierre A. MacKay Smail: Department of Classics Emeritus Druid for Denny Hall, Mail Stop DH-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-2268 (Message recorder) 15-Feb-1996 11:34:04-GMT,1547;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id EAA12305 for ; Thu, 15 Feb 1996 04:33:55 -0700 (MST) Received: from ifi.informatik.uni-stuttgart.de by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I18BQGNAFK000PBV@AXP14.AMS.ORG>; Thu, 15 Feb 1996 05:30:20 -0500 (EST) Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Thu, 15 Feb 1996 11:29:13 +0100 (MET) Received: by azu.informatik.uni-stuttgart.de; Thu, 15 Feb 1996 11:29:15 +0100 Date: Thu, 15 Feb 1996 11:29:15 +0100 From: Eberhard Mattes Subject: Re: default TeX input path In-reply-to: <960214121025.21e254b1@vms.rhbnc.ac.uk> (CHAA006@vms.rhbnc.ac.uk) To: P.Taylor@alpha1.rhbnc.ac.uk Cc: tex-implementors@MATH.AMS.ORG, CHAA006@alpha1.rhbnc.ac.uk Message-id: <199602151029.LAA18864@azu.informatik.uni-stuttgart.de> Content-transfer-encoding: 7BIT Phil Taylor writes: > An analogous situation already exists in the emTeX world, where MFJOB > creates sub-directories in which it then runs; it is therefore necessary > to ensure that MF_Inputs _and_ MF_Bases include directory> to ensure that all works as expected. Note that nowadays (since MFjob 1.1r) the directory names listed in the MFINPUT environment variable (including the implicit ".") are made absolute before changing to the subdirectory. (This is not yet done for MFBAS.) Eberhard Mattes 15-Feb-1996 12:34:54-GMT,2923;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id FAA12601 for ; Thu, 15 Feb 1996 05:34:51 -0700 (MST) Received: from linus.mitre.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I18D2GHDWG000WVY@AXP14.AMS.ORG>; Thu, 15 Feb 1996 06:07:23 -0500 (EST) Received: from frieda.mitre.org (frieda.mitre.org [129.83.10.3]) by linus.mitre.org (8.6.12/8.6.12) with ESMTP id GAA26157 for ; Thu, 15 Feb 1996 06:07:20 -0500 Received: from localhost (localhost [127.0.0.1]) by frieda.mitre.org (8.6.12/8.6.12) with ESMTP id GAA15713 for ; Thu, 15 Feb 1996 06:08:27 -0500 Date: Thu, 15 Feb 1996 06:08:26 -0500 From: "John D. Ramsdell" Subject: Mail Delivery Subsystem: Returned mail: User unknown To: tex-implementors@MATH.AMS.ORG Message-id: <199602151108.GAA15713@frieda.mitre.org> Content-transfer-encoding: 7BIT Please remove ramsdell@mitre.org from tex-implementors. I suggest you create tex-implementors-request for list administration messages. John ------- Forwarded Message Date: Thu, 15 Feb 1996 06:04:19 -0500 From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-Id: <199602151104.GAA26057@linus.mitre.org> To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="GAA26057.824382259/linus.mitre.org" This is a MIME-encapsulated message - --GAA26057.824382259/linus.mitre.org The original message was received at Thu, 15 Feb 1996 06:04:14 -0500 >From frieda.mitre.org [129.83.10.3] ----- The following addresses had delivery problems ----- (unrecoverable error) ----- Transcript of session follows ----- ... while talking to axp14.ams.org.: >>> RCPT To: <<< 553 unknown or illegal user: tex-implementors-request@AXP14.AMS.ORG 550 ... User unknown ----- Original message follows ----- - --GAA26057.824382259/linus.mitre.org Content-Type: message/rfc822 Return-Path: ramsdell@linus.mitre.org Received: from frieda.mitre.org (frieda.mitre.org [129.83.10.3]) by linus.mitre.org (8.6.12/8.6.12) with ESMTP id GAA26055 for ; Thu, 15 Feb 1996 06:04:14 -0500 Received: from localhost (localhost [127.0.0.1]) by frieda.mitre.org (8.6.12/8.6.12) with ESMTP id GAA15698 for ; Thu, 15 Feb 1996 06:05:20 -0500 Message-Id: <199602151105.GAA15698@frieda.mitre.org> To: tex-implementors-request@MATH.AMS.ORG Date: Thu, 15 Feb 1996 06:05:20 -0500 From: "John D. Ramsdell" unsubscribe Please remove ramsdell@mitre.org from tex-implementors@math.ams.org John - --GAA26057.824382259/linus.mitre.org-- ------- End of Forwarded Message 15-Feb-1996 18:19:28-GMT,2622;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id LAA15985 for ; Thu, 15 Feb 1996 11:19:24 -0700 (MST) Received: from gw.rmcs.cranfield.ac.uk by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I18NWSG1RK00031A@AXP14.AMS.ORG>; Thu, 15 Feb 1996 11:19:24 -0500 (EST) Date: Thu, 15 Feb 1996 16:17:49 +0000 (GMT) From: Brian {Hamilton Kelly} Subject: Re: Drivers design about VF To: tex-implementors@MATH.AMS.ORG Cc: TEX@rmcs.cranfield.ac.uk Message-id: <960215161749.664c@rmcs.cranfield.ac.uk> Content-transfer-encoding: 7BIT In message <199602131138.MAA01562@murnau.idris.fr> of Tue, 13 Feb 1996 12:38:37 +0100, Bernard GAULLE wrote: > Having recently completed 100 virtual fonts and using them with > few drivers, i'm surprised to see how drivers handle virtual fonts. > May be there is a basic technical reason i don't see but i'm wondering... > The three well known drivers i have used are loading all fonts mapped > inside a vf file, even there is no need of them, even no chars are used > nor printed at all. Is it really a perfect design? or is it because > vf aren't extensively used? IMHO i thought they could progress, but > i'm wrong don't hesitate to convince me. > > Could someone tell me about a driver that is more sophisticated > than those i used and which is able to load the only required fonts? SFAIR, my DVItoLN03 program (for the DEC LN03 printer, running under VMS) only loads those glyphs that are used from any font --- and especially so for virtual fonts. The program makes two passes through the DVI file, noting which glyphs are used from each font (physical or virtual) on the first pass. It then generates "internal font" files for the print engine, which include only the glyphs actually used in the document. Finally, it makes a second pass through the DVI file, translating the commands into those that set glyphs from the downloaded internal fonts where each character is imaged. Mind you, it's so long since I wrote it I couldn't say for sure, and I haven't got a "Weaved/TeXed" printed version to hand to check at present. The source is in dvitoln03.web somewhere or other on the CTAN archives; there's also a .ch file for the V4.1 revision (I think). -- Brian {Hamilton Kelly} TeX@rmcs.cranfield.ac.uk Smail: School of Engineering & Applied Science, Royal Military College of Science, Shrivenham, SWINDON SN6 8LA, U.K. Phone: Swindon (01793) 785252 (UK), +44-1793-785252 (International) 16-Feb-1996 14:55:39-GMT,6583;000000000001 Received: from listserv.gmd.de ([192.88.97.1]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id HAA26149 for ; Fri, 16 Feb 1996 07:54:40 -0700 (MST) Message-Id: <199602161454.HAA26149@csc-sun.math.utah.edu> Date: Fri, 16 Feb 1996 15:53:43 +0100 Reply-to: postmaster@listserv.gmd.de From: "LSMTP for OpenVMS v1.0a" Subject: Undelivered mail To: beebe@MATH.UTAH.EDU X-Report-Type: Nondelivery; boundary="> Error description:" An error was detected while processing the enclosed message. A list of the affected recipient follows. This list is in a special format that allows software like LISTSERV to automatically take action on incorrect addresses; you can safely ignore the numeric codes. --> Error description: Error-for: PEB@MPPMU.MPG.DE Error-Code: 3 Error-Text: Mailer iws132a.MPPMU.MPG.DE said: "550 PEB@iws132a.MPPMU.MPG.DE... User unknown" Error-End: One error reported. ------------------------------ Original message ------------------------------ Received: from vm.gmd.de by listserv.gmd.de (LSMTP for OpenVMS v1.0a) with SMTP id 5F9244BF ; Fri, 16 Feb 1996 15:53:27 +0100 Received: from DEARN (NJE origin SMTP@DEARN) by VM.GMD.DE (LMail V1.2b/1.8b) with BSMTP id 3065; Fri, 16 Feb 1996 15:54:16 +0100 Received: from listserv.gmd.de by vm.gmd.de (IBM VM SMTP V2R2) with TCP; Fri, 16 Feb 96 15:54:08 +0100 Received: from axp14.ams.org by listserv.gmd.de (LSMTP for OpenVMS v1.0a) with SMTP id BC6681A4 ; Fri, 16 Feb 1996 15:48:53 +0100 Received: from vax02.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I19YLOQ5DC00087M@AXP14.AMS.ORG>; Fri, 16 Feb 1996 09:34:35 -0500 (EST) Received: from csc-sun.math.utah.edu by VAX02.AMS.ORG (PMDF #7286 ) id <01I19YKYC0OG8WVYYR@VAX02.AMS.ORG>; Fri, 16 Feb 1996 09:34:19 EST Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu Õ128.110.198.3þ) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id HAA25966; Fri, 16 Feb 1996 07:33:44 -0700 (MST) Received: (from beebe@localhost) by plot79.math.utah.edu (8.7.1/8.7.1) id HAA10004; Fri, 16 Feb 1996 07:33:42 -0700 (MST) Date: Fri, 16 Feb 1996 07:33:42 -0700 (MST) From: "Nelson H. F. Beebe" Subject: Re: TEXMFOUT To: tex-implementors@MATH.AMS.ORG Cc: beebe@math.utah.edu Message-id: Content-transfer-encoding: 7BIT X-US-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe In recent mail to tex-implementors, Charles Karney suggests that a TEXMFOUT variable should be available to provide a way to limit the directories in which TeX and METAFONT can open a file for output. I believe that this is an EXCELLENT idea, and should be implemented with TEXMFOUT set by default to the current directory (in UNIX, "."). This would be a good way to limit attempts to overwrite critical files. While we are at it, I believe that TeX should be made to log the opening of output files too. Consider the following simple test file, foo.tex: \newwrite\x \openout\x=foo.out \write\x{Hello} \closeout\x \bye Now run (UNIX) TeX: % tex foo.tex This is TeX, Version 3.1415 (C version 6.1) (foo.tex Õ1þ ) Output written on foo.dvi (1 page, 196 bytes). Transcript written on foo.log. Notice the COMPLETE ABSENCE of a terminal message about the opened output file. Here is what the log file says: This is TeX, Version 3.1415 (C version 6.1) (format=plain 94.6.21) 16 FEB 1996 07:07 **foo.tex (foo.tex \x=\write0 Õ1þ ) Output written on foo.dvi (1 page, 196 bytes). Evidently, a write has occurred, but no mention is made of the output file name. Nevertheless, it got written: % cat foo.out Hello I suggest that UNIX implementors might want to go even further: namely, to forbid the opening of files whose names begin with a ".", which in UNIX are `hidden' files (i.e. the directory listing command, ls, by default does not show them). Such files are conventionally used for user startup and configuration information that needs to be present, but which one doesn't want cluttering directory listings. This change would prevent overwriting of such as .login, .cshrc, and most importantly, .rhosts, which is the file authorizing password-less login from remote hosts and users. Also, since the directory lister normally hides such files, a user whose TeX job has just overwritten one of them is unlikely to notice the change. Although one might conceivably argue that there might be some use for using hidden files for TeX output, such as a history of job runs in a journal production environment, or some such thing, I think the drawbacks of damage to critical files far outweigh the advantages, and in the interests of security, the capability should be removed from TeX. Now some non-TeX background... The recent flurry of attacks on Microsoft Word 6.0, which by default executes an embedded macro header when it opens a document for screen display, suggests that similar attacks on TeX are likely to occur in the future, although they are necessarily more limited because of TeX's restricted system operations capabilities. The Word 6.0 macro language is claimed to be comparable in power to Visual Basic, and to have full access to all operating system and window system facilities. A number of virus have already been identified, ranging from the benign `This proves we can do it', to ones that delete the entire file system, or infect all other Word 6 documents in the file system. Since Microsoft Word is available on both IBM PC and Apple Macintosh platforms, and has been the number 2 product in the word processing market (and likely, soon to be number 1 if Corel doesn't succeed in resurrecting WordPerfect after buying it from Novell last month), the potential impact of such viruses is large, particularly now that World-Wide Web browsers can be configured to download and open files for display using any program whatever for the display job. ======================================================================== Nelson H. F. Beebe Tel: +1 801 581 5254 Center for Scientific Computing FAX: +1 801 581 4148 Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu University of Utah URL: http://www.math.utah.edu/~beebe Salt Lake City, UT 84112, USA ======================================================================== 16-Feb-1996 15:17:41-GMT,2290;000000000001 Received: from thphy.uni-duesseldorf.de (xerxes.thphy.uni-duesseldorf.de [134.99.64.123]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with SMTP id IAA26531 for ; Fri, 16 Feb 1996 08:17:31 -0700 (MST) Received: from lancelot.thphy.uni-duesseldorf.de by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA08976; Fri, 16 Feb 96 16:15:24 +0100 Received: (from vieth@localhost) by lancelot.thphy.uni-duesseldorf.de (8.6.12/8.6.9) id QAA00752; Fri, 16 Feb 1996 16:13:52 +0100 Date: Fri, 16 Feb 1996 16:13:52 +0100 Message-Id: <199602161513.QAA00752@lancelot.thphy.uni-duesseldorf.de> To: beebe@math.utah.edu Cc: tex-implementors@MATH.AMS.ORG, beebe@math.utah.edu In-Reply-To: Subject: Re: TEXMFOUT From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit > In recent mail to tex-implementors, Charles Karney suggests that a > TEXMFOUT variable should be available to provide a way to limit the > directories in which TeX and METAFONT can open a file for output. > I believe that this is an EXCELLENT idea, and should be implemented > with TEXMFOUT set by default to the current directory (in UNIX, "."). > This would be a good way to limit attempts to overwrite critical > files. I think there might some misunderstanding here, but the present version of web2c/kpathsea-2.6 already provides a TEXMFOUT variable, but this has quite a different meaning than what you have in mind. TEXMFOUT, if set, can be used to redirect the output files to some other directory than the current directory where they would normally be placed. However, TEXMFOUT has nothing to do with restring the directories to which output might be written. >From kpathsea.texi (2.6): -------- If a @code{MakeTeX@dots{}} script fails, the invocation is appended to a file @file{missfont.log} in the current directory. If the current directory is not writable and the environment variable @samp{TEXMFOUTPUT} is set, its value is used. Otherwise, nothing is written. -------- Hope this clarifies the situation, especially for the non-Unix people. Cheers, Ulrik. P.S. Why do I always get bounces and mailer-error protocols when replying or posting to tex-implementors? 16-Feb-1996 16:16:21-GMT,2452;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id JAA27202 for ; Fri, 16 Feb 1996 09:16:13 -0700 (MST) Received: from thphy.uni-duesseldorf.de (xerxes.thphy.uni-duesseldorf.de) by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I19ZYXC02O0004RZ@AXP14.AMS.ORG>; Fri, 16 Feb 1996 10:16:44 -0500 (EST) Received: from lancelot.thphy.uni-duesseldorf.de by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA08976; Fri, 16 Feb 96 16:15:24 +0100 Received: (from vieth@localhost) by lancelot.thphy.uni-duesseldorf.de (8.6.12/8.6.9) id QAA00752; Fri, 16 Feb 1996 16:13:52 +0100 Date: Fri, 16 Feb 1996 16:13:52 +0100 From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth) Subject: Re: TEXMFOUT In-reply-to: To: beebe@Math.Utah.edu Cc: tex-implementors@MATH.AMS.ORG, beebe@Math.Utah.edu Message-id: <199602161513.QAA00752@lancelot.thphy.uni-duesseldorf.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit > In recent mail to tex-implementors, Charles Karney suggests that a > TEXMFOUT variable should be available to provide a way to limit the > directories in which TeX and METAFONT can open a file for output. > I believe that this is an EXCELLENT idea, and should be implemented > with TEXMFOUT set by default to the current directory (in UNIX, "."). > This would be a good way to limit attempts to overwrite critical > files. I think there might some misunderstanding here, but the present version of web2c/kpathsea-2.6 already provides a TEXMFOUT variable, but this has quite a different meaning than what you have in mind. TEXMFOUT, if set, can be used to redirect the output files to some other directory than the current directory where they would normally be placed. However, TEXMFOUT has nothing to do with restring the directories to which output might be written. >From kpathsea.texi (2.6): -------- If a @code{MakeTeX@dots{}} script fails, the invocation is appended to a file @file{missfont.log} in the current directory. If the current directory is not writable and the environment variable @samp{TEXMFOUTPUT} is set, its value is used. Otherwise, nothing is written. -------- Hope this clarifies the situation, especially for the non-Unix people. Cheers, Ulrik. P.S. Why do I always get bounces and mailer-error protocols when replying or posting to tex-implementors? 16-Feb-1996 16:36:24-GMT,1395;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id JAA27454 for ; Fri, 16 Feb 1996 09:35:17 -0700 (MST) Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I19Z03VPNK0004O6@AXP14.AMS.ORG>; Fri, 16 Feb 1996 10:25:12 -0500 (EST) Date: Fri, 16 Feb 1996 10:25:10 -0500 (EST) From: bbeeton Subject: Re: TEXMFOUT In-reply-to: <199602161513.QAA00752@lancelot.thphy.uni-duesseldorf.de> To: vieth@thphy.uni-duesseldorf.de Cc: tex-implementors@MATH.AMS.ORG Message-id: <824484310.929136.BNB@MATH.AMS.ORG> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Mail-System-Version: ulrik vieth asks: P.S. Why do I always get bounces and mailer-error protocols when replying or posting to tex-implementors? this list is maintained by hand; it is a private list. not everyone on the list keeps me posted as to their changes of address. if anyone does happen to get a bounce or other mailer error, please forward it to me and i will correct the list (almost) immediately. similarly, if you know your address is changing, please send me your new one, or ask to be removed (permanently or temporarily). this will save anyone who posts to the list a lot of annoyance. -- bb 16-Feb-1996 16:36:38-GMT,5170;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id JAA27461 for ; Fri, 16 Feb 1996 09:36:35 -0700 (MST) Received: from vax02.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I19YLOQ5DC00087M@AXP14.AMS.ORG>; Fri, 16 Feb 1996 09:34:35 -0500 (EST) Received: from csc-sun.math.utah.edu by VAX02.AMS.ORG (PMDF #7286 ) id <01I19YKYC0OG8WVYYR@VAX02.AMS.ORG>; Fri, 16 Feb 1996 09:34:19 EST Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id HAA25966; Fri, 16 Feb 1996 07:33:44 -0700 (MST) Received: (from beebe@localhost) by plot79.math.utah.edu (8.7.1/8.7.1) id HAA10004; Fri, 16 Feb 1996 07:33:42 -0700 (MST) Date: Fri, 16 Feb 1996 07:33:42 -0700 (MST) From: "Nelson H. F. Beebe" Subject: Re: TEXMFOUT To: tex-implementors@MATH.AMS.ORG Cc: beebe@math.utah.edu Message-id: Content-transfer-encoding: 7BIT X-US-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe In recent mail to tex-implementors, Charles Karney suggests that a TEXMFOUT variable should be available to provide a way to limit the directories in which TeX and METAFONT can open a file for output. I believe that this is an EXCELLENT idea, and should be implemented with TEXMFOUT set by default to the current directory (in UNIX, "."). This would be a good way to limit attempts to overwrite critical files. While we are at it, I believe that TeX should be made to log the opening of output files too. Consider the following simple test file, foo.tex: \newwrite\x \openout\x=foo.out \write\x{Hello} \closeout\x \bye Now run (UNIX) TeX: % tex foo.tex This is TeX, Version 3.1415 (C version 6.1) (foo.tex [1] ) Output written on foo.dvi (1 page, 196 bytes). Transcript written on foo.log. Notice the COMPLETE ABSENCE of a terminal message about the opened output file. Here is what the log file says: This is TeX, Version 3.1415 (C version 6.1) (format=plain 94.6.21) 16 FEB 1996 07:07 **foo.tex (foo.tex \x=\write0 [1] ) Output written on foo.dvi (1 page, 196 bytes). Evidently, a write has occurred, but no mention is made of the output file name. Nevertheless, it got written: % cat foo.out Hello I suggest that UNIX implementors might want to go even further: namely, to forbid the opening of files whose names begin with a ".", which in UNIX are `hidden' files (i.e. the directory listing command, ls, by default does not show them). Such files are conventionally used for user startup and configuration information that needs to be present, but which one doesn't want cluttering directory listings. This change would prevent overwriting of such as .login, .cshrc, and most importantly, .rhosts, which is the file authorizing password-less login from remote hosts and users. Also, since the directory lister normally hides such files, a user whose TeX job has just overwritten one of them is unlikely to notice the change. Although one might conceivably argue that there might be some use for using hidden files for TeX output, such as a history of job runs in a journal production environment, or some such thing, I think the drawbacks of damage to critical files far outweigh the advantages, and in the interests of security, the capability should be removed from TeX. Now some non-TeX background... The recent flurry of attacks on Microsoft Word 6.0, which by default executes an embedded macro header when it opens a document for screen display, suggests that similar attacks on TeX are likely to occur in the future, although they are necessarily more limited because of TeX's restricted system operations capabilities. The Word 6.0 macro language is claimed to be comparable in power to Visual Basic, and to have full access to all operating system and window system facilities. A number of virus have already been identified, ranging from the benign `This proves we can do it', to ones that delete the entire file system, or infect all other Word 6 documents in the file system. Since Microsoft Word is available on both IBM PC and Apple Macintosh platforms, and has been the number 2 product in the word processing market (and likely, soon to be number 1 if Corel doesn't succeed in resurrecting WordPerfect after buying it from Novell last month), the potential impact of such viruses is large, particularly now that World-Wide Web browsers can be configured to download and open files for display using any program whatever for the display job. ======================================================================== Nelson H. F. Beebe Tel: +1 801 581 5254 Center for Scientific Computing FAX: +1 801 581 4148 Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu University of Utah URL: http://www.math.utah.edu/~beebe Salt Lake City, UT 84112, USA ======================================================================== 16-Feb-1996 21:00:39-GMT,4046;000000000001 Received: from pppl.gov (root@pppl.gov [192.55.106.85]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id OAA00662 for ; Fri, 16 Feb 1996 14:00:25 -0700 (MST) Received: from draco.pppl.gov (karney@draco.pppl.gov [198.35.6.44]) by pppl.gov (8.7.1/8.7.1) with ESMTP id QAA18637; Fri, 16 Feb 1996 16:00:08 -0500 (EST) Received: (from karney@localhost) by draco.pppl.gov (8.7.3/8.7.3) id QAA29443; Fri, 16 Feb 1996 16:00:05 -0500 (EST) Date: Fri, 16 Feb 1996 16:00:05 -0500 (EST) Message-Id: <199602162100.QAA29443@draco.pppl.gov> From: Charles Karney To: tex-implementors@MATH.AMS.ORG CC: beebe@math.utah.edu, vieth@thphy.uni-duesseldorf.de In-reply-to: <199602161513.QAA00752@lancelot.thphy.uni-duesseldorf.de> (vieth%thphy.uni-duesseldorf.de@Princeton.EDU) Subject: Re: TEXMFOUT Reply-to: karney@princeton.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Here is an concrete suggestion of the way in which my suggestion of limiting where TeX can write files might be implemented. (1) First, the current situation with \openout (with Unix/web2c/kpathsea) is: (a) if path name contains no ".", append ".tex"; (b) attempt to open resulting file for writing; (c) if (b) fails and if TEXMFOUTPUT is defined, prepend TEXMFOUTPUT/ and attempt to open file for writing again; (d) if (b) and (c) fail, prompt for file name and go to (a). A few notes: (i) step (c) does a textual concatenation. Thus if the original path name is /u/smith/.rhosts and if TEXMFOUTPUT=/tmp, then (c) attempts to open /tmp//u/smith/.rhosts. On most (but not all?) Unix platforms the "//" is converted to / and /tmp/u/smith/.rhosts is opened (and this will fail unless the directory /tmp/u/smith exists). (ii) if the user responds with a RETURN in step (d), then the pathname is set to "" and the procedure results in ".tex" (a hidden file!) being opened. (Typing a RETURN to error messages is an automatic response for a lot of users!) (2) Here's my proposal for a "safer" implementation. This supposes that you ONLY want TeX to write files whose path name includes a directory. (I think that this is the case at our site.) (a) if the path name includes a directory, print error message, prompt for a file name, and start over; (b) if the file name is empty, open /dev/null (or NUL: or whatever) for writing and return; (c) else if the file name contains no ".", append ".tex"; (d) attempt to open resulting file for writing; (e) if (d) fails and if TEXMFOUTPUT is defined, prepend TEXMFOUTPUT/ and attempt to open file for writing again.; (d) if (d) and (e) fail, print error message, prompt for a file name, and start over. In all cases, log the path name of the opened file in a similar manner to files which are \input. Some variations: (3) Keep the current behavior. Activate the "safe" mode if TEXSAFE is defined. Then cd /tmp;env TEXSAFE=1 tex \\batchmode \\input %s might be a suitable mailcap entry for TeX. This variation would be desirable if people currently expect TeX to be able to open files anywhere. (4) Permit relative directory specifications which don't include "..", i.e., permit directories to be opened BENEATH the current directory. This might be a reasonably safe alternative to (3). (5) Strip off the directory part of the path name rather than complain. Another resonably safe alternative to (3). (6) ONLY attempt to open the file in TEXMFOUTPUT (default value = "."). This might be useful if the suspect file is in a user's home directory. (7) Forbid hidden file names (begin with a "."). You might also worry about other weird characters in a file name (space, return, characters with the 8th bit on). (But on some systems, such characters are perfectly OK.) (8) Alter the behavior with an empty path name to open some canonical file name like "texput.tex". -- Charles Karney Plasma Physics Laboratory E-mail: Karney@Princeton.EDU Princeton University Phone: +1 609 243 2607 Princeton, NJ 08543-0451 FAX: +1 609 243 2662 16-Feb-1996 22:02:27-GMT,4224;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id PAA01367 for ; Fri, 16 Feb 1996 15:02:11 -0700 (MST) Received: from pppl.gov by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I1AC3I3TLS00070I@AXP14.AMS.ORG>; Fri, 16 Feb 1996 16:00:47 -0500 (EST) Received: from draco.pppl.gov (karney@draco.pppl.gov [198.35.6.44]) by pppl.gov (8.7.1/8.7.1) with ESMTP id QAA18637; Fri, 16 Feb 1996 16:00:08 -0500 (EST) Received: (from karney@localhost) by draco.pppl.gov (8.7.3/8.7.3) id QAA29443; Fri, 16 Feb 1996 16:00:05 -0500 (EST) Date: Fri, 16 Feb 1996 16:00:05 -0500 (EST) From: Charles Karney Subject: Re: TEXMFOUT In-reply-to: <199602161513.QAA00752@lancelot.thphy.uni-duesseldorf.de> (vieth%thphy.uni-duesseldorf.de@Princeton.EDU) To: tex-implementors@MATH.AMS.ORG Cc: beebe@Math.Utah.edu, vieth@thphy.uni-duesseldorf.de Reply-to: karney@princeton.edu Message-id: <199602162100.QAA29443@draco.pppl.gov> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Here is an concrete suggestion of the way in which my suggestion of limiting where TeX can write files might be implemented. (1) First, the current situation with \openout (with Unix/web2c/kpathsea) is: (a) if path name contains no ".", append ".tex"; (b) attempt to open resulting file for writing; (c) if (b) fails and if TEXMFOUTPUT is defined, prepend TEXMFOUTPUT/ and attempt to open file for writing again; (d) if (b) and (c) fail, prompt for file name and go to (a). A few notes: (i) step (c) does a textual concatenation. Thus if the original path name is /u/smith/.rhosts and if TEXMFOUTPUT=/tmp, then (c) attempts to open /tmp//u/smith/.rhosts. On most (but not all?) Unix platforms the "//" is converted to / and /tmp/u/smith/.rhosts is opened (and this will fail unless the directory /tmp/u/smith exists). (ii) if the user responds with a RETURN in step (d), then the pathname is set to "" and the procedure results in ".tex" (a hidden file!) being opened. (Typing a RETURN to error messages is an automatic response for a lot of users!) (2) Here's my proposal for a "safer" implementation. This supposes that you ONLY want TeX to write files whose path name includes a directory. (I think that this is the case at our site.) (a) if the path name includes a directory, print error message, prompt for a file name, and start over; (b) if the file name is empty, open /dev/null (or NUL: or whatever) for writing and return; (c) else if the file name contains no ".", append ".tex"; (d) attempt to open resulting file for writing; (e) if (d) fails and if TEXMFOUTPUT is defined, prepend TEXMFOUTPUT/ and attempt to open file for writing again.; (d) if (d) and (e) fail, print error message, prompt for a file name, and start over. In all cases, log the path name of the opened file in a similar manner to files which are \input. Some variations: (3) Keep the current behavior. Activate the "safe" mode if TEXSAFE is defined. Then cd /tmp;env TEXSAFE=1 tex \\batchmode \\input %s might be a suitable mailcap entry for TeX. This variation would be desirable if people currently expect TeX to be able to open files anywhere. (4) Permit relative directory specifications which don't include "..", i.e., permit directories to be opened BENEATH the current directory. This might be a reasonably safe alternative to (3). (5) Strip off the directory part of the path name rather than complain. Another resonably safe alternative to (3). (6) ONLY attempt to open the file in TEXMFOUTPUT (default value = "."). This might be useful if the suspect file is in a user's home directory. (7) Forbid hidden file names (begin with a "."). You might also worry about other weird characters in a file name (space, return, characters with the 8th bit on). (But on some systems, such characters are perfectly OK.) (8) Alter the behavior with an empty path name to open some canonical file name like "texput.tex". -- Charles Karney Plasma Physics Laboratory E-mail: Karney@Princeton.EDU Princeton University Phone: +1 609 243 2607 Princeton, NJ 08543-0451 FAX: +1 609 243 2662 17-Feb-1996 14:30:26-GMT,3377;000000000001 Received: from uu3.psi.com (uu3.psi.com [38.145.250.2]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with SMTP id HAA07674 for ; Sat, 17 Feb 1996 07:30:24 -0700 (MST) Received: from lrw.UUCP by uu3.psi.com (5.65b/4.0.940727-PSI/PSINet) via UUCP; id AA05498 for ; Sat, 17 Feb 96 09:22:19 -0500 Message-Id: <9602171422.AA05498@uu3.psi.com> Received: by lrw.UUCP (DECUS UUCP w/Smail); Sat, 17 Feb 96 08:55:57 EDT Date: Sat, 17 Feb 96 08:55:57 EDT From: Jerry Leichter To: beebe@math.utah.edu Subject: Re: TEXMFOUT X-Vms-Mail-To: UUCP%"beebe@math.utah.edu" I'm getting that "deja vu all over again" feeling. *Exactly* this same discussion took place years back - perhaps 5 or so. As I recall, it initially arose in the responses to a proposal to add the equiva- lent of the "system()" call to TeX - i.e., some way for a TeX job to cause a system command to be executed. (The suggestion was to do this through some special file name, so that TeX itself would not be changed.) Needless to say, this would open the way for some nasty "TeX viruses". The discussion of the dangers thereof quickly lead to a discussion of the dangers of TeX's unres- tricted ability to open files. Note that the ability to open a file like .login in the login directory on a Unix system (or LOGIN.COM on a VMS system, or AUTOEXEC.BAT on a MS/DOS system) is tantamount to the ability to execute arbitrary system commands. Then as now, there were suggestions along the lines of "well, the *dangerous* files all have names starting with '.', so let's forbid those". Besides leading to a situation in which you can never know what files it *is* safe to open in a TeX file - since *some* implementor on *some* system may consider your file name "dangerous" - these approaches are fundamentally unsound. No one can make a complete list of "dangerous" file names - there are just too many tricky things that can be done. The old discussion made that clear. I recall *no* significant opposition to the idea of being able to run TeX in a "restricted" mode, where (for example) TeX could only open output files in the current directory. Given this, you could at least make sure that, when TeX'ing files of uncertain provenance, you did so in a "safe" directory. An interesting question is what the default mode should be: Restricted or unrestricted. The obvious answer is "unrestricted, for compatibility", but in reality this means most people will *never* use the restricted mode. (It was recalled in the previous discussion that, back in the '70's, IBM had a text formatter named something like SCRIPT. SCRIPT had the ability to execute system commands. The dangers of this came to be pointed out. In the next version, this ability had to be explicitly enabled when you ran SCRIPT. Users whose old, clever SCRIPT files no longer worked without intervention bitched and moaned, but IBM wouldn't back down - and it was right.) As I recall, most people agreed that "restricted by default" was the way to go - especially after an examination of all the widely-used macro packages revealed that they never created files outside of the current directory anyway. So, here we are, 5 or so years down the road. As far as I know, no version of TeX implements a "restricted output" mode. And we're repeating the same arguments. -- Jerry 19-Feb-1996 10:42:10-GMT,5568;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id DAA20903 for ; Mon, 19 Feb 1996 03:42:08 -0700 (MST) From: msinke@natlab.research.philips.com Received: from 130.144.65.1 by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I1DUYL87WG000EQZ@AXP14.AMS.ORG>; Mon, 19 Feb 1996 04:33:39 -0500 (EST) Received: (from smap@localhost) by relay.philips.nl (8.6.9/8.6.9-950414) id KAA08924 for ; Mon, 19 Feb 1996 10:33:05 +0100 Received: from unknown(192.26.173.32) by ns.philips.nl via smap (V1.3+ESMTP) with ESMTP id sma008907; Mon Feb 19 10:32:43 1996 Received: from natlab.research.philips.com (prle.prl.philips.nl [130.144.1.112]) by smtp.nl.cis.philips.com (8.6.10/8.6.10-0.9z-02May95) with SMTP id KAA06095 for ; Mon, 19 Feb 1996 10:33:38 +0100 Received: by natlab.research.philips.com; Mon, 19 Feb 1996 10:32:38 +0100 Received: by eleanor.prl.philips.nl; Mon, 19 Feb 96 10:32:36 +0100 Date: Mon, 19 Feb 1996 10:32:36 +0100 Subject: Re: TEXMFOUT To: tex-implementors@MATH.AMS.ORG Message-id: <9602190932.AA03194@eleanor.prl.philips.nl> Content-transfer-encoding: 7BIT Charles Karney wrote, > Here is an concrete suggestion of the way in which my suggestion of > limiting where TeX can write files might be implemented. > > (1) First, the current situation with \openout (with Unix/web2c/kpathsea) > is: > > (a) if path name contains no ".", append ".tex"; (in my armTeX implementation, second the file without .tex is tried. That's less safe, but as the dot is a directory seperator on my system (RISC OS), this prevents the user from making lots of useless directories, containing only a file 'tex'. BTW, my implementation is based on web2c-6.2. IMHO, I thought that this was also the expected behaviour under Unix (but I guess I'm wrong...) > > (b) attempt to open resulting file for writing; > > (c) if (b) fails and if TEXMFOUTPUT is defined, prepend TEXMFOUTPUT/ and > attempt to open file for writing again; > > (d) if (b) and (c) fail, prompt for file name and go to (a). > > A few notes: > > (i) step (c) does a textual concatenation. Thus if the original path name > is /u/smith/.rhosts and if TEXMFOUTPUT=/tmp, then (c) attempts to open > /tmp//u/smith/.rhosts. On most (but not all?) Unix platforms the "//" is > converted to / and /tmp/u/smith/.rhosts is opened (and this will fail > unless the directory /tmp/u/smith exists). > > (ii) if the user responds with a RETURN in step (d), then the pathname is > set to "" and the procedure results in ".tex" (a hidden file!) being > opened. (Typing a RETURN to error messages is an automatic response for a > lot of users!) > > (2) Here's my proposal for a "safer" implementation. This supposes that > you ONLY want TeX to write files whose path name includes a directory. (I > think that this is the case at our site.) > > (a) if the path name includes a directory, print error message, prompt > for a file name, and start over; > > (b) if the file name is empty, open /dev/null (or NUL: or whatever) for > writing and return; > > (c) else if the file name contains no ".", append ".tex"; > > (d) attempt to open resulting file for writing; > > (e) if (d) fails and if TEXMFOUTPUT is defined, prepend TEXMFOUTPUT/ and > attempt to open file for writing again.; > > (d) if (d) and (e) fail, print error message, prompt for a file name, and > start over. > > In all cases, log the path name of the opened file in a similar manner to > files which are \input. > > Some variations: > > (3) Keep the current behavior. Activate the "safe" mode if TEXSAFE is > defined. Then > > cd /tmp;env TEXSAFE=1 tex \\batchmode \\input %s > > might be a suitable mailcap entry for TeX. This variation would be > desirable if people currently expect TeX to be able to open files anywhere. > > (4) Permit relative directory specifications which don't include "..", > i.e., permit directories to be opened BENEATH the current directory. This > might be a reasonably safe alternative to (3). I thought that, e.g., LaTeX2e depends on writing in directories beneath the current one, so I'm in support of this alternative. > > (5) Strip off the directory part of the path name rather than complain. > Another resonably safe alternative to (3). This would result in uncertainty for the user. One of TeX's main strengths is its stability, and confusing users surely isn't stable. > > (6) ONLY attempt to open the file in TEXMFOUTPUT (default value = "."). > This might be useful if the suspect file is in a user's home directory. Possible, but VERY restricted. This means that the user should set TEXMFOUTPUT for the jobs that try to write in other directories. Of course, this might be what you mean, but certainly only in unsafe places (like the user's home directory), not in some scratch or /tmp directory. > > (7) Forbid hidden file names (begin with a "."). You might also worry > about other weird characters in a file name (space, return, characters with > the 8th bit on). (But on some systems, such characters are perfectly OK.) 8-bit characters are supported on some platforms, and even while the filenames used on such platforms might not be portable, I think we should not beforehand forbid these. File names starting with a leading dot are dangerous, though, and should be forbidden (IMO). > > (8) Alter the behavior with an empty path name to open some canonical file > name like "texput.tex". Maybe these comments are helpful. Mark. 19-Feb-1996 10:51:38-GMT,2053;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id DAA20952 for ; Mon, 19 Feb 1996 03:51:35 -0700 (MST) Received: from lumiere.idris.fr by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I1DVAXRR3K000GQG@AXP14.AMS.ORG>; Mon, 19 Feb 1996 04:43:52 -0500 (EST) Received: from murnau.idris.fr (murnau.idris.fr [130.84.8.20]) by lumiere.idris.fr (8.7.3/8.7.3) with ESMTP id KAA20536 for ; Mon, 19 Feb 1996 10:43:30 +0100 Received: (from gaulle@localhost) by murnau.idris.fr (8.7.3/8.7.1) id KAA00255; Mon, 19 Feb 1996 10:43:28 +0100 Date: Mon, 19 Feb 1996 10:43:28 +0100 From: Bernard GAULLE Subject: Re: Drivers design about VF To: tex-implementors@MATH.AMS.ORG Message-id: <199602190943.KAA00255@murnau.idris.fr> Content-transfer-encoding: 7BIT It seems that i missed to answer to the list. Sorry Tom and Paul. I'ld greatly appreciate other experiences with .vf files. --bg ------- Start of forwarded message ------- From: gaulle (Bernard GAULLE) To: "Tomas G. Rokicki" Subject: Re: Drivers design about VF Date: Thu, 15 Feb 96 14:15:56 MET >>>>> On Tue, 13 Feb 1996 08:28:15 -0800 (PST), >>>>> "Tomas G. Rokicki" write about "Re: Drivers design about VF": TGR> Which drivers have you seen this behavior with? TGR> In particular, does dvips do this? Ok, the appearence wasn't really the truth. I made more tries with no pk files available and checked which font MakeTeXPK was doing. DVIPS open and "loads" the vf and just say "Defining font xx" which looks fine. (by the way, if one font was previously "Loaded" it just says "(Already known.)" without telling which one). Looking also ok for xdvi with "-l" option (which lists the "fonts used"). For Textures it isn't so easy to test, but as far as i correctly manage the metrics suitcases, i found that the maximum number of fonts was anormally reached. --bg ------- End of forwarded message ------- 23-Feb-1996 11:14:50-GMT,6099;000000000001 Received: from Niord.shsu.edu (niord.shsu.edu [192.92.115.8]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with SMTP id EAA27050 for ; Fri, 23 Feb 1996 04:14:48 -0700 (MST) Message-Id: <199602231114.EAA27050@csc-sun.math.utah.edu> Date: Fri, 23 Feb 1996 05:00:32 CDT From: Local delivery agent To: Subject: LOCAL delivery error X-Report-Type: Nondelivery; boundary="> Error description:" Note: this message was generated automatically. An error was detected while processing the enclosed message. A list of the affected recipients follows. This list is in a special format that allows software like LISTSERV to automatically take action on incorrect addresses; you can safely ignore the numeric codes. --> Error description: Error-For: bed_gdg@SHSU.edu Error-Code: 2 Error-Text: Error in delivery to user BED_GDG retry count exceeded Error-End: 1 error detected ------------------------------ Rejected message ------------------------------ Received: from axp14.ams.org by Niord.shsu.edu (MX V4.1 AXP) with SMTP; Fri, 16 Feb 1996 08:50:38 CDT Received: from vax02.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I19YLOQ5DC00087M@AXP14.AMS.ORG>; Fri, 16 Feb 1996 09:34:35 -0500 (EST) Received: from csc-sun.math.utah.edu by VAX02.AMS.ORG (PMDF #7286 ) id <01I19YKYC0OG8WVYYR@VAX02.AMS.ORG>; Fri, 16 Feb 1996 09:34:19 EST Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id HAA25966; Fri, 16 Feb 1996 07:33:44 -0700 (MST) Received: (from beebe@localhost) by plot79.math.utah.edu (8.7.1/8.7.1) id HAA10004; Fri, 16 Feb 1996 07:33:42 -0700 (MST) Date: Fri, 16 Feb 1996 07:33:42 -0700 (MST) From: "Nelson H. F. Beebe" Subject: Re: TEXMFOUT To: tex-implementors@MATH.AMS.ORG CC: beebe@math.utah.edu Message-ID: Content-Transfer-Encoding: 7BIT X-US-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe In recent mail to tex-implementors, Charles Karney suggests that a TEXMFOUT variable should be available to provide a way to limit the directories in which TeX and METAFONT can open a file for output. I believe that this is an EXCELLENT idea, and should be implemented with TEXMFOUT set by default to the current directory (in UNIX, "."). This would be a good way to limit attempts to overwrite critical files. While we are at it, I believe that TeX should be made to log the opening of output files too. Consider the following simple test file, foo.tex: \newwrite\x \openout\x=foo.out \write\x{Hello} \closeout\x \bye Now run (UNIX) TeX: % tex foo.tex This is TeX, Version 3.1415 (C version 6.1) (foo.tex [1] ) Output written on foo.dvi (1 page, 196 bytes). Transcript written on foo.log. Notice the COMPLETE ABSENCE of a terminal message about the opened output file. Here is what the log file says: This is TeX, Version 3.1415 (C version 6.1) (format=plain 94.6.21) 16 FEB 1996 07:07 **foo.tex (foo.tex \x=\write0 [1] ) Output written on foo.dvi (1 page, 196 bytes). Evidently, a write has occurred, but no mention is made of the output file name. Nevertheless, it got written: % cat foo.out Hello I suggest that UNIX implementors might want to go even further: namely, to forbid the opening of files whose names begin with a ".", which in UNIX are `hidden' files (i.e. the directory listing command, ls, by default does not show them). Such files are conventionally used for user startup and configuration information that needs to be present, but which one doesn't want cluttering directory listings. This change would prevent overwriting of such as .login, .cshrc, and most importantly, .rhosts, which is the file authorizing password-less login from remote hosts and users. Also, since the directory lister normally hides such files, a user whose TeX job has just overwritten one of them is unlikely to notice the change. Although one might conceivably argue that there might be some use for using hidden files for TeX output, such as a history of job runs in a journal production environment, or some such thing, I think the drawbacks of damage to critical files far outweigh the advantages, and in the interests of security, the capability should be removed from TeX. Now some non-TeX background... The recent flurry of attacks on Microsoft Word 6.0, which by default executes an embedded macro header when it opens a document for screen display, suggests that similar attacks on TeX are likely to occur in the future, although they are necessarily more limited because of TeX's restricted system operations capabilities. The Word 6.0 macro language is claimed to be comparable in power to Visual Basic, and to have full access to all operating system and window system facilities. A number of virus have already been identified, ranging from the benign `This proves we can do it', to ones that delete the entire file system, or infect all other Word 6 documents in the file system. Since Microsoft Word is available on both IBM PC and Apple Macintosh platforms, and has been the number 2 product in the word processing market (and likely, soon to be number 1 if Corel doesn't succeed in resurrecting WordPerfect after buying it from Novell last month), the potential impact of such viruses is large, particularly now that World-Wide Web browsers can be configured to download and open files for display using any program whatever for the display job. ======================================================================== Nelson H. F. Beebe Tel: +1 801 581 5254 Center for Scientific Computing FAX: +1 801 581 4148 Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu University of Utah URL: http://www.math.utah.edu/~beebe Salt Lake City, UT 84112, USA ======================================================================== 29-Feb-1996 14:00:24-GMT,1297;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.4/8.7.3) with ESMTP id HAA07592 for ; Thu, 29 Feb 1996 07:00:21 -0700 (MST) From: dgilbert@snowhite.cis.uoguelph.ca Received: from snowhite.cis.uoguelph.ca by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I1S1KEX16O000BK1@AXP14.AMS.ORG>; Thu, 29 Feb 1996 08:14:13 -0500 (EST) Received: from toby.cis.uoguelph.ca.cis.uog (toby.cis.uoguelph.ca [131.104.48.112]) by snowhite.cis.uoguelph.ca (8.6.9/8.6.9) with SMTP id IAA09557 for ; Thu, 29 Feb 1996 08:13:00 -0500 Received: by toby.cis.uoguelph.ca.cis.uoguelph.ca (5.61/4.7) id AA15678; Thu, 29 Feb 96 08:12:59 -0500 Date: Thu, 29 Feb 1996 08:13:00 -0500 Subject: Changing address To: tex-implementors@MATH.AMS.ORG Message-id: <199602291313.IAA09557@snowhite.cis.uoguelph.ca> Content-transfer-encoding: 7BIT First, I'd like to say that I've been waiting for years to figure out how to change my subscription to this list --- I didn't want to post to the list. However, my current account is probably on the list to be nuked. I would like this changed from dgilbert@snowhite.cis.uoguelph.ca to dgilbert@jaywon.pci.on.ca. I'd also like to support the call for a -request extension for the list. Dave. 2-Mar-1996 23:09:03-GMT,6113;000000000001 Received: from mail.noris.net (root@main.noris.net [193.141.54.1]) by csc-sun.math.utah.edu (8.7.4/8.7.3) with ESMTP id QAA15755 for ; Sat, 2 Mar 1996 16:08:53 -0700 (MST) Received: from hugis.imp.de ([192.109.102.42]) by mail.noris.net with SMTP id <6977-18119>; Sun, 3 Mar 1996 00:10:30 +0100 Received: by hugis.imp.de id AA07209 (5.65c/IDA-1.4.4/IMP+); Sun, 3 Mar 1996 00:02:42 +0100 Date: Sun, 3 Mar 1996 00:02:42 +0100 From: UUCP Administration Message-Id: <199603022302.AA07209@hugis.imp.de> Subject: Undeliverable Mail Apparently-To: beebe@math.utah.edu To: unlisted-recipients:; (no To-header on input) This mail message is undeliverable. (Probably to or from system 'bisun') It was sent to you or by you. Sorry for the inconvenience. Sincerely, hugis!uucp ############################################# ##### Data File: ############################ >From math.utah.edu!beebe Fri Feb 16 00:33:42 1996 remote from hugis Received: from AXP14.AMS.ORG by hugis.imp.de with SMTP id AA07887 (5.65c/IDA-1.4.4/IMP+); Fri, 16 Feb 1996 17:12:35 +0100 Return-Path: Received: from vax02.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I19YLOQ5DC00087M@AXP14.AMS.ORG>; Fri, 16 Feb 1996 09:34:35 -0500 (EST) Received: from csc-sun.math.utah.edu by VAX02.AMS.ORG (PMDF #7286 ) id <01I19YKYC0OG8WVYYR@VAX02.AMS.ORG>; Fri, 16 Feb 1996 09:34:19 EST Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id HAA25966; Fri, 16 Feb 1996 07:33:44 -0700 (MST) Received: (from beebe@localhost) by plot79.math.utah.edu (8.7.1/8.7.1) id HAA10004; Fri, 16 Feb 1996 07:33:42 -0700 (MST) Date: Fri, 16 Feb 1996 07:33:42 -0700 (MST) From: "Nelson H. F. Beebe" Subject: Re: TEXMFOUT To: tex-implementors@MATH.AMS.ORG Cc: beebe@math.utah.edu Message-Id: Content-Transfer-Encoding: 7BIT X-Us-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112, USA" X-Telephone: +1 801 581 5254 X-Fax: +1 801 581 4148 X-Url: http://www.math.utah.edu/~beebe In recent mail to tex-implementors, Charles Karney suggests that a TEXMFOUT variable should be available to provide a way to limit the directories in which TeX and METAFONT can open a file for output. I believe that this is an EXCELLENT idea, and should be implemented with TEXMFOUT set by default to the current directory (in UNIX, "."). This would be a good way to limit attempts to overwrite critical files. While we are at it, I believe that TeX should be made to log the opening of output files too. Consider the following simple test file, foo.tex: \newwrite\x \openout\x=foo.out \write\x{Hello} \closeout\x \bye Now run (UNIX) TeX: % tex foo.tex This is TeX, Version 3.1415 (C version 6.1) (foo.tex [1] ) Output written on foo.dvi (1 page, 196 bytes). Transcript written on foo.log. Notice the COMPLETE ABSENCE of a terminal message about the opened output file. Here is what the log file says: This is TeX, Version 3.1415 (C version 6.1) (format=plain 94.6.21) 16 FEB 1996 07:07 **foo.tex (foo.tex \x=\write0 [1] ) Output written on foo.dvi (1 page, 196 bytes). Evidently, a write has occurred, but no mention is made of the output file name. Nevertheless, it got written: % cat foo.out Hello I suggest that UNIX implementors might want to go even further: namely, to forbid the opening of files whose names begin with a ".", which in UNIX are `hidden' files (i.e. the directory listing command, ls, by default does not show them). Such files are conventionally used for user startup and configuration information that needs to be present, but which one doesn't want cluttering directory listings. This change would prevent overwriting of such as .login, .cshrc, and most importantly, .rhosts, which is the file authorizing password-less login from remote hosts and users. Also, since the directory lister normally hides such files, a user whose TeX job has just overwritten one of them is unlikely to notice the change. Although one might conceivably argue that there might be some use for using hidden files for TeX output, such as a history of job runs in a journal production environment, or some such thing, I think the drawbacks of damage to critical files far outweigh the advantages, and in the interests of security, the capability should be removed from TeX. Now some non-TeX background... The recent flurry of attacks on Microsoft Word 6.0, which by default executes an embedded macro header when it opens a document for screen display, suggests that similar attacks on TeX are likely to occur in the future, although they are necessarily more limited because of TeX's restricted system operations capabilities. The Word 6.0 macro language is claimed to be comparable in power to Visual Basic, and to have full access to all operating system and window system facilities. A number of virus have already been identified, ranging from the benign `This proves we can do it', to ones that delete the entire file system, or infect all other Word 6 documents in the file system. Since Microsoft Word is available on both IBM PC and Apple Macintosh platforms, and has been the number 2 product in the word processing market (and likely, soon to be number 1 if Corel doesn't succeed in resurrecting WordPerfect after buying it from Novell last month), the potential impact of such viruses is large, particularly now that World-Wide Web browsers can be configured to download and open files for display using any program whatever for the display job. ======================================================================== Nelson H. F. Beebe Tel: +1 801 581 5254 Center for Scientific Computing FAX: +1 801 581 4148 Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu University of Utah URL: http://www.math.utah.edu/~beebe Salt Lake City, UT 84112, USA ======================================================================== 13-Mar-1996 21:36:33-GMT,1201;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.4/8.7.3) with ESMTP id OAA01704 for ; Wed, 13 Mar 1996 14:36:25 -0700 (MST) Received: from ALPHA1.RHBNC.AC.UK (134.219.201.113) by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I2AMEUZ87K0014IW@AXP14.AMS.ORG>; Wed, 13 Mar 1996 15:27:43 -0500 (EST) Date: Wed, 13 Mar 1996 20:24:35 +0000 (GMT) From: Philip Taylor (RHBNC) Subject: Errors during Weave for (e_)TeX.Web To: tex-implementors@MATH.AMS.ORG Cc: CHAA006@alpha1.rhbnc.ac.uk Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: P.Taylor@alpha1.rhbnc.ac.uk Message-id: <960313202435.21e56e85@vms.rhbnc.ac.uk> Content-transfer-encoding: 7BIT Dear Implementors -- Whilst preparing for the first public release of e_TeX, I found that I was unable to weave the VMS implementation, Weave reporting "!Sorry, byte memory capacity exceeded. (change file l. 6103)". I would much appreciate any guidance on determining whether this is caused by an error in the changefile or by an under- sized Weave, and if the latter, how I should set about granting it additional byte memory. -------- Philip Taylor, RHBNC. 15-Mar-1996 9:56:10-GMT,2968;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.4/8.7.3) with ESMTP id CAA18450 for ; Fri, 15 Mar 1996 02:55:56 -0700 (MST) Received: from thphy.uni-duesseldorf.de (xerxes.thphy.uni-duesseldorf.de) by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I2CRWA47KG0003FQ@AXP14.AMS.ORG>; Fri, 15 Mar 1996 04:24:10 -0500 (EST) Received: from macbeth.uni-duesseldorf.de (macbeth.thphy.uni-duesseldorf.de) by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA19840; Fri, 15 Mar 96 10:25:34 +0100 Received: by macbeth.uni-duesseldorf.de (5.x/SMI-SVR4) id AA26822; Fri, 15 Mar 1996 10:23:21 +0100 Date: Fri, 15 Mar 1996 10:23:21 +0100 From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth) Subject: Re: Errors during Weave for (e_)TeX.Web In-reply-to: <960313202435.21e56e85@vms.rhbnc.ac.uk> (CHAA006@vms.rhbnc.ac.uk) To: P.Taylor@alpha1.rhbnc.ac.uk Cc: tex-implementors@MATH.AMS.ORG, CHAA006@alpha1.rhbnc.ac.uk Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <9603150923.AA26822@macbeth.uni-duesseldorf.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit [ Phil Taylor reported overflowing WEAVE's capacity for e-TeX.ch ] I vaguley recall having played with e-TeX.ch when it was first announced here last summer and I didn't experience any problems WEAVEing it under Unix. I've looked into web2c's weave.ch now and was a little surprised to find that it didn't need to increase any of the sizes (except for stack_size), which suggests that Knuth's original values in weave.web were presumably chosen to be big enough in the default configuration to handle at least tex.web. However, if e-TeX.web has gained in size since last summer by adding a few thousand lines of code and documentation, it's quite possible that those values were just marginal and that they've been genuinely exceeded now in e-TeX. In that case, fixing the numbers in weave.ch seems inenvitable, but should be easy to do. For example, |max_bytes| is 45000 currently and may go up to 65534, so what's stopping you? On the other hand, I don't really know anything about WEAVE's internal memory management, so I can't rule out that your problem is due to the complexity of individual pages or due to some silly parsing error. I'd suggesst to try it on another platform first. If that also fails, recompiling a bigger WEAVE seems necessary. Cheers, Ulrik. P.S. This is what I get for last July's version of e-TeX.ch: $ wc tex.web e-tex.ch e-tex.web e-tex.tex 24928 124955 1028508 tex.web 3321 12002 110790 e-tex.ch 26799 132276 1095228 e-tex.web (produced with CWEB's wmerge) 40380 168524 1732220 e-tex.tex (after successful WEAVEing) [lines] [words] [chars] Since web2c's weave never keeps usage statistics, I unfortunately can't tell you how much capacity I really needed. Would be a nice feature if one could say weave +s to turn statistics on as in CWEB! 15-Mar-1996 16:02:25-GMT,1021;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.4/8.7.3) with ESMTP id JAA19895 for ; Fri, 15 Mar 1996 09:02:12 -0700 (MST) Received: from ALPHA1.RHBNC.AC.UK by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01I2D2UNYQ5S0007LU@AXP14.AMS.ORG>; Fri, 15 Mar 1996 09:37:31 -0500 (EST) Date: Fri, 15 Mar 1996 14:37:02 +0000 (GMT) From: Philip Taylor (RHBNC) Subject: Re: Errors during Weave for (e_)TeX.Web To: tex-implementors@MATH.AMS.ORG Cc: CHAA006@alpha1.rhbnc.ac.uk Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: P.Taylor@alpha1.rhbnc.ac.uk Message-id: <960315143702.21e48a0d@vms.rhbnc.ac.uk> Content-transfer-encoding: 7BIT My sincere thanks to J"org, Ulrik and Peter for assistance with the Weave/e_TeX problem; Peter Breitenlohner pointed out that the necessity to increase the data structure sizes for Weave is, in fact, already a part of the e_TeX documentation, a fact which I had forgotten or overlooked. ** Phil.