[353] in SIPB bug reports
Re: LaTeX file name problems
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Wed Mar 8 01:16:27 1989
Date: Tue, 7 Mar 89 21:28:00 EST
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: <amgreene@ATHENA.MIT.EDU>
Cc: bjaspan@ATHENA.MIT.EDU, bug-sipb@ATHENA.MIT.EDU
In-Reply-To: Andrew Marc Greene's message of Tue, 7 Mar 89 19:24:18 EST,
Here I don the turban of a UNIX Guru:
Barry reported two alleged bugs; first, that TeX does not allow you to
process a file with no extension, and second, that its rules for
forming derived files based on the name of a source file permit some
duplication and/or overwriting.
In response to your response to his first point, Andrew, I disagree.
It's a BUG in the UNIX implementation of TeX, which is irritating to
proponents of "Real Unix"[0] (and, alas, comforting to displaced
TOPS-20 weenies).
UNIX is neither TOPS-20, VMS, nor MS-DOS; files without '.'s in their
names are perfectly legal, and the '.' in file suffixes is considered
part of the suffix, rather than as a separator. In general, it is not
considered "polite" to assume that the user meant a different file
than the one he named on the command line[1]. I can't count the
number of times I've tried to substitute /dev/null for a missing .tex
file, and been stopped because TeX claimed that /dev/null.tex doesn't
exist[2].
Having had to deal with questions of the form "Why do have to I call
[the file containing] my program one thing when I use the editor and
another thing when I use the compiler"?, I assert that language
processors which add extensions implicitly are doing the user a
disfavor.
Certain UNIX utilities (most notably /bin/cc) assign different
semantics to filenames with different suffixes; however, they
_require_ that the extensions be mentioned on the command line.
In response to Barr3y's second point, I feel that TeX should set
\jobname to be equal to (in shell syntax) `basename $filename .tex`.
- Bill
[0] BONUS QUESTION: $.02 to the first person to tell me what "JLRU" stands
for.
[1] Justifying this behavior because Scribe behaves in the same
arguably broken way demonstrates a lack of knowledge of its history;
neither Scribe nor TeX were originally developed under UNIX, and, to
top it all off, at least one version of Scribe wouldn't accept
filenames containing '/' because it interpreted the '/' as the start
of an option (in TOPS-20/VMS tradition).
[2] Because of the way in which devices work on certain DEC operating
systems, NUL:.TEX is the same thing as NUL: .
