☰

erzwingt die Ausgabe in die Eingabe (den Puffer) wie "\033[6n" in einem Skript

tag-icon • tag-icon shell-script shell terminal tty c
erzwingt die Ausgabe in die Eingabe (den Puffer) wie "\033[6n" in einem Skript

Ich habe versucht, Pipes und Umleitungen zu verwenden, um die Ausgabe (von C-Programmen oder Skripten) im Eingabepuffer zu platzieren, was auch printf "\033[6n"funktioniert hat, aber ohne positive Ergebnisse.

Weiß jemand, wie das möglich ist, denn:

  1. eine Befehlszeile
  2. in einem Shell-Skript
  3. C-Code

Piping-Ausgabe _cmd_ > /dev/stdinund C-Code fprintf(stdin, "blah\n");haben keinen messbaren Effekt.

Notiz:Ich möchte die Eingabe nicht an einen anderen Befehl „weiterleiten“, sondern Zeichen sozusagen in den „Tastaturpuffer“ „einfügen“.

BEARBEITEN:Der ursprüngliche Anwendungsfall war eine Sandbox-CLI-App, shelldie systemexterneBefehlemit dem Betriebssystem zu interagieren (z. B. Bas), abernichtDatei-Deskriptoren verarbeiten.

Antwort1

Bearbeiten:Die kurze AntwortWar /dev/uinput, jetzt ist es TIOCSTI(siehe Ende des Beitrags)

Dies ist die Antwort bisher. Um auf die Kommentare einzugehen:

ioctl_tty(2)Ich habe nicht, aber eine Suche TIOCSTIin der Kernel-Quelle (überFreie Elektronen) zeigt tiocsti„falsche Eingabezeichen“ an, die einen tty_structKontext verwenden.

Die betreffende Anwendung läuft ständig interaktiv, sodass Pipes und Weiterleitungen nicht verwendet werden können. Sie kann shellfür Skripting verwendet werden, erfasst jedoch im Gegensatz zu vielen anderen ähnlichen Anwendungen die Ergebnisse nicht und erlaubt dies auch nicht, sondern lässt stdin& stdoutnur wie gewohnt ihre Arbeit verrichten.

In absehbarer Zukunft besteht keine Möglichkeit, dies zu ändern, es ist nicht meine Anwendung. Ich konnte jedoch die Ergebnisse von ausschneiden , die vom Kernel über & in "\033[6n"in den Tastaturpuffer eingefügt wurden , wobei ein Kontext verwendet wird.tty_insert_flip_chartty_schedule_flipsrc/drivers/tty/tty_buffer.ctty_port

Wenn ich mich recht erinnere, bevor die FD-Dateistruktur geändert wurde, als esnur4 Dateideskriptoren, wäre dies vielleicht möglich gewesen. Heutzutage kann man zwar in /dev/stdinoder schreiben /proc/self/fd/0, aber sie sind mit verbunden /dev/tty#und alles, was in ein TTY-Gerät geschrieben wird, landet auf dem Bildschirm ( /dev/stdout). Der Kernel scheint den Dateideskriptorweg bei der Verwendung von TTYs zu umgehen. Beachten Sie, dass die flipFunktionen darauf als verweisenHafen.

Keine Userland-App hat Zugriff auf diese Kernelfunktionen. Unter X-Windows ist es möglich, xvkbdund xdotooloder zu verwenden xte, aber diese App wird auf der Linux-Konsole (VT) verwendet.

Die (fast) richtige Antwort:

Obwohl /dev/uinputkein Benutzerzugriff (auf den meisten Systemen) besteht, funktioniert sudoein Skript mit allen Argumenten.printf

Alternativ kann die TastaturEreignisfunktioniert auch, da alle Benutzer darauf Zugriff haben, es ändert sich jedoch bei jedem Start und bei jedem System (bei mir ist es normalerweise so /dev/input/event0, aber nicht immer).

Nach weiteren Untersuchungen ist keiner dieser Ansätze praktikabel, insbesondere für Skripting. Was wir verstehen müssen, ist, dass wir nur präsentieren möchtenTextauf dem Eingabepuffer, nicht auf „einen Tastendruck simulieren“ (so funktionieren die oben genannten Geräte).

Die (praktischste) echte Antwort:

Eine externe Frage verwies auf eine Antwort auf Stackexchange aus dem Jahr 2011 (Hier). Es verwendet TIOCSTI. Nachdem Sie das Perl-Beispiel noch einmal durchgesehen haben, kann es auch für die Skripterstellung praktisch sein, wenn keine Anwendung bereitgestellt wird.

perl -le 'require "sys/ioctl.ph";
      ioctl(STDIN, &TIOCSTI, $_) for split "", join " ", @ARGV
     ' `_cmds_`

Allerdings wird es auch auf dem Bildschirm angezeigt. Nach vielen Stunden weiterer Recherche und Experimente ist Folgendes in einem Skript oder auf der Befehlszeile praktikabel:

stty -echo; perl -le 'require "sys/ioctl.ph"; ioctl(STDIN, &TIOCSTI, $_) for split "", join " ", @ARGV ' `_cmds_` ;stty echo

Notiz:wurde zwar TIOCSTIwiderrufen inOpenBSD 6.2(Oktober 2017), anscheinend sind die Linux-Kernel-Entwickler derGegenteilund weigerte sich kategorisch, es zu widerrufen (mehr dazu finden Sie imOpenBSD Journal).

Antwort2

Ab Debian Bullseye console-toolswurde es in aufgenommen , kbddavon writevtwarnichtenthalten. Wer es möchte, findet die Quellen im Update am Ende dieses Beitrags verlinkt.

writevt /dev/tty# text, zumindest unter Linux, vielleicht BSD und Unix, ist es derzeit Teil des console-toolsPakets. Der Benutzer mussschreibenBerechtigungen für das VT. Insbesondere (EDIT: wenn es auf Ihrem Betriebssystem verfügbar ist) lautet die vollständige und richtige Antwort auf das OP:

writevt `tty` "`_cmds_`"

Diese Frage zeigt, dass die StackExchange-Community als Ganzes nicht über fundiertes Wissen über Basisbetriebssysteme verfügt. writevtist sehr alt, es ist ein Basisbefehl, der auf 99 % (EDIT: Debian Linux) Systemen installiert ist. Bis Juni 2002 gab es in Debian weder eine Manpage noch einen Betreuer dafür, was erklären könnte, warum viele Leute nichts davon wissen, obwohl das vor 15 Jahren war. Aber selbst auf Kali Linux (dasalles) ist es meistens nicht aufgeführt unterverfügbar Befehle, obwohl es von Anfang an da war.

Ab Debian writevtwird Buster nicht mehr standardmäßig installiert und ist laut einigen möglicherweise in keinem Paket mehr vorhanden (aufgrund fehlender Betreuer? oder Paketänderungen console-tools?)

UPDATE: Tatsächlich kann ich console-toolsbei der Debian-Paketsuche (wo ich den Inhalt ursprünglich überprüft habe) nichts mehr finden, nicht einmal Backports.

Das ursprüngliche Paketprojekt ist hier:

http://lct.sourceforge.net/

Es sind keine Patches erforderlich. Raspbian/RPiOS hat hier einen Debian-Build (Wheezy bis Buster):

http://raspbian.raspberrypi.org/raspbian/pool/main/c/console-tools/

Zitat von Yan Dirson:

Aktuelle (öffentliche) Softwareprojekte, an denen ich arbeite: Das Debian GNU/Linux-Projekt, dessen Mitglied ich seit 1997 bin.

http://ydirson.free.fr/en/software/

warten auf kbdabsorbieren - 2001

Das console-toolsPaket aus dem Projekt „Linux Console Tools“ ist weiterhin in RPiOS verfügbar. Es ist nicht dasselbe wie linuxconsoletoolsdas Paket aus dem Projekt „Linux Console Project“, das sich ebenfalls auf SourceForge befindet.

verwandte Informationen