History not working in pipenv

[ionecum]

Normally you can hit 'up arrow' to get your previous command and down arrow to go next. This work in any shell, including in many other virtual environment. But it doesn't work in pipenv and this is really sad. I loved pipend when I tried it because it offers everything a virtual environment may offer in a single place and elegantly. The only drawback is that history doesn't work and this is a serious annoyance.

[pfmoore]

What platform is this on? If it's Windows, this is an OS issue, and not directly related to pew. There's nothing much we can do about it, unfortunately (the command line editing and history functionality isn't exposed programmatically, so we're at the mercy of the OS in terms of when it thinks we're running the "same program", and so presents the history).

(@zooba, @eryksun am I right in my assessment above? I'm pretty sure this started happening at the point where Python started using the redirector executable for virtual environments, but my investigations led me to believe that we couldn't do anything about the history issue. But I'd love it if I were told I'm wrong about that!)

BTW, I assume you reported here because pipenv uses pew to start a command line shell? If not, you may have reported this to the wrong project - but the answer will be the same, I'm afraid.

[eryksun]

I'm pretty sure this started happening at the point where Python started using the redirector executable for virtual environments, but my investigations led me to believe that we couldn't do anything about the history issue.

A console session assigns a command history buffer to each process that's attached to it, up to the maximum number of history buffers allowed in the session. When a process attaches to the console session, the host prefers to reuse a history buffer that was previously attached to the same application (e.g. "python.exe"). The command history for the current process is accessible via the up/down arrow keys and function keys (e.g. F7) when using the console's high-level command-line editing (e.g. ReadConsoleW or ReadFile with line-input and echo-input enabled), not when reading low-level input events (i.e. ReadConsoleInputW). An example of the latter is PowerShell (pwsh), which implements its own command-line history via PSReadLine. An example of the former is cmd.exe, as well as python.exe (assuming pyreadline isn't installed).

By default, a session has only 4 history buffers that store 50 commands each. I change the default to 32 history buffers that store 512 commands each. For a system console (hosted by conhost.exe), the default settings are changed via the control menu's "Defaults" dialog. The command history settings are on the "Options" tab. You can also change the command history settings in the current session's "Properties" dialog. The current-session settings are stored either in the registry (based on the initial title of the console session/window) or in the shell link (.LNK) that was used to execute the application that allocated the console session.

A process that's attached to a console session can also call SetConsoleHistoryInfo to change the command history settings. If you're using Windows Terminal, console sessions (i.e. tabs in the terminal) ignore the settings in the registry, and thus each session is limited to just 4 history buffers, unless extended programmatically via SetConsoleHistoryInfo.

---

"pipenv.exe" is an entrypoint executable that runs the base "python.exe". Counting the original CMD shell, that's 3 processes attached to the console. With the shell command I see that it runs "cmd.exe" via cmd.exe /c. That's 5 processes attached to the console. Finally if the environment's "python.exe" is a launcher instead of a symlink, it launches the base "python.exe". That's 7 processes attached to the console. So I'd set the default number of history buffers to at least 8.

[pfmoore]

@eryksun That's awesome, thanks for that (and apologies for the somewhat-random ping, but I was pretty sure if anyone would be able to explain what was going on here, you would 🙂)

Hopefully this helps address your issue @ionecum

[ionecum]

Sorry but other virtual environment work perfectly on Windows and they have a perfectly working history. History in a command line tool is so important that I would perfectly stop to use this tool because of it.

…

On 2/23/21, Paul Moore ***@***.***> wrote: What platform is this on? If it's Windows, this is an OS issue, and not directly related to pew. There's nothing much we can do about it, unfortunately (the command line editing and history functionality isn't exposed programmatically, so we're at the mercy of the OS in terms of when it thinks we're running the "same program", and so presents the history). ***@***.***, @eryksun am I right in my assessment above? I'm pretty sure this started happening at the point where Python started using the redirector executable for virtual environments, but my investigations led me to believe that we couldn't do anything about the history issue. But I'd love it if I were told I'm wrong about that!) BTW, I assume you reported here because pipenv uses pew to start a command line shell? If not, you may have reported this to the wrong project - but the answer will be the same, I'm afraid. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #224 (comment)