Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

dor send --stdin interprets backslash escapes in piped bytes

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

メンテナーはふだん 1 日以内に返信

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

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
50/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
typescript
領域
cli

調査の方向性

issue で説明されている stdin の処理とテキストのエスケープ変換について、dor/src/commands/send.ts から始めます。ドキュメント化された piping の例で現在の動作を確認し、その後、デフォルトで raw stdin にするか、既存の動作を文書化するかを maintainer が選ぶまで待ちます。選択された契約が実装または文書化され、関連するバイト列を保持する回帰テストがあれば完了です。

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

説明

dor send --stdin interprets backslash escapes in piped bytes, corrupting the documented use case

dor send --stdin reads standard input and forwards it as a text input:

if (flags.stdin === true) {
  if (!readStdin) return { ok: false, message: 'stdin is not available' };
  return { ok: true, value: [{ kind: 'text', text: await readStdin() }] };
}

(send.ts:183-186)

Text inputs then run through interpretTextEscapes unless --raw is set:

input += raw ? item.text : interpretTextEscapes(item.text);

(send.ts:227-228, converting \n \r \t \\ at send.ts:238-253)

Why this is a footgun for --stdin

The flagship stdin example in the help is:

cat script.sh | dor send surface:3 --stdin

(send.ts:115)

Bytes arriving on stdin are already literal — they are not a shell-authored string where a two-character \t stands in for a tab. Shell scripts routinely contain literal backslash sequences (printf 'a\tb', sed 's/\n/ /', grep -P '\d', Windows paths with \\). Piping such a file through --stdin silently rewrites every \n/\r/\t/\\, so the text typed into the target terminal is not the file's contents.

Repro: printf 'printf "a\\tb\\n"\n' | dor send surface:3 --stdin types a real TAB and newline into the middle of the line instead of the literal \t/\n the script source contains.

The escape interpretation is desirable for --text "echo hi\nthere" (a human types escapes on the command line), but for --stdin the input is already-real bytes.

Design question (why an issue, not a drive-by PR)

The current behavior is consistent with the documented contract — the help says "Text input interprets backslash escapes … unless --raw is set" (send.ts:97), and --stdin is documented as text input — so flipping the default is a contract change that needs a maintainer call. Options:

  1. Make --stdin raw by default — treat piped bytes as literal; keep --text interpreting escapes. Most aligned with the cat script.sh | … example. Would need an opt-in flag if anyone wants escape interpretation on stdin.
  2. Keep current behavior, document it — call out at the --stdin help that it interprets escapes and that --raw is needed for literal file contents.

I lean toward option 1, but it changes documented behavior, so I'm leaving the call to a maintainer. Happy to open the PR (including a regression test that pipes a script containing \t and asserts the bytes are preserved) once a direction is chosen.

Surfaced by the nightly code-quality survey.

主要言語
TypeScript
スター
5
フォーク
1
平均マージ
12時間 46分
マージ済み PR（30日）
322

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

diffplug/dormouse のほかの issue

diffplug/dormouse の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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