🚀 go-pugleaf

In article <ORLOFF.92Oct29192755@surya4.cern.ch>, orloff@surya4.cern.ch
(Jean Orloff) writes:
|> 
|> Joachim> XXX is system dependent, ie, on different systems different
|> Joachim> characters might stop the scan of a file name. Therefore you
|> 
|> Are you sure? I know that the scanning stops on spaces even on systems
|> (eg Mac's) allowing white spaces in filenames and even on the ones
|> REQUIRING a white space before the extension (eg IBM VM/CMS which
|> remaps \input abc.tex into abc tex a0)... It surely stops on
|> unexpandable tokens everywhere.

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

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

Chris Thompson
JANET:    cet1@uk.ac.cam.phx
Internet: cet1@phx.cam.ac.uk