5

I've got this error, when running M-x ansi-term C:/Windows/System32/bash.exe RET

Spawning child process: invalid argument

after running M-x debug-on-entry RET start-process RET when running M-x ansi-term I've got this stack trace:

Debugger entered--entering a function:
* start-process("terminal" #<buffer *terminal*> "/bin/sh" "-c" "stty -nl echo rows 20 columns 97 sane 2>/dev/null;if [ $1 = .. ]; then shift; fi; exec \"$@\"" ".." "C:/Windows/System32/bash.exe")
  apply(start-process "terminal" #<buffer *terminal*> "/bin/sh" "-c" "stty -nl echo rows 20 columns 97 sane 2>/dev/null;if [ $1 = .. ]; then shift; fi; exec \"$@\"" ".." "C:/Windows/System32/bash.exe" nil)
  term-exec-1("terminal" #<buffer *terminal*> "C:/Windows/System32/bash.exe" nil)
  term-exec(#<buffer *terminal*> "terminal" "C:/Windows/System32/bash.exe" nil nil)
  make-term("terminal" "C:/Windows/System32/bash.exe")
  term("C:/Windows/System32/bash.exe")
  funcall-interactively(term "C:/Windows/System32/bash.exe")
  call-interactively(term record nil)
  command-execute(term record)
  execute-extended-command(nil "term" nil)
  funcall-interactively(execute-extended-command nil "term" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

It try to execute /bin/sh on Windows, is this correct? I'm using GNU Emacs 25.3.1 installed from choco.

M-x term was working but after I've try to fix ansi-term it stops, but the issue was that I have ssh-add in my .bashrc and it didn't work. I couldn't enter the pass phrase.

EDIT: after a while I've learned that on Windows only eshell is working , since most shells depend on internals of Linux system. The option may be to install Emacs inside WSL.

jcubic
  • 691
  • 1
  • 4
  • 16
  • 1
    have you found a solution for this problem? Facing the same issue. – Artemios Antonio Balbach Dec 04 '19 at 14:24
  • @ArtemiosAntonioBalbach No, I don't use ansi-term on Windows. Also and I'm using WSL with win10 now. I need to try again to run it with WSL. – jcubic Dec 04 '19 at 20:33
  • The `ansi-term` implementation hard-codes an invocation of `/bin/sh`. Changing the code to use MSYS's `sh.exe` causes the ansi-term to be startable but unresponsive. We might be out of luck here. – kdb Feb 09 '21 at 08:08
  • @kdb I was watching some videos about Emacs and it seems that most Terminal emulators don't work on Windows at all. I think only eshell work on Win. I think that it was this video [Emacs From Scratch #9 - Learn to Love the Terminal Modes](https://www.youtube.com/watch?v=wa_wZIuT9Vw) – jcubic Feb 09 '21 at 16:12
  • @jcubic The question is "why"? Is it just lack of support for Windows on the Emacs side? Is there something that makes a general-purpose ansi-term inherently impossible on Windows? Depending on the answer, `ansi-term` may be fixable. – kdb Feb 09 '21 at 21:12
  • @jcubic Relevant: [Windows (used to) lack a PTY infrastructure](https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/), so the technology underlying ansi-term just isn't there on Windows. And though this changes right now, it might be years before it spreads to end-user software. – kdb Feb 28 '21 at 14:30

0 Answers0