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

Abierto
  • ¿Algo no está bien?
#141 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
cli, operating-systems

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Rust
Estrellas
5.9k
Forks
180
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/sudo

Todos los issues de microsoft/sudo

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.