You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a result of me diagnosing why poetry shell starts a new shell, but without the virtual env activated.
Looking at how poetry uses the shell, it uses pexpect to run it, writing the command to activate the python environment as its first input. This breaks in all configurations that read anything before that; particularly, any configuration that uses VT100 escape sequences that read anything. These may be more or less common in, for example, prompts.
new_line_ps1() {
local _ y x _
local LIGHT_YELLOW="\001\033[1;93m\002"local RESET="\001\e[0m\002"
IFS='[;'read -p $'\e[6n' -d R -rs _ y x _
if [[ "$x"!= 1 ]];thenprintf"\n${LIGHT_YELLOW}^^ no newline at end of output ^^\n${RESET}"fi
}
if [ "$color_prompt"= yes ];then
PS1='$(new_line_ps1)${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ 'else
PS1='$(new_line_ps1)${debian_chroot:+($debian_chroot)}\u@\h:\w\$ 'fiunset color_prompt force_color_prompt
My analysis of what happens:
What this prompt does is it outputs the "\e[6n" VT100 escape code to read cursor position. VT100 compliant terminals respond to this by producing the a string like "\e[10;1R" as if input from a keyboard. This can then be read by the program to determine that the cursor is on line 10, column 1.
The way poetry shell is implemented, it typically claims to be VT100 compliant if run from such a terminal (because it does not change the TERM environment variable), yet it does not respond to VT100 queries the shell outputs before giving it the activation command. In this case, that results in the read command in the prompt reading (part of) the activation command.
The text was updated successfully, but these errors were encountered:
poetry shell behaviour is pretty much all inherited from pexpect, you could try raising an issue over there - presumably you could reproduce this behaviour with pexpect and not using poetry at all.
Possibly pexpect isn't really meant to be used this way.
IMO poetry shell is a mis-step, more trouble than it's worth. If there's anything at all you don't like about poetry shell - you're better off ignoring it completely and just manually activating the virtual environment as you would have done if poetry shell had never existed.
-vvv
option) and have included the output below.Issue
Related: #18 python-poetry/poetry#571
This is a result of me diagnosing why
poetry shell
starts a new shell, but without the virtual env activated.Looking at how poetry uses the shell, it uses pexpect to run it, writing the command to activate the python environment as its first input. This breaks in all configurations that read anything before that; particularly, any configuration that uses VT100 escape sequences that read anything. These may be more or less common in, for example, prompts.
For example, I have this in my .bashrc, essentially from this StackOverflow comment:
My analysis of what happens:
What this prompt does is it outputs the "\e[6n" VT100 escape code to read cursor position. VT100 compliant terminals respond to this by producing the a string like "\e[10;1R" as if input from a keyboard. This can then be read by the program to determine that the cursor is on line 10, column 1.
The way
poetry shell
is implemented, it typically claims to be VT100 compliant if run from such a terminal (because it does not change the TERM environment variable), yet it does not respond to VT100 queries the shell outputs before giving it the activation command. In this case, that results in the read command in the prompt reading (part of) the activation command.The text was updated successfully, but these errors were encountered: