M-x shell does not work on Windows when default-directory too long

M-x shell does not work on Windows when default-directory too long

[Michael Schierl]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

[cc to bug-gnu-emacs since the bug occurs as well:
In GNU Emacs 21.3.1 (i386-msvc-windows98.3000)
 of 2003-03-28 on buffy]

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Start Emacs with -q.

Open an existing file with a long path (e.g. "c:/temp/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/foo.txt"). 

Press M-x shell RET

A shell window will appear but there is nothing in it - no prompt no
nothing. Entered Commands will not have any effects.

--Or:--

Evaluate the following code and run M-x shb.

(defvar shb-procname shell-file-name)

;; the environment will not change anything; i just put it there to
;; show that it is *not* an environment memory overflow
(defvar shb-proc-env '("TMP=C:\\TEMP" 
		       "TEMP=C:\\TEMP" 
		       "PROMPT=$p$g" 
		       "COMSPEC=C:\\WINDOWS\\COMMAND.COM"))

(defvar shellbug-not-so-long-name (concat "c:/temp/deepdir/deepdir"
					  "/deepdir/deepdir/deepdir"
					  "/deepdir/deepdir/deepdir"))

(defvar shellbug-long-name (concat shellbug-not-so-long-name 
				   "/deepdir/"))

(make-directory shellbug-long-name t)

(defun shellbug (procname bufname)
  (kill-buffer (get-buffer-create bufname))
  (switch-to-buffer (get-buffer-create bufname))
  (let ((process-environment shb-proc-env))
    (make-comint-in-buffer procname (get-buffer-create bufname)
			   shb-procname nil "-i")))

(defun shb () (interactive)
  (let ((default-directory shellbug-long-name))
    (shellbug "shellbug1" "*shell-doesnt-work*"))
  (let ((default-directory shellbug-not-so-long-name))
    (shellbug "shellbug2" "*shell-works*"))
  (pop-to-buffer "*shell-doesnt-work*"))

Then you will see two windows of which one shows a shell and the
other does not. So the reason for the bug is really the too long
default-directory.

This bug appears both on my unstable emacs and on my stable one - and
it can be quite annoying until you found the reason why M-x shell
suddenly stops working...

Michael

In GNU Emacs 21.3.50.1 (i386-mingw-windows98.3000)
 of 2004-05-19 on BERATUNG4
configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-1/include -I../../libpng-1.2.4-1/include -I../../tiff-3.5.7/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.1.4-1/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: deu
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tool-bar-mode: t
  encoded-kbd-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  unify-8859-on-encoding-mode: t
  line-number-mode: t

Recent input:
<down-mouse-1> <mouse-1> M-x r e p o r <tab> 
<return>

Recent messages:
Loading mwheel...done
(C:\PROGRAMME\EMACS-21.3.50.2\BIN\EMACS.EXE -q)
Loading encoded-kb...done
Loading tool-bar...done
Loading image...done
Loading tooltip...done
Making completion list...
Loading help-mode...done
Loading emacsbug...done

Re: M-x shell does not work on Windows when default-directory too long

[Jason Rumney]

Michael Schierl <schierlm-usenet@gmx.de> writes:

> Start Emacs with -q.
>
> Open an existing file with a long path (e.g. "c:/temp/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/foo.txt"). 
>
> Press M-x shell RET
>
> A shell window will appear but there is nothing in it - no prompt no
> nothing. Entered Commands will not have any effects.

> 		       "COMSPEC=C:\\WINDOWS\\COMMAND.COM"))

Thank you for your report. Unfortunately COMMAND.COM is not Free
Software, so the Emacs developers cannot do anything about its
limitations. I tried to reproduce this with CMD.EXE (the native shell
of NT and its derivatives), and it does not happen, so it would appear
that COMMAND.COM is the source of the problem.