Powershell fails every prompt in pixi shell after cancelling (ctrl+c)

[Wumpf]

Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

(see description)

Issue description

• open powershell
• navigate to folder with a pixi.toml file
• pixi shell
• sleep(1000) (or any other long running command
• ctrl+c to cancel while it is still running
• press enter, observe how error code remains -1073741510. In my case the oh-my-posh shell plugin also gets.. issues:
  

Expected behavior

continue operating as normal

[ruben-arts]

I can recreate it! Will take a look at this later.

[ruben-arts]

Added the help wanted label as we don't know where this is coming from.

[traversaro]

I am experiencing this also on Command Prompt. Interestingly, it seems that the pixi environment is actually active when the prompt does not have the (envname) modifier, while the (envname) modifier is present, the environment is not active, see :

(pixitest) C:\src\pixitest>set | findstr "PIXI"
PIXI_CACHE_DIR=D:\cache\rattler
PIXI_ENVIRONMENT_NAME=default
PIXI_ENVIRONMENT_PLATFORMS=win-64
PIXI_EXE=C:\Users\straversaro\AppData\Local\pixi\bin\pixi.exe
PIXI_PROJECT_MANIFEST=C:\src\pixitest\pixi.toml
PIXI_PROJECT_NAME=pixitest
PIXI_PROJECT_ROOT=C:\src\pixitest
PIXI_PROJECT_VERSION=0.1.0
PIXI_PROMPT=(pixitest)

(pixitest) C:\src\pixitest>

(pixitest) C:\src\pixitest>
(pixitest) C:\src\pixitest>
(pixitest) C:\src\pixitest>
(pixitest) C:\src\pixitest>^C
C:\src\pixitest>
(pixitest) C:\src\pixitest>
C:\src\pixitest>
(pixitest) C:\src\pixitest>set | findstr "PIXI"
PIXI_CACHE_DIR=D:\cache\rattler

C:\src\pixitest>set | findstr "PIXI"
PIXI_CACHE_DIR=D:\cache\rattler
PIXI_ENVIRONMENT_NAME=default
PIXI_ENVIRONMENT_PLATFORMS=win-64
PIXI_EXE=C:\Users\straversaro\AppData\Local\pixi\bin\pixi.exe
PIXI_PROJECT_MANIFEST=C:\src\pixitest\pixi.toml
PIXI_PROJECT_NAME=pixitest
PIXI_PROJECT_ROOT=C:\src\pixitest
PIXI_PROJECT_VERSION=0.1.0
PIXI_PROMPT=(pixitest)

(pixitest) C:\src\pixitest>set | findstr "PIXI"
PIXI_CACHE_DIR=D:\cache\rattler

C:\src\pixitest>set | findstr "PIXI"
PIXI_CACHE_DIR=D:\cache\rattler
PIXI_ENVIRONMENT_NAME=default
PIXI_ENVIRONMENT_PLATFORMS=win-64
PIXI_EXE=C:\Users\straversaro\AppData\Local\pixi\bin\pixi.exe
PIXI_PROJECT_MANIFEST=C:\src\pixitest\pixi.toml
PIXI_PROJECT_NAME=pixitest
PIXI_PROJECT_ROOT=C:\src\pixitest
PIXI_PROJECT_VERSION=0.1.0
PIXI_PROMPT=(pixitest)

(pixitest) C:\src\pixitest>

In this case, pixi is version 0.18.0, and C:\src\pixitest is an empty pixi environment.

[traversaro]

This is particularly annoying as it appears to happen when you use Ctrl+C to close a running program, like:

pixi shell
runsomeprogram :: You press Ctrl+C to exit
:: now the shell is corrupted

I guess most users on Windows are probably using pixi run , so they are not encountering this. I think I will eventually try to tackle this problem, as it is quite annoying. Anyone has some pointers to relevant part of the codes it may be worth start looking into?

[ruben-arts]

He @traversaro, please enlighten us!

The initialization of the powershell can be found here:

pixi/src/cli/shell.rs

Lines 37 to 70 in 58ab590

	fn start_powershell(
	pwsh: PowerShell,
	env: &HashMap<String, String>,
	prompt: String,
	) -> miette::Result<Option<i32>> {
	// create a tempfile for activation
	let mut temp_file = tempfile::Builder::new()
	.suffix(".ps1")
	.tempfile()
	.into_diagnostic()?;
	let mut shell_script = ShellScript::new(pwsh.clone(), Platform::current());
	for (key, value) in env {
	shell_script.set_env_var(key, value).into_diagnostic()?;
	}
	temp_file
	.write_all(shell_script.contents().into_diagnostic()?.as_bytes())
	.into_diagnostic()?;
	// Write custom prompt to the env file
	temp_file.write(prompt.as_bytes()).into_diagnostic()?;
	// close the file handle, but keep the path (needed for Windows)
	let temp_path = temp_file.into_temp_path();
	let mut command = std::process::Command::new(pwsh.executable());
	command.arg("-NoLogo");
	command.arg("-NoExit");
	command.arg("-File");
	command.arg(&temp_path);
	let mut process = command.spawn().into_diagnostic()?;
	Ok(process.wait().into_diagnostic()?.code())
	}

This is the prompt:

pixi/src/prompt.rs

Lines 37 to 43 in 58ab590

	pub fn get_powershell_prompt(env_name: &str) -> String {
	format!(
	"$old_prompt = $function:prompt\n\
	function prompt {{\"({}) $($old_prompt.Invoke())\"}}",
	env_name
	)
	}

This is all the code around activation: https://github.com/prefix-dev/pixi/blob/main/src/activation.rs

Would be happy to help if you feel like you found the culprit!

[Petzep]

I have the same issue.
When the terminal is corrupted, it behaves as if it is running both the pixi-shell and the powershell on the foreground.
The input from the keyboard is sent to the pixi-shell and powershell on alternating keystrokes.
This can be demonstrated by getting the process ID of powershell and the pixi-shell, then corrupting the pixi-shell and checking the pids of both processes.

Steps:

• Start a powershell terminal
• Get the powershell pid: echo $pid
• Start the pixi shell: pixi shell
• Get the pixi-shell pid: echo $pid
• Corrupt the terminal as the OP suggested: sleep(1000) Enter and within 1 seconds Ctrl + C
• type echo $pid but type every keystroke twice
• Observe: Every time a key is pressed the cursor alternates between PS> and (pixi-env)PS>
• Press Enter twice (one for each process)
• Observe: One PID is the powershell, one is the pixi-shell

Are there any Ctrl + C hooks that could cause this behavior in the pixi-shell?

[maphew]

great sleuthing @Petzep, thanks! It's great to have a comprehenisble explanation, hopefully that reveals a path to a fix.

Only new bit I can add to the conversation is that this is not console software dependent. It happens for me in CMD and Powershell, and doesn't matter if run within default Windows, Windows Terminal or ConEmu.

[traversaro]

At least on my environments, the activation of pixi on windows take ~1/2 seconds, that makes it complicated to use pixi run as a replacement to pixi shell for terminal-intensive workflows. As I would really like to use pixi in some projects in which there is an extensive use of Windows, I am not currently exploring the workaround of using conda to activate the pixi environment:

conda activate .pixi/envs/default

That is far from perfect (you are basically ignoring the activation table of pixi.toml), but at least works with Ctrl+C .

Another alternative is to use https://github.com/synapticarbors/pixi2ces to create a conda lock file and create a different conda environment, but to be honest I do not love it as it as the same downside of the previous method, with the additional overhead of having a different conda environment, that can quickly diverse from the pixi one unless you pay attention.

[ruben-arts]

Does `eval "$(pixi shell-hook -s bash)" work?

[traversaro]

Does `eval "$(pixi shell-hook -s bash)" work?

Probably this is more related to #417 ?

Anyhow, I just tried and it hangs for ~1/2 seconds, and then it exists but it does not seem to me that the environemnt is actually activated.

[traversaro]

Anyhow, I just tried and it hangs for ~1/2 seconds, and then it exists but it does not seem to me that the environemnt is actually activated.

Actually the environment is activated, but the PATH variable does not contain the pixi-related parts.

[ruben-arts]

Ah because of that, issue in #417 with the path...

[arthur-st]

Running into this as well, both in the command prompt and in PowerShell. The simplest repo is like this:

1. pixi shell
2. python
3. press Ctrl+C
4. press Enter a couple of times

CMD will show an incorrectly exited Python interpreter, whereas PowerShell will just lock up after a few Enter presses (on a beefy machine).