You guys might already solved it by yourselves but if not,
this might help...
"Neal D. Becker" <nbecker(a)hns.com> writes:
Starting up term mode I get:
(1) (error/warning) Error in process filter: (error /home/nbecke/ is not a
No kidding! My home is /home/nbecker!
This is 21.4.11 with all current packages.
Joel Stanley <jstanley(a)cs.uiuc.edu> writes:
I recently built 21.5.13 in order to attempt to solve problems I was
having with tramp-mode hanging in 21.4.x. The good news is that, for
some reason, tramp-mode doesn't hang in 21.5.13 (see
it does in 21.4.x.
The bad news is that, M-x term RET /bin/bash RET gives me a terminal
that seems pretty broken. In particular, newlines don't seem to be being
read from the inferior process correctly, or something along those lines
("ls" from the bash prompt yields a series of incorrectly broken lines,
similar to what you'd see if your stty settings were wrong).
I think both of you use Mule build. If so, try "C-x RET c
binary M-x term". It is the problem of EOL auto detection.
By default, eterm does not meddle with coding-system stuff
which means it uses auto detection for output from a shell.
When auto detector sees CRLF sequence, it decides that it is
part of DOS line endings. As a result, CR is eaten by
coding-system conversion so it never reaches eterm. Eterm
should add something like
(let ((coding-system-for-read (or coding-system-for-read 'undecided-unix)))
so that CR will reach terminal emulator correctly.
If someone cares enough about eterm, writing a patch like
above would be nice.