🚀 go-pugleaf

>>>>> On 30 Oct 92 01:46:52 GMT, cet1@cus.cam.ac.uk (C.E. Thompson)
C.E.> said: Nntp-Posting-Host: bootes.cus.cam.ac.uk

C.E.> Yes, he is sure (I imagine: anyway, he is right). Scanning stops
C.E.> on a non-expandable non-character token (remember that file
C.E.> names are read with expansion, by the way) or on any of an
C.E.> implementation-defined set of character tokens. The base source
C.E.> includes just space in the set, and most implementations don't
C.E.> alter that. Maybe in actual fact, *no* implementations change
C.E.> it: does anyone know of an instance? But they are definitely
C.E.> allowed to.

C.E.> There is a partial de facto standard mostly imposed by the
C.E.> desire to implement LaTeX without having to hack it to pieces. I
C.E.> imagine that this is one reason why the CMS implementation uses
C.E.> dots as separators rather than the more `natural' spaces. And,
C.E.> of course, a really natural Unix implementation would require
C.E.> null-terminated filenames :-)

The only thing LaTeX imposes is to forbid a filename like {abc}. This
not really restrictive. If things are as you say, then is impossible
to know a posteriory (in a system independent way) from which physical file you
just \input'd or \read something.... THIS is a big restriction.

I once dreamt of "redirecting" the output by something like
\openout16=filename, in order to be able to capture the message
written on the output file, but this seems to be forbidden... SAD!
 
--
*************************************************************************
*	Jean Orloff		*	e-mail: ORLOFF@dxcern.cern.ch	*
*	TH-Division, CERN	*	phone:	(41-22) 767-3204	*
*	CH-1211 Geneva 23	*	fax:	(41-22) 782-3914	*
*************************************************************************