Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

dor send --stdin interprets backslash escapes in piped bytes

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
50/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
cli

Línea de trabajo

Comienza en dor/src/commands/send.ts, en el manejo de stdin y la conversión de escape de texto descritos en el issue. Confirma el comportamiento actual con el ejemplo documentado de piping y, después, espera a que el maintainer elija entre usar raw stdin por defecto o documentar el comportamiento existente. Se considera terminado cuando el contrato elegido está implementado o documentado, con una prueba de regresión que preserve los bytes relevantes.

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

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
5
Forks
1
Merge medio
12 h 46 min
PR fusionados (30 d)
322

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 diffplug/dormouse

Todos los issues de diffplug/dormouse

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.