This bug can be a bit difficult one to reproduce, because it requires protonup to have pending updates, otherwise the execution will not become stalled waiting for user input.

Erroneous Behavior

When running the command:

topgrade --yes from within a script. The topgrade programe is supposed to be running in non-interactive mode. However once it gets to the protonup target. Then it fails to call protonup command with necessary --yes flag to instruct it to perform non-interactive input. This results in the following stalling / pausing of the topgrade overall command executions. Since the child process (protonup) is itself stalled and waiting for user confirmation.

Expected Behavior

If topgrade --yes is being executed, then protonup --yes should be getting spawned. However AFAIKT it is not. And nothing in the topgrade code (in that location) seems to be explicitly manually passing in such --yes flag to tell it to do so (at least not unless implicitly thru some defaulted hidden function).

Steps to reproduce

In order to reproduce then protonup must itself have pending upgrades. So this cannot be achieved always so easily, since to have a pending update you must install something first with protonup (i.e. a specific proton version, such as GE edition). And then wait for that edition to itself have a new release. Since the version you just installed is already the newest version.

However I suppose you could (alternatively) just simply not install protonup command whatsoever onto your testing environment. But instead write some temporary dummy little test script, made it world executable. Such that once it gets invoked it pretends to be protonup and then waits or prints the supplied argv arguments. To proove that topgrade is actually being the point of failure here.

Possible Cause (Optional)

Quite possibly the initial commit never explicitly implemented this functionality. Or (at that earlier time), the child program being called (protonup command) had not yet implemented a --yes option. So then it just was not an implementable feature when the initial support was being added.

Problem persists without calling from topgrade

• [X ] Yes
• No

Did you run topgrade through Remote Execution

• Yes
• No

If yes, does the issue still occur when you run topgrade directlly in your
remote host

• [X ] Yes
• No

Additional Details

• Operation System/Version

Ubuntu 23.04

• Installation

Topgrade was installed via cargo package manager (so cargo install topgrade)

• Topgrade version (topgrade -V)

$ topgrade --version Topgrade 12.0.2

Verbose Output (topgrade -v)

DEBUG Step "protonup"
DEBUG Detected "/home/id/.py/venv/bin/protonup" as "protonup"
── 22:47:55 - protonup ─────────────────────────────────────────────────────────

DEBUG Executing command /home/id/.py/venv/bin/protonup

Ready to download GE-Proton8-16
Size      : 422.6 MiB

Published : 2023-09-24

Continue? (Y/n):