Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!hanche From: hanche@imf.unit.no (Harald Hanche-Olsen) Newsgroups: comp.sys.apollo Subject: Re: emacs problem Message-ID: Date: 28 Jan 91 16:43:15 GMT References: <2280@tuvie.UUCP> Sender: news@ugle.unit.no Organization: The Norwegian Institute of Technology, Trondheim, Norway. Lines: 32 In-Reply-To: mike@vlsivie.tuwien.ac.at's message of 28 Jan 91 12:02:13 GMT In article <2280@tuvie.UUCP> mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) writes: Gnu Emacs 18.55 (with Leonard N. Zubkoff's patches for sr 10.2) seems to have a problem with shell subprocesses. At times the 0x0 character (displayed as ^@ by emacs) appears in buffers running a shell. While this is only a nuisance running an inferior shell, it is a problem when running the M-x compile command: The C-x ` (next-error) function is unable to process the compiler output. Has anybody found out what causes this problem and how to fix it? Any hints will be appreciated! This should probably go in some kind of FAQ list (sigh)... Emacs talks to its subsprocesses using pseudo ttys (ptys among friends). On Apollos, ptys occasionally get corrupted, and the problem you describe results. Rebuilding the ptys helps, but it can have funny side effects to any users logged in on those ptys. We rebuild ours once per week. That seems to avoid the problem most of the time, but of course your mileage may vary. Here is the relevant line from our /usr/lib/crontab (running the shell script at 04:00 every Sunday morning): 0 4 * * 7 root /usr/local/lib/fix_ptys and here is /usr/local/lib/fix_ptys: #!/bin/csh -f /bin/rm -f /dev/[pt]ty[pq][0-9a-f] /etc/crpty 32 - Harald Hanche-Olsen Division of Mathematical Sciences The Norwegian Institute of Technology N-7034 Trondheim, NORWAY