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

オープン
  • 何か問題がありますか？
#141 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
rust
領域
cli, operating-systems

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
Rust
スター
5.9k
フォーク
180
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/sudo のほかの issue

microsoft/sudo の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。