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

Aberta
  • Algo errado?
#141 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
rust
Domínio
cli, operating-systems

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Rust
Estrelas
5.9k
Forks
180
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de microsoft/sudo

Todas as issues de microsoft/sudo

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.