pipx run isn't redirecting signals to child app (?)

Hello,

What a wonderful tool, no more manual management of python apps in my system 😃

About the issue, I wonder if signals are being redirected to the child app when calling pipx run <app>. For instance:

pipx run --spec tmonpy tmon

tmon in the absence of arguments, waits for SIGINT to return and print a temperature report. But it looks like pipx run when SIGINT-ed kills the app and doesn’t give it a chance to return gracefully (I could be wrong though, I haven’t looked at the source).

So this is what I would expect to happen:

pipx run --spec tmonpy tmon

wait a few seconds, press Ctrl+C and a graph should be printed in the terminal:

===================
Temp Monitor Report

    temp (°C) for a period of 0:00:04
       41.00  ┤
       40.86  ┤
       40.71  ┤
       40.57  ┤
       40.43  ┤
       40.29  ┤
       40.14  ┤
       40.00  ┼╮
       39.86  ┤│
       39.71  ┤│
       39.57  ┤│
       39.43  ┤│
       39.29  ┤│
       39.14  ┤│
       39.00  ┤╰───

    min: 39.1 °C
    avg: 39.2 °C
    max: 40.0 °C

    raw: /tmp/[e-mail]
===================

Note: tmon is expected to work on Linux only! Don’t try to run the test case on mac or win.

[uranusjr]

I couldn’t find any good documentation on why, however. ox.exec* lists availability on Windows. @uranusjr, why do you need to fall back to subprocess for Windows?

Do we just need to use our original code for Windows? Or is there an advantage to how pipenv does things with subprocess.Popen(), etc.?

Windows and Unix-like systems implement exec* stuff differently. On POSIX, the process is first forked, and then the new program is loaded into the (forked) process. Windows does not have fork, so the implementation basically starts a new process in the background, and exits the current process. This is fine for Windows (the subsystem, not the operating system) applications, but has some unexpected (to people familiar with the fork-based implementation) behaviours when used in the console subsystem. You can try this in cmd.exe:

C:\>py -c "import os, sys; os.execl(sys.executable, 'python', '-V')"

C:\>Python 3.9.0

You can see a prompt being displayed before the version information, because the process launched with os.execl is in the background, and you get dropped back to the shell when the former process exits. This causes more problems when you need to interact with the launched process:

C:\>py -c "import os, sys; os.execl(sys.executable, 'python', '-q')"

C:\>>>> import sys
'import' is not recognized as an internal or external command,
operable program or batch file.

Since the new process is in the background, and the user is dropped back to the shell, all inputs now goes to the shell, not the launched process.

Rule of thumb: Don’t use the exec* family on Windows in a console application. It never does what you want.

[uranusjr]

os.exec* (which calls into the corresponding exec* C functions) “swaps out” the current process entirely, so the current process (which is running pytest) just vanishes in thin air when you call that. This is done at the OS level, thus not possible to verify with pytest. The best thing you can do is to mock it out and verify the arguments.