From: Davin Pearson <d DOT pearson AT EXT DOT canterbury DOT ac DOT nz>
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