Feature request: return the final console contents after a command runs in a new elevated window

Ouverte
  • Quelque chose ne va pas ?
#141 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
cli, operating-systems

Piste de recherche

Read the related issue #120 and review the attached proof-of-concept source, build instructions, and test scripts to understand the proposed console snapshot behavior. Then trace how sudo currently launches elevated commands through ShellExecuteEx and assess the proposed helper and result channel against that path. Done means an agreed integration design that handles final console text, colors, scrollback, and exit code within the stated limits; the issue says the prototype is not an integration patch and requests architectural feedback first.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Issue-Feature Needs-Triage
Description of the new feature / enhancement

I would like an opt-in extension to forceNewWindow that returns the elevated console’s final contents to the originating console after the command exits.

The command would run interactively in a separate elevated console, with input confined to that console. After completion, sudo would return its saved text, foreground/background colors, scrollback, and command exit code to the originating console.

The result would represent the final console state, rather than replay intermediate output. Overwritten or erased text and completed progress indicators would be included only if they remain in that final state. Blank lines within the output would be preserved; unused trailing buffer space would be excluded, even if it has a colored background.

A possible implementation:

  1. An elevated helper launches the command in a separate conhost console and retains the console after the command exits.
  2. The helper reads the final screen buffer, including retained scrollback.
  3. A secured, one-way result channel transfers a bounded snapshot and the command exit code to the unelevated sudo process.
  4. The unelevated process renders the text and colors in its originating console without replaying arbitrary control sequences.

The source-buffer size could be configurable within conhost’s supported limits and set before launching the command. This would not change the originating terminal’s history settings. The feature would return retained console contents, not promise an unlimited output log.

I suggest making this explicitly opt-in, with the CLI and implementation subject to discussion.

Scenario when this would be used?

I prefer running administrative commands in a separate elevated console (for security reason), but I also want their results retained in my original terminal session.

Short commands can close their elevated window before I can read the output. Longer or interactive commands can require input in that separate window, while their final results would still be useful alongside my previous work in the original console.

This is related to #120. Instead of keeping the elevated window open or requiring another keypress, the proposed feature would return its final contents automatically after command completion.

Supporting information

I have tested a standalone Windows proof of concept using conhost and classic console APIs.

The tests covered colored text and backgrounds, retained scrollback, interleaved stdout/stderr display, cursor-based overwriting, erased text, Windows PowerShell 5.1 Write-Progress, and returning the command exit code.

Without resizing, completed progress indicators disappeared as expected. With resizing, PowerShell sometimes left artifacts in the elevated console; the snapshot preserved those existing artifacts rather than attempting to reconstruct or correct the application’s display.

The prototype currently increases the source buffer to approximately 32K rows at ordinary console widths. Classic console API limits still apply. Other limitations include classic palette attributes and physical line wrapping. Excluding unused trailing colored rows remains to be implemented.

This is a final-state snapshot, not a replacement for separate stdout/stderr streams or lossless logging. Contents already erased or displaced from the source buffer cannot be recovered.

The prototype has not undergone a security audit. I understand that introducing an elevated helper and IPC changes the tradeoffs of the current direct ShellExecuteEx path. I would welcome feedback on whether this feature fits sudo and which architecture would be acceptable before preparing an integration PR.

Attached are the standalone proof-of-concept source code, build instructions, and test scripts. These demonstrate the proposed mechanism; they are not a sudo integration patch. The known limitations described above still apply.

ConhostReturn-Prototype-0.8.zip
ConhostReturn-WriteProgress-Test.zip

Langage dominant
Rust
Étoiles
5.9k
Forks
180
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de microsoft/sudo

Toutes les issues de microsoft/sudo

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.