How to get rlwrap to work inside Emacs' shell / eshell? - shell

When I try to get rlwrap to work inside an Emacs (version 24.3.50.1) shell buffer (either M-x shell or M-x eshell), I get this error message:
rlwrap: Oops, crashed (caught SIGFPE) - this should not have happened!
For example:
rlwrap telnet google.com 80
wors fine from a regular terminal (like xterm), but crashes from a shell inside an Emacs buffer.
Several people are having similar issue but the only "answer" I could find so far is a "RTFM" style answer on mailing lists. I did read that part of Emacs' doc and I don't understand what I'm supposed to do to make rlwrap work from within Emacs.

Try using M-xansi-term instead of shell/eshell.
shell and eshell do not provide terminal emulation functionality, but readline requires terminal emulation capabilities to move the cursor etc.

Related

My emacs client automagically terminates when switching applications [OSX iTerm2]

I try to be brave and switch from vi to emacs.
Now, I set up Emacs 26 on macOS via homebrew and start Emacs as daemon in the background.
I can use files using emacsclient -t. However, whenever I bring the Terminal into the background emacsclient exits within a few seconds.
See example Video here: https://cloud.familie-ganter.de/s/QwbK8cFBHnPjQ4d
I did a plain install. My init file does not contain anything except what you see in the video. The funny thing is whenever I start emacs directly in the Terminal, nothing at all happens when bringing it to the background.
What seems to be the problem?
I am lost …
I expect it to be something dumb and simple -- so please be nice, this is my first stackoverflow post.

vi editing crashes within the shell-mode of emacs

Steps to reproduce this:
open emacs
M-x shell RET
vi tmpfile RET
Then you'll see the vi interface is a mess. To quit this, try to blind input :q! or just close the shell buffer.
The reason I use "vi" within emacs is that I use emacs shell-mode heavily and sometimes I ssh to another host within it. On the remote host, i have a reason to use "vi" when i need to edit some file and emacs is absent there.
Your help is appreciated.
I strongly suspect that a proper terminal emulator is necessary for anything like that.
Emacs has one, happily. Try running M-x ansi-term. You can run a shell within that (the default option) and then ssh to the remote host as you were in shell mode.
(If you didn't need to change hosts then you could run vi directly, instead of a shell.)
You might also find Remote ssh connection from within Emacs useful.
You will undoubtedly want to stick to char-mode in the terminal when using vi.
See: C-hig (emacs) Terminal emulator RET

IPython in Emacs py-shell: TAB completion not working & windows get killed

I've switched from ipython 0.10-11.1 to 1.1.0
Now, using Emacs together with the new ipython version I run into the following two problems:
1) Tab completion in Emac's ipython py-shell (C-c !) stopped working for me. Say, if I try to complete 'pl' into 'plot' and so pl<Tab>, the only thing I get in the minibuffer is
Can't find completion for "pl" based on line pl
There are many similar reports about this on the web, however none of the fixes I found solve the issue for me. In particular the additions to ~/.emacs/init.el suggested at http://www.emacswiki.org/emacs/PythonProgrammingInEmacs, in section IPython just don't 'do' anything.
2) When I start the py-shell on a any given buffer foo.py, which is open within one of several Emacs subwindows, then, all other subwindows, except for the one corresponding to foo.py and the newly started (ipython) py-shell get closed.
Both of these issues where absent in ipython 0.10-11.1. Anyone has an idea?
My Emacs version: GNU Emacs 23.2.1. My ipython.el version: defconst ipython-version "0.11" from https://github.com/ipython/ipython/tree/master/docs/emacs
Completion from a (I)Python-shell is just TAB
C-c ! from inside a shell should open another shell, but seems broken indeed, resp. it's not available.
https://bugs.launchpad.net/python-mode/+bug/1234539
Fixed in trunk meanwhile.
BTW to open a second shell from inside, C-u M-x python should work.
Did you set py-python-command-args accordingly?
Assume plot needs option -pylab.
Troubleshooting:
Start with Emacs -Q from the directory where python-mode.el lives.
Open python-mode.el and evaluate it.
Open a --maybe empty-- file with ending ".py".
Python-mode should be switched on.
M-x python RET
a regular Python-shell should appear.
M-x ipython RET
an IPython-shell should open.
Always call (I)Python-shell from a python-mode activated already.
Otherwise shipped python.el or other stuff might come between.
Link shows TAB-completion with IPython-1.1.0 at work:
https://launchpadlibrarian.net/152211804/ex.png
The previous answer does not provide any clue for how to get TAB-completion to work with IPython-1.1.0 and GNU Emacs 23.2.1. In fact the troubleshooting steps, starting from a bare-bones Emacs, do not lead to an IPython-shell with working TAB-completion. Moreover the image at https://launchpadlibrarian.net/152211804/ex.png claiming TAB-completion at work with IPython-1.1.0 depicts an Emacs 24.3.50.1, rather than an Emacs 23.2.1 which I was referring to in my question.
For me the solution was: get rid of IPython-1.1.0 reinstall IPython 0.10-11.1.
(That leaves you without the more recent notebook feature - which is fine if Emacs is at the core of your Python workflow anyway)

Can I get GNU Emacs to TAB complete filenames after using ssh in the *shell* buffer?

I am using GNU Emacs 23.1.50.1 (i486-pc-linux-gnu).
What I want is conceptually simple, [TAB] indicates that I press the
TAB key.
M-x shell
erik#furby:~$ ls
bin Desktop Documents Dropbox R.tools
erik#furby:~$ cd Drop[TAB]
and tab completion works fine (i.e., Dropbox is completed)
However, as soon as I ssh, this no longer works.
ssh erik#remote.edu
Terminal = dumb
erik#remote:~> ls
bin private
erik#remote:~> cd priv[TAB]
and the minibuffer displays
"No completions of priv"
I've found others with the same problems, but
could not discern the solution.
http://www.linuxforums.org/forum/red-hat-fedora-linux/56103-tab-completion-problem-ssh-shell-through-emacs.html
Emacs remote shell
OK, after I posted the question, I stumbled on dirtrack-mode , which appears to have a solution, although not entirely trivial. It uses dirtrack-mode, and the author says:
"It took me a long time to figure out how to get tab-completion working in shell-mode when I was ssh’d into another computer."
It's been annoying me for years; I'm glad I'm not the only one!
This answer to a duplicate worked for me:
C-x C-f /user#host:~ (open a directory on the remote server in dired mode)
M-x shell in the dired buffer
It works with eshell if you instead of doing ssh user#host you do cd /ssh:user#host: however it doesn't seem to work with shell.

Emacs 23 on OS X - pseudo terminal will not be allocated because stdin is not a terminal

I installed Emacs 23 on OS X (the NS/Cocoa variant) and I got the following error when I tried to run ssh from a shell inside emacs.
"pseudo terminal will not be allocated because stdin is not a terminal".
Searching around the web tells me that it is because stdin is somehow a pipe instead of a real tty. I confirmed that by running stty.
Unfortunately, no one really seems to know how to fix it. There were suggestions to try and modify process-connection-type (some said set it to nil while others said t) but unfortunately, neither seems to work.
How do I fix this and get back usage of ssh (and I guess other tools like ftp, latex and anything that needs a tty) inside emacs's shell?
[update: I know of M-x term but that isn't a solution for me. I have confirmed that this works for me on Carbon Emacs 22.3 so this might be something specific about the NS post)
I figured this out. I had some piece of elisp in my .emacs which was setting process-connection-type to nil. Though this was needed for Carbon Emacs, it doesn't seem to be needed for NS Emacs 23. Setting it to t fixes it
are you using M-x shell or M-x term, term is a full blown terminal emulator that will allow you to run any console application you want.
M-x ansi-term
Character to defy 15 char limit.

Resources