Repository navigation
IPython terminal prompt missing after upgrading from 2.3.1 to 5.1.0 #10071
Description
I just recently upgraded IPython from 2.3.1 to 5.1.0. Right off the bat, the terminal command prompt is missing although I can type stuff in but it won't echo back either. Execution of the code seems to be working but I can't know for sure. By the way, if I execute ipython --simple-prompt it seems to be working as usual with terminal prompts.
I am aware of the doc here but still have no clue why simply typing ipython won't show me the prompt.
See diagnostics info below.
root@api-2712513810-9iimk:/api# ipython --debug
[TerminalIPythonApp] IPYTHONDIR set to: /root/.ipython
[TerminalIPythonApp] Using existing profile dir: '/root/.ipython/profile_default'
[TerminalIPythonApp] Searching path ['/api', '/root/.ipython/profile_default', '/usr/local/etc/ipython', '/etc/ipython'] for config files
[TerminalIPythonApp] Attempting to load config file: ipython_config.py
[TerminalIPythonApp] Looking for ipython_config in /etc/ipython
[TerminalIPythonApp] Looking for ipython_config in /usr/local/etc/ipython
[TerminalIPythonApp] Looking for ipython_config in /root/.ipython/profile_default
[TerminalIPythonApp] Looking for ipython_config in /api
Python 3.5.2 (default, Nov 17 2016, 22:42:56)
Type "copyright", "credits" or "license" for more information.
IPython 5.1.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
[TerminalIPythonApp] Loading IPython extensions...
[TerminalIPythonApp] Loading IPython extension: storemagic
[TerminalIPythonApp] Starting IPython's mainloop...
root@api-2712513810-9iimk:/api#
root@api-2712513810-9iimk:/api#
root@api-2712513810-9iimk:/api# ipython --simple-prompt
Python 3.5.2 (default, Nov 17 2016, 22:42:56)
Type "copyright", "credits" or "license" for more information.
IPython 5.1.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]: exit
root@api-2712513810-9iimk:/api# python -c "import IPython; print(IPython.sys_info())"
{'commit_hash': '5c9c918',
'commit_source': 'installation',
'default_encoding': 'UTF-8',
'ipython_path': '/usr/local/lib/python3.5/site-packages/IPython',
'ipython_version': '5.1.0',
'os_name': 'posix',
'platform': 'Linux-4.4.14-boot2docker-x86_64-with-debian-8.6',
'sys_executable': '/usr/local/bin/python',
'sys_platform': 'linux',
'sys_version': '3.5.2 (default, Nov 17 2016, 22:42:56) \n[GCC 4.9.2]'}
Activity
takluyver commented on Nov 30, 2016
That's weird. What terminal emulator are you using? Do you have any custom configuration that might affect it? You can temporarily use the default configuration by running IPYTHONDIR=/tmp ipython.
ye commented on Nov 30, 2016
@takluyver weird indeed! I am using a python dockerized python environment based off the official python:3.5 docker images with a bunch of pip packages baked in. There is no custom configration for IPython as far as I know. And I have no idea what terminal emulator I use in the docker container (if you tell me how to check I can post back the results.) Thanks.
Btw, it's even weirder that after I docker container gets deleted and recreated, it simply works again ?!
takluyver commented on Dec 1, 2016
The terminal emulator will be outside the docker container (at least the way you usually run docker). It's the program like xterm, gnome-terminal or iterm, which draws the terminal in a window on your desktop. But as you've got it working, it seems that wasn't the issue. It was a shot in the dark in any case.
Very strange. Does it then stay working, or does it break again at some point?
ye commented on Dec 1, 2016
I am on a Mac with OS X El Capitan and is using the default Terminal app and the Docker for Mac client, FWIW.
It was working once then it broken yesterday and now it's back working again so yeah I think it's random. So far it's still working since yesterday.
This other strange thing that may or maynot be related is that I am randomly seeing copying a string in the terminal and pasting it back onto it got extra prefix and postfix of stuff like ~00 and ~01.
takluyver commented on Dec 1, 2016
OK, nothing sounds unusual there. There are certainly plenty of other people using it in the default Mac terminal.
That sounds a bit like the special characters which readline uses to mark invisible parts of the input prompt, to help it calculate prompt width. Can you show an example?
ye commented on Dec 1, 2016
Will do when I encounter it again! And thanks!
ye commented on Dec 5, 2016
Missing prompt came back earlier today on my Python pod. I haven't seen the special characters prefix/postfixes yet. See gist for details
takluyver commented on Dec 8, 2016
I'm mystified by this one, and I don't know where to start for debugging. @jonathanslenders , any idea why prompts would just fail to appear at all? @ye is on a Mac with the default terminal app.
jonathanslenders commented on Dec 8, 2016
This in weird. Does Kubernetes allocate a pty? For docker you can tell whether or not to allocate a tty?
I don't really understand the issue with the escape sequences.
takluyver commented on Dec 8, 2016
@ye are you using the -t flag when you docker run? That controls whether it allocates a pty. I see you were in the example above where it worked, but I can't see if you are when it's not working.
If it's not running in a tty, though, we should fall back to the simple prompt mode automatically.
ye commented on Dec 8, 2016
Yes, when I run it, I always do kubectl exec -i -t $POD_NAME ipython. Without the -t flag, I can't even get a shell prompt. And shell prompt exists all the time even when IPython prompt was missing.
davidszotten commented on Jan 26, 2017
possibly some more clues:
having a similar using empire (also uses docker)
(note Out but no In)
if i call reset, either from bash before launching, or from inside ipython via !reset it starts working
takluyver commented on Jan 26, 2017
Aha, the bit about reset suggests that something else has done something with terminal state that affects us. Can you use stty before and after calling reset in bash, and see what has changed? If there's nothing different, try with stty -a for more info.
davidszotten commented on Jan 26, 2017
davidszotten commented on Jan 26, 2017
in case it's helpful:
davidszotten commented on Jan 26, 2017
it seems setting rows/columns (need both) fixes the issue
$ stty columns 156; stty rows 70
takluyver commented on Jan 26, 2017
I see the -brkint -imaxbel options in stty in my terminal, and IPython works there :-S
davidszotten commented on Jan 26, 2017
So is the row/column issue a bug in the prompt toolkit (or ipython) or is it acting "correctly" with a badly configured terminal?
takluyver commented on Jan 26, 2017
I'm not sure what the expected behaviour would be if the terminal reports that it's 0 by 0, but it's certainly plausible that it wouldn't show up anything. @jonathanslenders , does that sound right?
I guess that the best fix is to check for terminal dimensions 0, assume that's incorrect and use the fallback dimensions instead. I think it needs to be in prompt_toolkit, though - I don't think we're passing terminal size in to PT.
jonathanslenders commented on Jan 26, 2017
If the terminal reports 0x0 as a size, then indeed it won't draw anything.
If that's the case, I agree that we can fallback to the default size (80x24).
It's this function: https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/prompt_toolkit/terminal/vt100_output.py#L344
@davidszotten: Are you able to test this and create a pull request?
davidszotten commented on Jan 26, 2017
thanks for the help. will try to give this a go and raise a pr. unfortunately i'm about to go away for 10 days, so will have to put this on hold until i'm back.
as for the default, is that a constant somewhere (couldn't find one) or will i just hard code those values in the function?
thanks again!
jonathanslenders commented on Jan 26, 2017
You can hard-code 80x24. This seems to be the default for a Linux terminal. Making this configurable for such an edge case doesn't seem worth the effort, I think. If 80x24 appears to be too big as a default, we can consider something smaller.
jonathanslenders commented on Mar 4, 2017
FYI: this was fixed in prompt-toolkit/python-prompt-toolkit@e73b921
I still need to push a new release of prompt_toolkit.
ye commented on Mar 8, 2017
Thanks @jonathanslenders ! can you provide an ETA on the release of the fix? Much appreciate it!
jonathanslenders commented on Mar 9, 2017
Hi @ye, I'll try to release in the coming week. There are still a few things I'd like to merge.
MrMino commented on Mar 27, 2022
Looks like this has been fixed with the release of prompt-toolkit 1.0.14.