From: Davin Pearson Newsgroups: comp.os.msdos.djgpp Subject: emacs problems Date: Tue, 07 Oct 1997 02:36:28 +1300 Organization: University of Canterbury Lines: 121 Message-ID: <3438E95C.37AB@EXT.canterbury.ac.nz> Reply-To: d DOT pearson AT EXT DOT canterbury DOT ac DOT nz NNTP-Posting-Host: exti141.tacacs.canterbury.ac.nz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk I have both Eli Zaretskii's Emacs and Geoff Voelker's Emacs running under Windows 95 but for some reason Eli's emacs now refuses to load. (This sort of annoying problem has happened to me before) Instead of loading, displays the following error message for about 3/50 ths of a second, before obliterating it with the command line. Cannot open load file: case-table So it seems that Eli should search the sources of his Emacs and replace occurences of \n with \r\n in the above string and other similar ones. I might be able to be more helpful in future in tracking down bugs (when I am more of an expert), but right now I am at the stage of running all my DJGPP utils out-of-the-box with no messing around with sources. Regarding the original problem of why (DOS) emacs no longer loads, could anyone offer a suggestion for the cause of the problem? With Win95-Emacs, which otherwise works fine, I have also come across some puzzling differences between running my makefile from the shell prompt and from inside Emacs (M-x compile). Could an experienced user explain the reason for the difference in behaviour? (I am using Win95 Emacs) --------------- --------------- Makefile follows: --------------- SHELL = c:/djgpp/bin/bash.exe default: # Next line should say hello-one @echo 'hello-one' # Next line should say hello-two @echo "hello-two" # Next line should display current shell: @echo current shell = $(SHELL) # Next line should wildcard-expand the * @echo * # Next line should display current directory @pwd # Next line should display a different current directory @cd /djgpp; pwd # Next line should echo a listing to a file @pwd; pwd; pwd; echo >c:/hello_there $$( ls ) ----------- The following is the result of running "make" from the ----------- bash prompt. hello-one hello-two current shell = c:/djgpp/bin/bash.exe makefile makefile~ c:/davin/tmake /djgpp c:/davin/tmake c:/davin/tmake c:/davin/tmake --------------------- The following is the result of running "make" --------------------- on the same makefile, with the same current --------------------- directory, from inside Emacs. cd ~/DAVIN/tmake/ make hello-one current shell = c:/djgpp/bin/bash.exe c:/davin/tmake Compilation finished at Thu Sep 25 18:59:10 --------------------- --------------------- The following is the result of running "make" --------------------- on the same makefile, with the command M-! hello-one current shell = c:/djgpp/bin/bash.exe c:/davin/tmake --------------------- The third way is identical to the second. The difference between the first and the second way is a cosmetic one, but still puzzling. A careful examination of the file "c:/hello_there after running both trials shows that this file contains the same contents: namely "makefile makefile~" For some reason, the output from the commands is often suppressed when the makefile is run from within emacs. I have no idea, for example why the kind of quotes in echo "one" versus echo 'two' makes a difference to whether or not the output is returned to emacs. ---------------- Another unrelated problem is that when I type the command: etags *.el on the bash command line, I get a bizarre error like: asm-mo: no such file or directory , but when I type the command: etags '*.el' it churns away and correctly produces the tags file. My understanding of this is that single quotes on the argument protects the argument from wildcard expansion from bash, so that the wildcard expansion is done inside the etags command. My guess as to why: etags *.el doesn't work is that there are so many files in the directory that it overflows the command line and causes etags to get confused. Trying out the command: etags *.el with the COMMAND.COM works fine, which seems to confirm the theory that bash is overflowing the command line. Is bash limited to 126-character command lines like COMMAND.COM? If not, what is its limit? ----- Advice on these issues would be greatfully appreciated. Davin Pearson