Fünf reale Szenarien, für die CPYNET tatsächlich gebaut wurde - keine hypothetischen. Jeder Befehl unten ist eine echte Eingabe gegen ein echtes Deployment, mit der exakten Ausgabe, die er erzeugt.
Du bist per SSH mit einem entfernten Server verbunden, etwas ist fehlgeschlagen, und du musst die relevanten Log-Zeilen gerade jetzt an ein Teammitglied bringen - ohne eine weitere Runde SSH-Zugriff oder eine Datei per E-Mail.
$ journalctl -u myservice -n 200 | cpy482913curl "https://llmtag.com/482913"
Zwei Zeilen zurück: der nackte Code und ein einsatzbereiter curl-Befehl. Füge eine der beiden im Chat ein - wer sie liest, bekommt genau den Text, und er ist in dem Moment weg, in dem das passiert:
$ 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
Das ist die pst-Shell-Funktion - sie legt den Text als Nebeneffekt auch in die Zwischenablage, reiner Komfort. Kein cpy/pst auf der anderen Seite installiert? Die einfache Zeile curl "https://llmtag.com/482913", die cpy oben ausgegeben hat, funktioniert genauso, kein Alias nötig. So oder so: Ein zweites Lesen desselben Codes (von wem auch immer, dich eingeschlossen) liefert einen 404 - er ist schon weg.
Manche Umgebungen - abgeschottete Firmenlaptops, VDI-Sitzungen, Remote-Desktops ohne geteilte Zwischenablage zwischen Host und Gast - lassen dich überhaupt kein Text über die Betriebssystem-Zwischenablage herauskopieren.
$ echo "WLAN-Passwort: correcthorsebatterystaple" | cpy174205curl "https://llmtag.com/174205"
$ pst 174205WLAN-Passwort: correcthorsebatterystaple
CPYNET rührt die Betriebssystem-Zwischenablage auf der abgeschotteten Maschine ohnehin nie an - alles geht als reiner Text über curl raus, eine deaktivierte Zwischenablage spielt dort also keine Rolle. Die Maschine, die es zurückliest, ist eine normale, also funktioniert der Zwischenablage-Komfort von pst dort problemlos. Kein Terminal auf der Empfängerseite griffbereit? Scanne stattdessen den nach dem Senden angezeigten QR-Code mit deinem Handy - er öffnet sich direkt im Browser.
Nicht jeder, mit dem du teilen musst, will einen Befehl ausführen - ein Kunde, eine Führungskraft, oder ein Teammitglied an einer abgeschotteten Maschine braucht nur einen Link und ein Passwort, das einmal im Browser eingegeben wird.
$ echo "staging: https://staging.internal Benutzer: demo Passwort: xQ9!vB2m" | cpy -password=handoff2026591042curl "https://llmtag.com/591042"
Schicke den reinen Link (nicht nur den Code - der Code allein braucht immer noch die richtige URL) und das Passwort über getrennte Kanäle. Sie öffnen den Link in einem beliebigen Browser, tippen das Passwort in das Feld auf der Seite und lesen ihn einmal - kein CLI, keine Browser-Erweiterung, kein Konto. Ein falsches Passwort schlägt fehl, ohne die Lesung zu verbrauchen; ein fehlendes fragt einfach erneut.
Ein Container ohne geteiltes Volume, ein isolierter Build-Schritt, die Zwischenausgabe eines CI-Jobs - überall dort, wo stdout erreichbar ist, das Dateisystem aber nicht mit dem geteilt wird, wo du das Ergebnis eigentlich brauchst.
$ docker run myimage some-command | curl --data-binary @- https://llmtag.com/https://llmtag.com/718234
Ein roher Pipe (kein cpy im Container installiert) bekommt nur die nackte URL zurück - immer noch genau eine Zeile, immer noch in den nächsten Schritt pipebar:
$ pst 718234{"status":"ok","records_processed":48213}
Der Container hatte kein cpy installiert, also griff er auf einen rohen Pipe zurück - deine eigene Maschine hat es mit ziemlicher Sicherheit, also ist das Zurücklesen einfach pst (ein einfaches curl "https://llmtag.com/718234" funktioniert identisch, falls nicht). Funktioniert genauso mit kubectl exec, einem minimalen scratch/distroless-Image, das nicht mal curl hat (siehe den netcat-Fallback), oder jeder anderen Umgebung, in der das Einzige, was du zuverlässig erreichen kannst, ein Pipe ist.
Das Passwort oben (-password=) wird serverseitig geprüft - der Server sieht den Klartext kurz, um es zu verifizieren. cpy -e ist eine andere, stärkere Schicht: die Verschlüsselung passiert vollständig auf deiner Maschine, bevor irgendetwas gesendet wird, und der Server speichert nur jemals Chiffretext.
$ echo "root SSH-Passphrase: Tr0ub4dor&3" | cpy -e305817curl "https://llmtag.com/305817"key (share separately, never with the link/code): n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdE
Schicke den Code über einen Kanal und den Schlüssel über einen anderen (ein Anruf, ein zweiter Chat-Thread, persönlich) - wer nur den Link oder Code hat, bekommt unlesbaren Chiffretext zurück, der Server eingeschlossen.
$ pst 305817 -key=n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdEroot SSH-Passphrase: Tr0ub4dor&3
Lässt du -key= weg, gibt pst stattdessen den rohen Chiffretext aus - der Server hat so oder so, mit oder ohne Schlüssel, nie genug Information, um ihn zu entschlüsseln.