Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f1FCc4H13964 for ; Thu, 15 Feb 2001 13:38:04 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1FCc3d10422 . for ; Thu, 15 Feb 2001 13:38:04 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1FCc3712877 for ; Thu, 15 Feb 2001 13:38:03 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0974C.23C81E00" Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id NAA28984 for ; Thu, 15 Feb 2001 13:38:01 +0100 (MET) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1FCbxM28311 for ; Thu, 15 Feb 2001 13:37:59 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <3.F501D8C1@mail.listserv.gmd.de>; Thu, 15 Feb 2001 13:37:51 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488780 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 15 Feb 2001 13:37:54 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id NAA12234 for ; Thu, 15 Feb 2001 13:37:53 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id NAA19736 for ; Thu, 15 Feb 2001 13:37:53 +0100 Received: from musse.tninet.se (musse.tninet.se [195.100.94.12]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with SMTP id f1FCbsx09280 for ; Thu, 15 Feb 2001 13:37:55 +0100 (MET) Received: (qmail 23999 invoked from network); 15 Feb 2001 13:37:52 +0100 Received: from delenn.tninet.se (HELO algonet.se) (195.100.94.104) by musse.tninet.se with SMTP; 15 Feb 2001 13:37:52 +0100 Received: from [195.100.226.137] (du137-226.ppp.su-anst.tninet.se [195.100.226.137]) by delenn.tninet.se (BLUETAIL Mail Robustifier 2.2.1) with ESMTP id 837383.240670.982delenn-s0 for ; Thu, 15 Feb 2001 13:37:50 +0100 In-Reply-To: References: Return-Path: X-Sender: haberg@pop.matematik.su.se Content-class: urn:content-classes:message Subject: Re: Side remarks about TeX input sequence Date: Thu, 15 Feb 2001 13:37:18 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Hans Aberg" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3936 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0974C.23C81E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 11:19 +0100 2001/02/15, Rainer Schoepf wrote: >> Are these OS's in continued widespread use, or are they dying? -- The = thing >> is that without those OS line separator convetions, one can decide = that a >> line separator should be \l, \r, or a \r\l (as in Java), and that = would be >> platform independent. > >That's totally irrelevant. You are confusing OS level and library = level. >What you see in Java is at the library level and has near to nothing to = do >with the underlying operating system. > >To take OpenVMS, it has various OS level file formats (both stream and >record oriented), many of which can be used for textual data. In every >case you can read characters or lines or whatever if your language = library >offers the functionality. In Java you see \r\l, in C \n. No, you got it wrong: One can open a file as a text file or as binary = file: In C, if you open it as a text file, the local OS convention line separators are translated into \n, but if you open it as a binary, you = see whatever is in the file. The idea of open a file as text file does not work well say on a Mac, if you happen to have a mixture say UNIX, MSOS & MacOS files. So one way around it, is to let your program read either of \n, \r, or \r\n as a single line separator. Under C this can be done either by requiring the files to be opened as binary and add such parsing, or to tweak the C = text file open mode to translate them into the usual \n. However, the first way does not work under OS's that does not use the = UNIX, MSOS or MacOS conventions. So one must then know what exactly they are doing. >And still, it has nothing to do with input encoding or internal >representation. Please explain: To me \n and \r seems different. Or are you claiming = that there is God given law that requires one to open all files in text mode? = :-) Hans Aberg ------_=_NextPart_001_01C0974C.23C81E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Side remarks about TeX input sequence

At 11:19 +0100 2001/02/15, Rainer Schoepf = wrote:
>> Are these OS's in continued widespread use, = or are they dying? -- The thing
>> is that without those OS line separator = convetions, one can decide that a
>> line separator should be \l, \r, or a \r\l = (as in Java), and that would be
>> platform independent.
>
>That's totally irrelevant. You are confusing OS = level and library level.
>What you see in Java is at the library level and = has near to nothing to do
>with the underlying operating system.
>
>To take OpenVMS, it has various OS level file = formats (both stream and
>record oriented), many of which can be used for = textual data. In every
>case you can read characters or lines or whatever = if your language library
>offers the functionality. In Java you see \r\l, = in C \n.

No, you got it wrong: One can open a file as a text = file or as binary file:
In C, if you open it as a text file, the local OS = convention line
separators are translated into \n, but if you open it = as a binary, you see
whatever is in the file.

The idea of open a file as text file does not work = well say on a Mac, if
you happen to have a mixture say UNIX, MSOS & = MacOS files. So one way
around it, is to let your program read either of \n, = \r, or \r\n as a
single line separator. Under C this can be done = either by requiring the
files to be opened as binary and add such parsing, or = to tweak the C text
file open mode to translate them into the usual = \n.

However, the first way does not work under OS's that = does not use the UNIX,
MSOS  or MacOS conventions. So one must then = know what exactly they are
doing.

>And still, it has nothing to do with input = encoding or internal
>representation.

Please explain: To me \n and \r seems different. Or = are you claiming that
there is God given law that requires one to open all = files in text mode? :-)

  Hans Aberg

------_=_NextPart_001_01C0974C.23C81E00--