pew-org / pew

A tool to manage multiple virtual environments written in pure python
MIT License
1.17k stars 81 forks source link

up/down arrow history doesn't work on pipenv shell on windows #165

Open dangillet opened 7 years ago

dangillet commented 7 years ago

In the cmd shell, usually you can hit 'up arrow' to get your previous command. Once you run 'pipenv shell', this no longer works. if you run some commands inside the pipenv shell and then hit 'up' it does nothing.

This bug was filed in pipenv issue tracker. According to @erinxocon this is a pew bug.

erinxocon commented 7 years ago

Indeed! Don't know the cause, I do believe the bug is pew!

berdario commented 7 years ago

It's a virtualenv issue, already reported

https://github.com/berdario/pew/issues/90

Sorry :/

crioux commented 7 years ago

This is not the same issue as the virtualenv issue. That's for the python3 interpreter and it has to do with locating the history file for the python interactive shell.

This is for the windows console specifically. Note that things work when using 'conemu' instead of just 'cmd'. See details in #166

crioux commented 7 years ago

The issue is that the windows console does not interpret the 'arrow keys' as ansi codes, like unix terminals, but rather as virtual keystrokes. The virtual keystrokes are captured by the parent process, and not translated into ansi codes or passed through to the child process windows event loop. The only way to do this is with a windows event hook dll, which translates the virtual keystrokes from the parent console and passes them to the child process event loop. This is what conemu is doing, and every similar subshell under Win32 would have to do. I'm not suggesting this is worth anyone's time, since the workaround (using conemu) is possibly acceptable.

That said, I'm not sure you'd even want this fix if i were to write it. It would involve compiling a binary that gets injected into every window on the system, which is what conemu is doing. One might be able to do it in a less invasive fashion, but it would be some pretty deep win32. I'm willing to give it a shot at some point, unless someone here really wants a go at it.

crioux commented 7 years ago

Okay, some color on this: There may be a simpler way to fix this.

There's a problem with the generated 'pew.exe' that gets created by setuptools or whatever. Something that executable is doing to launch python is doing so in a manner that is probably piping the stdin/stdout handles or something. Directly executing the process from pew in python without using the 'pew.exe' does what you'd expect:

python -c "from pew import pew; pew.pew()" in <yourvirtualenv> cmd

If you do the above, arrow keys work in cmd.

berdario commented 7 years ago

Apologies, I was too eager to close the ticket and didn't realize it was actually a different issue

The fact that setuptools would cause the issue could explain why I haven't seen it before while developing. Is this affecting only cmd.exe or powershell as well?

I don't use Windows day to day, so I haven't tested this first hand,yet... And I don't have plans to fix it with an invasive dll as in your first suggestion

dangillet commented 7 years ago

I've tested @crioux work around and it indeed works! :smiley: :tada:

@berdario I've tested in powershell and the problem does not occur there. It's only a problem in cmd.exe it appears.

crioux commented 7 years ago

Yea, I'm looking into setuptools and working this bug through, I'll let you know what I find.

garytyler commented 6 years ago

Any news or other workarounds on this issue? I just want to ask before I spend an evening on some wobbly solution of my own, to allow me to work in the vscode integrated terminal. I'm happy to attempt contributing, but I am far from the best person for a job like this. Thanks!

@crioux 's solution python -c "from pew import pew; pew.pew()" in <yourvirtualenv> cmd does [DEPRECATED] work in a regular cmd shell but not in the vscode integrated terminal.

crioux commented 6 years ago

I haven't had much time to look into it. I got around it by using ConEmu and my desire to fix it some other was has waned :|

eli-b commented 6 years ago

@crioux's workaround doesn't work for me. I just get a list of available commands. I'm using cmd.exe on Windows 10, with pew 1.1.2 installed in my pipenv virtualenv.

astewart-xmos commented 6 years ago

I have the same setup as @eli-b, can confirm I get the same results

askpatrickw commented 6 years ago

It's interesting to note that using the virtualenv-wrapper for windows that workon <env> works as expected from CMD. I suspect its working differently... maybe that method could be adopted by pew or uplevel dependencies aka pipenv could replace pew with that method since they're waiting on a fix from pew. cc: @kennethreitz and @nateprewitt

fredfalcon commented 6 years ago

what is required to fix this?

dangillet commented 6 years ago

I'm not sure. I can just add that using the command python -m pew in <yourvirtualenv> cmd works as well.

So it seems that the problem has something to do with using the pew.exe file.

RZarifov commented 4 years ago

Found this issue since it is related to the problem I'm facin, so decided to post here, despite the fact it is 2 years old.
The issue is that when I use python interactive console on windows 10 in pipenv, I have no history, so no up and down arrows work.
There is mentioned that pipenv won't use pew anymore, but still, if somebody knows how to handle this issue, I would be much obliged if you help me.

And again: the issue is as described in this thread: pipenv, windows 10, interactive python console, it doesn't save history, so up and down arrows doesn't work. Asking anybody who could help to resolve this issue.

pfmoore commented 4 years ago

There's a problem with the generated 'pew.exe' that gets created by setuptools or whatever. Something that executable is doing to launch python is doing so in a manner that is probably piping the stdin/stdout handles or something.

The code used by the wrappers generated by pip comes from distlib (and via that, from simple_launcher - the relevant bit is here). There's some code in there that ensures the child behaves correctly - maybe something more is needed for history?

If I'm correct, then the issue should probably be raised against that project, but it stands a better chance of being fixed if someone can produce a smaller test case (i.e., something that doesn't need all of pew to reproduce).