Durante años, tmux ha sido una de esas herramientas que muchos administradores de sistemas y desarrolladores instalan casi por reflejo en cualquier servidor. Permite mantener sesiones abiertas tras una desconexión SSH, dividir la terminal en paneles, trabajar con varias ventanas y volver más tarde al mismo entorno. Antes estuvo GNU Screen, todavía presente en muchos sistemas Unix y Linux, y después llegaron opciones más minimalistas como abduco o dtach.
Atch entra en esa tradición, pero con una idea distinta: no quiere ser un multiplexor de terminal completo ni competir con tmux en gestión de ventanas. Quiere resolver bien una necesidad concreta, mantener un proceso vivo, permitir desconectarse y volver, sin romper el comportamiento normal de la terminal y guardando todo el historial en disco. Para quien usa tmux solo para que un proceso sobreviva a una caída de SSH, esa diferencia puede ser suficiente.
El problema no es tmux, sino usarlo para todo
tmux sigue siendo una herramienta muy potente. Su manual lo define como un multiplexor de terminal que permite crear, acceder y controlar varias terminales desde una sola pantalla, con sesiones que pueden separarse y volver a conectarse más tarde. También ofrece ventanas, paneles, una línea de estado, comandos interactivos y un servidor que gestiona las sesiones en segundo plano.
Ese diseño es ideal para usuarios que viven dentro de tmux: dividen paneles, saltan entre ventanas, comparten sesiones, personalizan atajos y construyen flujos enteros alrededor de su configuración. El problema aparece cuando se usa tmux para algo mucho más pequeño: lanzar un trabajo largo por SSH y recuperarlo después. En ese caso, muchas de sus capacidades sobran y algunas pueden molestar.
Quien haya peleado con el scroll del ratón, el modo copia, los buffers alternativos de programas como vim, fzf o htop, los ajustes de TERM, los colores verdaderos o las secuencias modernas de terminal sabe que los multiplexores pueden introducir una capa de comportamiento inesperado. No es un fallo absurdo: tmux tiene que interpretar y gestionar la terminal porque necesita ofrecer paneles, scrollback y ventanas. Pero esa capa también puede hacer que una aplicación no se comporte exactamente igual dentro y fuera de tmux.
Atch parte de la premisa contraria. No implementa un emulador de terminal ni intenta reinterpretar la salida. Según su repositorio, pasa el flujo de bytes del pseudoterminal a la terminal sin modificarlo. Esto significa que el ratón, los colores, las secuencias OSC, los gráficos compatibles con terminal y los programas que usan pantalla alternativa dependen de la terminal real del usuario, no de una capa intermedia.
Qué aporta atch frente a screen, tmux, abduco y dtach
GNU Screen fue durante mucho tiempo la respuesta clásica para mantener procesos vivos tras una desconexión. El proyecto GNU lo describe como un gestor de pantalla completa que multiplexa una terminal física entre varios procesos, normalmente shells interactivos, con ventanas independientes, scrollback y posibilidad de separar la sesión.
abduco y dvtm dividieron mejor las responsabilidades. abduco se centra en separar y volver a adjuntar programas a una sesión, mientras que dvtm ofrece gestión dinámica de ventanas en consola. Marc André Tanner, autor de ambos, describe abduco como una alternativa más simple y limpia a tmux o screen cuando se combina con dvtm, y dvtm como un gestor de ventanas en mosaico para consola que delega la gestión de sesión en otra herramienta.
atch se sitúa más cerca de dtach y abduco que de tmux. Su intención no es ofrecer un escritorio dentro de la terminal, sino crear una sesión con nombre, dejar un proceso corriendo, separarse, volver y conservar lo ocurrido. La gran diferencia está en el historial persistente: cada byte escrito en el terminal se añade a un log en disco dentro de ~/.cache/atch/. Al volver a adjuntar una sesión, atch reproduce primero el historial completo y después entrega el flujo en vivo. Ese log sobrevive a desconexiones, salida del proceso, caídas y reinicios de la máquina, hasta que el usuario lo limpia explícitamente.
| Herramienta | Enfoque | Punto fuerte | Límite para algunos usos |
|---|---|---|---|
| GNU Screen | Multiplexor clásico | Muy extendido y disponible en muchos sistemas | Comportamiento más antiguo y configuración menos cómoda |
| tmux | Multiplexor moderno | Ventanas, paneles, sesiones, ecosistema y scripting | Puede ser excesivo si solo se quiere persistencia de sesión |
| abduco + dvtm | Separación Unix de responsabilidades | Sesiones simples y ventanas en consola por separado | Requiere combinar herramientas si se quiere todo |
| dtach | Adjuntar y separar procesos | Minimalismo extremo | Sin listado cómodo ni historial persistente en disco |
| atch | Sesiones transparentes con logs persistentes | No emula terminal y guarda salida en disco | No ofrece paneles ni gestión de ventanas |
El diseño de atch también incorpora comandos prácticos para automatización. Permite listar sesiones con atch list, enviar entrada estándar a una sesión ya abierta con atch push, seguir el log con atch tail -f, matar una sesión con atch kill o limpiar el historial con atch clear. También puede mostrar sesiones ya finalizadas si todavía conservan log en disco mediante atch list -a.
Por qué puede interesar a sysadmins, DevOps y usuarios de agentes
Atch resulta especialmente interesante en tres escenarios. El primero es el de administración remota clásica: entrar por SSH, lanzar una compilación, una migración, una copia larga, una actualización o un proceso de mantenimiento, salir y volver más tarde. Si la conexión se cae, el proceso no debería morir. Si el proceso termina mientras el usuario no está conectado, la salida no debería perderse.
El segundo escenario es CI/CD y automatización. Un webhook puede lanzar un despliegue dentro de una sesión atch y devolver respuesta de inmediato. Después, un operador puede adjuntarse a la sesión, revisar el historial completo o seguir el log sin necesidad de haber estado conectado desde el principio. Esto no sustituye a un sistema formal de observabilidad ni a un orquestador de despliegues, pero puede ser muy útil en entornos pequeños, laboratorios, servidores personales o tareas operativas donde una herramienta ligera encaja mejor que una plataforma completa.
El tercer caso es el de los agentes de IA y procesos largos asistidos por modelos. Muchas herramientas actuales ejecutan tareas durante minutos u horas: revisan repositorios, generan código, procesan ficheros, llaman a APIs, escriben logs y esperan instrucciones. Poder lanzar un agente dentro de una sesión persistente, desconectar, volver, revisar todo lo que hizo y enviar una nueva instrucción mediante atch push puede convertir atch en una pieza sencilla para flujos experimentales de IA agéntica.
También ayuda en forense operativa básica. Si un proceso muere o el servidor se reinicia, el historial no desaparece con el buffer de memoria de la sesión. El repositorio indica que el log se limita por defecto a 1 MB, aunque puede ajustarse con la opción -C o cambiarse al compilar. Es un detalle importante: guardar todo en disco tiene valor, pero también exige controlar tamaño, privacidad y rotación si se usa en entornos con información sensible.
Una herramienta pequeña para quien no necesita un multiplexor completo
Atch no es una alternativa universal a tmux. Si un usuario vive entre paneles, layouts, ventanas, plugins, sesiones compartidas y atajos personalizados, tmux seguirá siendo mejor herramienta. Atch renuncia deliberadamente a todo eso. Su propuesta consiste en hacer menos cosas, pero reducir interferencias.
Esa elección tiene sentido dentro de la filosofía Unix. En vez de asumir que toda sesión persistente necesita multiplexación completa, atch separa el problema: conservar un proceso, permitir reenganche, registrar salida y dejar que la terminal real gestione el resto. Para muchos administradores, esa simplicidad puede ser más atractiva que mantener otra configuración más en dotfiles.
El proyecto está escrito en C, se compila con make y no busca depender de un entorno pesado. Su adopción dependerá de la estabilidad, empaquetado en distribuciones, auditoría del código y confianza de la comunidad. Al tratarse de una herramienta de bajo nivel que intermedia sesiones de terminal, conviene probarla primero en entornos no críticos y revisar bien cómo maneja permisos, logs y rutas de sesión.
La aparición de atch recuerda algo que a veces se olvida en el mundo de las herramientas para terminal: no todos los usuarios necesitan más paneles, más plugins o más capas. A veces solo necesitan que un comando siga corriendo, que la terminal se comporte como siempre y que el historial no se evapore cuando más falta hace. Para ese caso concreto, atch plantea una respuesta pequeña, transparente y muy propia de sistemas Unix.
Preguntas frecuentes
¿Atch sustituye a tmux?
No para todos. Puede sustituirlo si solo se usa tmux para mantener procesos vivos y volver a una sesión después. No sustituye sus paneles, ventanas, plugins ni gestión avanzada de layouts.
¿Qué diferencia a atch de dtach?
Atch sigue una filosofía parecida de adjuntar y separar procesos, pero añade historial persistente en disco, listado de sesiones, push para enviar entrada a una sesión y comandos como tail, clear o kill.
¿Por qué es importante que no emule una terminal?
Porque reduce la posibilidad de que el ratón, el scroll, los colores, la pantalla alternativa o ciertas secuencias modernas se comporten de forma distinta dentro y fuera de la sesión.
¿Hay que tener cuidado con los logs?
Sí. Atch guarda salida en disco por defecto. Eso es útil para recuperar historial, pero puede incluir datos sensibles. En servidores compartidos o entornos regulados conviene revisar permisos, tamaño máximo y políticas de limpieza.
vía: medium
