mlvdv@RENOIR.BERKELEY.EDU (Michael Van De Vanter) (02/16/89)
General nature:
This problem appears to involve some interaction among GNU Emacs,
make, and csh on Suns, while propagating csh environments.
Environment:
GNU Emacs version 18.51.3. We have reproduced the bug on several Suns
(SunOS 3.4), under both SunView and X11R3. Note that we CANNOT
reproduce it on our VAX (same Emacs version). On our Suns, the
presence GNU Emacs in the chain of propagation is the only controlling
factor we've been able to isolate.
The bug occurs with no .emacs and .emacs_csh files present.
The behavior:
Create the following makefile, making sure you get the leading tabs on
lines 2 and 3.
-----test.Makefile-------------------------------------------------------
test :
@echo In Makefile FOO=${FOO} and FOOB=${FOOB}
@echo In csh FOO=$${FOO} and FOOB=$${FOOB}
----------------------------------------------------------------------
In an ordinary shell (e.g. SunView cmdtool or shelltool, under SUNos
3.4), the test runs as follows:
1>setenv FOO value1
2>setenv FOOB value2
3>make -f test.Makefile
In Makefile FOO=value1 and FOOB=value2
In csh FOO=value1 and FOOB=value2
4>
Then start emacs in the same shell, start a shell inside emacs, and
immediately execute the same makefile. The result, inside the emacs
shell, is:
manzanita.Berkeley.EDU% make -f test.Makefile
In Makefile FOO=value1 and FOOB=value2
In csh FOO=value1 and FOOB=
manzanita.Berkeley.EDU%
The value of the environment variable with the longer name has gotten
lost along the way.
Observation: in our trials, it seems to happen only when one variable
name is a prefix of the other, and the value of the longer is always
the one that gets lost.
M. L. Van De Vanter
Computer Science Division
571 Evans Hall
University of California, Berkeley
Berkeley, CA 94720
(415) 642-4611
mlvdv@Renoir.Berkeley.Edued@ARIZONA.EDU ("Ed Rodriguez") (06/28/89)
We are running emacs 18.53.1 and have a problem with broadcast messages. Whenever someone issues the shutdown command, the broadcast messages hangs emacs. The process then must be killed and started over again. We are running Sun 4.0 OS on a 3/160. Any pointers would be appreciated. thanks...Ed
r@la.tis.com (Richard Schroeppel) (09/03/89)
This message reports a bug in GNU Emacs. Occasionally, when I click the mouse, Emacs reports an error instead of moving the cursor. There seems to be no harm done to the buffers, and the mouse works normally afterwards. Details: I am running on a Sun 360 workstation, under Suntools. (As a separate process, not within a Suntools csh window.) I am using Emacstool version 18.54.2. (Which starts as an Emacs, and convert to Emacstool on the first mouseclick. I click the mouse immediately at startup before doing any editing.) There is no shortage of physical or virtual memory, and there is enough disk space to write out all the files and backups, but not enough to write an Emacs core dump. I am running another copy of Emacs on a DEC VT220 terminal connected to the cua0 terminal port. It has a low priority background subjob that is eating all the free machine cycles. My Emacs window uses as much of the screen as possible; there is a strip of the Suntools background a few pixels wide at the right edge of the screen. (I haven't figured out how to get rid of it.) The window is 142 characters wide (including the backslash at the right end of split lines.) The screen is 52 lines high (of data, not including the banner at the top of the window or the mode line or minibuffer). My window layout is ----------------------- | | | xxx | | | ----------------------- | | | | yyy | | | | | |------------| xxx' | | | | | zzz | | | | | ----------------------- The layout is created by: Begin from full screen. Use ^X2 to vertically split the screen, and then again to split the top half. Use ^X0 to kill the top quarter, leaving a 1/3:2/3 split between the top & bottom subwindows. Move to the bottom subwindow (either with a click or with ^XO.) Use ^X5 to split the bottom window, and m10^X} to widen the left portion to 80 characters. Then use ^X2 to split the left portion. Then select the appropriate buffers to display in each window. I load an Emacs startup file that sets the variable truncate-partial-width-windows to nil. It also loads the code to show the time, disk-use, & load-average in the mode line. xxx and xxx' are in Fundamental mode, and yyy and zzz are in Lisp mode. xxx and xxx' are looking at the different portions of the same file, with no overlap in the text areas displayed. The cursor was in subwindow yyy. I had just saved this buffer with ^X^S. I moved the arrow to subwindow zzz, about 70% over and 40% down (measured within the window). The arrow was a few characters past the end of a line. I clicked the left mouse button, expecting the cursor to move to the end of the line at which the arrow was positioned. Instead, the cursor remained where it was in window yyy, and an error message appeared in the minibuffer window: Wrong type argument: natnump, #<EMACS BUG: ILLEGAL DATATYPE (#o113). Save your buffers ... etc.> I normally continue editing when this happens, since the Emacs appears undamaged. (I save my buffers every few minutes anyway.) Buffers xxx, xxx', and yyy contain lines of 300-400 characters as well as many short lines. Each of these windows was showing at least one long (wrapped) line, as well as some short lines. Window zzz wasn't showing any long lines; the file contained few or none. I load an Emacs startup file that sets the variable truncate-partial-width-windows to nil.