CPYNET

Casos de uso

Cinco cenários reais para os quais o CPYNET foi realmente construído - não hipotéticos. Cada comando abaixo é uma entrada real contra um deployment real, mostrado com a saída exata que produz.

Compartilhando um log de uma sessão SSH

Você está conectado via SSH a um servidor remoto, algo falhou, e precisa levar as linhas de log relevantes a um colega de equipe agora mesmo - sem outra rodada de acesso SSH ou enviar um arquivo por e-mail.

você, no servidor
$ journalctl -u myservice -n 200 | cpy482913curl "https://llmtag.com/482913"

Duas linhas de volta: o código puro e um comando curl pronto para rodar. Cole qualquer um dos dois no chat - quem ler recebe o texto exato, e ele desaparece no instante em que isso acontece:

seu colega de equipe
$ 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

Essa é a função de shell pst - ela também deixa o texto na área de transferência como efeito colateral, pura conveniência. Sem cpy/pst instalado do outro lado? A linha simples curl "https://llmtag.com/482913" que o cpy imprimiu acima funciona exatamente igual, sem precisar de alias. De qualquer forma, uma segunda leitura do mesmo código (por qualquer um, incluindo você) retorna 404 - já se foi.

Tirando texto de uma máquina com área de transferência desativada

Alguns ambientes - laptops corporativos bloqueados, sessões VDI, desktops remotos sem área de transferência compartilhada entre host e convidado - simplesmente não deixam você copiar texto para fora pela área de transferência do sistema operacional.

a máquina bloqueada
$ echo "senha do wifi: correcthorsebatterystaple" | cpy174205curl "https://llmtag.com/174205"
sua própria máquina, minutos depois
$ pst 174205senha do wifi: correcthorsebatterystaple

O CPYNET nunca toca na área de transferência do sistema operacional na máquina bloqueada de qualquer forma - tudo sai como texto simples via curl, então uma área de transferência desativada não importa ali. A máquina que lê de volta é uma máquina normal, então a conveniência da área de transferência do pst funciona bem nesse lado. Sem terminal à mão do lado receptor? Escaneie o código QR mostrado após o envio com seu celular - ele abre direto no navegador.

Entregando um link protegido por senha a um colega não técnico

Nem todo mundo com quem você precisa compartilhar quer rodar um comando - um cliente, um gerente, ou um colega de equipe em uma máquina bloqueada só precisa de um link e uma senha que digitam uma vez, em um navegador.

você
$ echo "staging: https://staging.internal  usuário: demo  senha: xQ9!vB2m" | cpy -password=handoff2026591042curl "https://llmtag.com/591042"

Envie o link completo (não apenas o código - o código sozinho ainda precisa da URL certa) e a senha por canais separados. Eles abrem o link em qualquer navegador, digitam a senha no campo da página, e leem uma vez - sem CLI, sem extensão de navegador, sem conta. Uma senha errada falha sem consumir a leitura; uma senha ausente apenas pede novamente.

Trazendo a saída de um container de volta para o host

Um container sem volume compartilhado, uma etapa de build isolada, a saída intermediária de um job de CI - qualquer lugar onde o stdout é acessível mas o sistema de arquivos não é compartilhado com onde você realmente precisa do resultado.

dentro do container
$ docker run myimage some-command | curl --data-binary @- https://llmtag.com/https://llmtag.com/718234

Um pipe puro (sem cpy instalado dentro do container) recebe de volta apenas a URL pura - ainda exatamente uma linha, ainda encadeável para o próximo passo:

no host
$ pst 718234{"status":"ok","records_processed":48213}

O container não tinha cpy instalado, então caiu para um pipe puro - sua própria máquina quase certamente tem, então ler de volta é só pst (um simples curl "https://llmtag.com/718234" funciona igual se não tiver). Funciona da mesma forma com kubectl exec, uma imagem mínima scratch/distroless que nem tem curl (veja o fallback de netcat), ou qualquer outro ambiente onde a única coisa que você consegue alcançar de forma confiável é um pipe.

Criptografando de ponta a ponta um compartilhamento pela CLI

A senha acima (-password=) é verificada no lado do servidor - o servidor vê brevemente o texto puro para verificá-la. cpy -e é uma camada diferente, mais forte: a criptografia acontece inteiramente na sua máquina antes de qualquer envio, e o servidor só armazena texto cifrado.

você, criptografando no lado do cliente
$ echo "frase secreta ssh root: Tr0ub4dor&3" | cpy -e305817curl "https://llmtag.com/305817"key (share separately, never with the link/code): n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdE

Envie o código por um canal e a chave por outro (uma ligação, uma segunda thread de chat, pessoalmente) - quem tiver apenas o link ou o código recebe texto cifrado ilegível de volta, servidor incluído.

quem tiver tanto o código quanto a chave
$ pst 305817 -key=n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdEfrase secreta ssh root: Tr0ub4dor&3

Omita -key= e o pst imprime o texto cifrado bruto em vez disso - o servidor nunca tem informação suficiente para decifrá-lo de qualquer forma, com ou sem chave.