Cinco escenarios reales para los que CPYNET fue realmente construido - no hipotéticos. Cada comando de abajo es una entrada real contra un despliegue real, mostrado con la salida exacta que produce.
Estás conectado por SSH a un servidor remoto, algo falló, y necesitas hacer llegar las líneas de log relevantes a un compañero de equipo ahora mismo - sin otra ronda de acceso SSH ni enviar un archivo por correo.
$ journalctl -u myservice -n 200 | cpy482913curl "https://llmtag.com/482913"
Dos líneas de vuelta: el código desnudo y un comando curl listo para ejecutar. Pega cualquiera de los dos en el chat - quien lo lea obtiene el texto exacto, y desaparece en el instante en que lo hace:
$ pst 482913Aug 08 14:02:11 myservice[1823]: connection refused: db.internal:5432Aug 08 14:02:11 myservice[1823]: retrying in 5s...Aug 08 14:02:16 myservice[1823]: connection refused: db.internal:5432
Esa es la función de shell pst - como efecto secundario también deja el texto en su portapapeles, pura comodidad. ¿No tienen cpy/pst instalado? La línea simple curl "https://llmtag.com/482913" que cpy imprimió arriba funciona exactamente igual, sin necesitar ningún alias. En cualquier caso, una segunda lectura del mismo código (por cualquiera, incluyéndote a ti) devuelve un 404 - ya se ha ido.
Algunos entornos - portátiles corporativos bloqueados, sesiones VDI, escritorios remotos sin portapapeles compartido entre host e invitado - simplemente no te dejan copiar texto hacia fuera a través del portapapeles del sistema operativo.
$ echo "contraseña wifi: correcthorsebatterystaple" | cpy174205curl "https://llmtag.com/174205"
$ pst 174205contraseña wifi: correcthorsebatterystaple
CPYNET nunca toca el portapapeles del sistema operativo en la máquina bloqueada de todos modos - todo sale como texto plano a través de curl, así que un portapapeles deshabilitado no importa ahí. La máquina que lo lee de vuelta es una máquina normal, así que la comodidad del portapapeles de pst funciona bien en ese extremo. ¿No tienes terminal a mano en el lado receptor? Escanea el código QR que aparece después de enviar con tu teléfono en su lugar - se abre directamente en el navegador.
No todos con quienes necesitas compartir quieren ejecutar un comando - un cliente, un gerente, o un compañero de equipo en una máquina bloqueada solo necesita un enlace y una contraseña que escriben una vez, en un navegador.
$ echo "staging: https://staging.internal usuario: demo contraseña: xQ9!vB2m" | cpy -password=handoff2026591042curl "https://llmtag.com/591042"
Envía el enlace completo (no solo el código - el código por sí solo sigue necesitando la URL correcta) y la contraseña por canales separados. Abren el enlace en cualquier navegador, escriben la contraseña en el campo de la página, y lo leen una vez - sin CLI, sin extensión de navegador, sin cuenta. Una contraseña incorrecta falla sin consumir la lectura; si falta, simplemente vuelve a pedirla.
Un contenedor sin volumen compartido, un paso de compilación aislado, la salida intermedia de un trabajo de CI - cualquier lugar donde stdout sea accesible pero el sistema de archivos no se comparta con donde realmente necesitas el resultado.
$ docker run myimage some-command | curl --data-binary @- https://llmtag.com/https://llmtag.com/718234
Un pipe sin procesar (sin cpy instalado dentro del contenedor) devuelve solo la URL desnuda - sigue siendo exactamente una línea, sigue siendo encauzable al siguiente paso:
$ pst 718234{"status":"ok","records_processed":48213}
El contenedor no tenía cpy instalado, así que recurrió a un pipe sin procesar - tu propia máquina casi con certeza sí lo tiene, así que leerlo de vuelta es solo pst (un simple curl "https://llmtag.com/718234" funciona igual si no lo tiene). Funciona igual con kubectl exec, una imagen mínima scratch/distroless que ni siquiera tiene curl (ver el fallback de netcat), o cualquier otro entorno donde lo único a lo que puedes acceder de forma fiable es un pipe.
La contraseña de arriba (-password=) se verifica en el servidor - el servidor ve brevemente el texto plano para verificarla. cpy -e es una capa diferente, más fuerte: el cifrado ocurre enteramente en tu máquina antes de que se envíe nada, y el servidor solo almacena texto cifrado.
$ echo "frase de acceso ssh root: Tr0ub4dor&3" | cpy -e305817curl "https://llmtag.com/305817"key (share separately, never with the link/code): n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdE
Envía el código por un canal y la clave por uno diferente (una llamada, un segundo hilo de chat, en persona) - cualquiera que solo tenga el enlace o el código recibe texto cifrado ilegible, el servidor incluido.
$ pst 305817 -key=n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdEfrase de acceso ssh root: Tr0ub4dor&3
Si omites -key=, pst imprime el texto cifrado sin procesar en su lugar - el servidor nunca tiene suficiente información para descifrarlo de todos modos, con o sin clave.