1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
Date: 14 Jan 1994 12:44:13 -0500 (EST)
From: Michael Downes <MJD@MATH.AMS.ORG>
Subject: Around the Bend #17
To: info-tex@shsu.edu
X-ListName: TeX-Related Network Discussion List <INFO-TeX@SHSU.edu>
************************************************************************
*** Exercise 17:
When TeX cannot find an input file it prompts with "Please enter another
input file name:". On some systems you can enter "nul" in response to
this prompt to have TeX input a null file and continue processing. On
most systems TeX also allows you to enter a system-dependent end-of-file
character (Control-Z (DOS, VMS), Control-D (Unix), ...?), to which it
responds with an "Emergency stop" instead of continued processing.
An alternative would be to maintain a file called ".tex" containing an
error message so that merely pressing RETURN would cause TeX to read
".tex" and issue the error message. Unlike the null file case or
EOF-character case, this would allow normal access to the full menu of
error recovery options, including e.g., exiting to an editor, inserting
or deleting tokens, or changing the interaction mode. It would probably
be nice to have the file also accessible under various aliases "h.tex",
"help.tex", "?.tex", "q.tex", "quit.tex", "x.tex", "exit.tex", or
"@#&@%$.tex" corresponding to typical responses from stumped users.
But making a robust ".tex" file for input error recovery is not so
simple a task as might first seem. One needs to take into account, for
example, the possibility that an \input might be attempted when normal
catcodes or normal \endlinechar are not in effect.
Given the programmability of TeX, an all-encompassing solution is
probably not possible, so this exercise has two parts: consider what
would be a reasonable minimal set of assumptions for an input error
recovery file; and write a .tex file containing a suitable error message
and satisfying the assumptions.
************************************************************************
Motivation: From comp.text.tex:
> From: wayne@csri.toronto.edu (Wayne Hayes)
> Subject: Why does TeX ignore interupts???
> Message-ID: <1993Dec24.000935.2007@jarvis.csri.toronto.edu>
> Date: 24 Dec 93 05:09:35 GMT
>
> If there's ONE thing that annoys me more than anything about a program,
> it's when it refuses to die on command, and for no good reason. The
> absolute worst case is when it's waiting for input and you don't know
> what to tell it, and would like to quit for now.
>
> Thus my extreme annoyance every time I mistype an \input command to TeX
> and it asks me on the terminal "Please input another file name: ", and
> I usually just want to exit and re-edit my file to fix the \input
> error. But TeX refuses to die when I press ^C at this moment, and will
> only die if I send a QUIT (^\), at which point it dumps a
> multi-megabyte core file into the current directory. ARGGGHHHH!! Why
> does it do this? I can't see any good reason why it ignores interupts
> at this point. Is this intended? Is it a bug? Does it drive anyone
> else as nuts as it drives me?? Can it be changed in the next release???
It's puzzling that most of the implementations of TeX I know of don't
check for the interrupt key possibility at this prompt [Textures notably
cuts clean through the problem by popping up a dialog box if an input
file is not found]. Seems as if interrupt-key checking at that point
would be a desirable addition to the set of system-dependent changes for
each system.
A summary will be posted circa February 17, 1994.
Michael Downes %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
mjd@math.ams.org (Internet) ASCII 32--54,55--126: !"#$%&'()*+,-./0123456
789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
|
