ProcessRunner

Corre un proceso hasta que termina o hasta que se acaba el plazo, y devuelve su salida CON su código. ── POR QUÉ NO ES `Board\Shell` ───────────────────────────────────────────────────────────────── Porque {@see \Milpa\DevTools\Board\Shell::run()} devuelve `null` cuando el proceso sale distinto de cero, y para el tablero eso es correcto: un comando que falló no le sirve. Aquí es al revés — un proceso que salió en rojo es justo el caso interesante, y su salida es lo único que le dice a alguien qué arreglar. Dos contratos opuestos sobre la misma llamada al sistema; unificarlos obligaría a uno de los dos a fingir. ── POR QUÉ ES UNA CLASE Y NO UN CALLABLE ─────────────────────────────────────────────────────── Para que se pueda sustituir en una prueba sin sacar un proceso de verdad, que es el mismo motivo por el que existe `Board\Shell`. Nació además de un tropiezo: un parámetro `?\Closure` con default hacía fallar la resolución de {@see \Milpa\DevTools\Operations\TestHandler} en la app anfitriona, aunque el default estaba ahí para no necesitarlo nunca. Ese defecto del contenedor ya se arregló —`milpa/container` ya no intenta construir lo que PHP no deja construir— así que hoy esto es una clase por lo primero y no por lo segundo. Se queda igual: la costura por clase es el idioma que este monorepo ya usaba, y un tipo nombrado dice qué se sustituye mientras un `Closure` sólo dice su firma.

public function run(array $command, string $cwd, int $timeoutSeconds): array

Corre `$command` en `$cwd` y espera a lo más `$timeoutSeconds`. `stdout` y `stderr` se juntan en el orden en que salieron: separarlos obligaría a quien lee a recomponer la cronología, y el error que importa suele estar en el otro flujo del que se está mirando. Códigos propios cuando el proceso no fue quien contestó: `127` si no arrancó, `124` si se pasó del plazo — los mismos que usa una terminal, para que quien los vea ya sepa qué significan.

Parameters