Pipelineelemente mit unterschiedlichen controlling terminals?
Hauke Laging
ich habe ein bisschen mit screen herumgespielt, erfolglos, und finde
bei Google auch den Thread dazu hier nicht wieder, an den ich mich
dunkel erinnere.
Kann man eine Pipeline so starten, dass die einzelnen Elemente
unterschiedliche controlling terminals haben? Sinn der Aktion wäre
vor allem, Konflikte zu vermeiden, die daraus entstehen, dass
mehrere Teile der Pipeline von der Tastatur lesen wollen.
Ich habe allerlei Varianten von
screen ... | screen
probiert, was meistens mit der Meldung
Must be connected to a terminal.
scheitert. Wenn ich das richtig verstehe, merkt eins der beiden
screens, dass ihm das physische Terminal nicht so richtig gehört und
startet gar nicht erst. Nun kann man screen aber auch benutzen, ohne
dass es sich das Terminal gleich greift. Aber
screen -d -m -S S1 cat | screen -d -m -S S2 less
vermeidet zwar die Fehlermeldung, startet aber nur eine
screen-Sitzung. Was da scheitert und warum, habe ich nicht
herausbekommen, weil die strace-Ausgabe (-f) zu der aufrufenden
Shell etwas wild ist.
Geht das überhaupt? Hat das schon mal jemand erfolgreich praktiziert?
Wen ja, wie? :-)
CU
Leonard Orb
> screen -d -m -S S1 cat | screen -d -m -S S2 less
>
> vermeidet zwar die Fehlermeldung, startet aber nur eine
> screen-Sitzung. Was da scheitert und warum, habe ich nicht
> herausbekommen, ...
Das klappt deshalb nicht, weil das erste screen mit dem zweiten screen
in der Pipe steht, die Programme cat und less aber von ihren jeweiligen
screens mit eigenem Pseudo-Terminal gestartet werden.
Du hast danach einen detached screen, in dem "cat" auf Eingaben wartet.
Der screen mit less hat sich bereits wieder beendet, weil "less" ohne
Datei als Parameter auf einem Terminal nur eine Fehlermeldung ausgibt.
> Sinn der Aktion wäre vor allem, Konflikte zu vermeiden, die daraus
> entstehen, dass mehrere Teile der Pipeline von der Tastatur lesen
> wollen.
Wäre das mit Eingabeumleitung nicht wesentlich einfacher in den Griff zu
bekommen?
Leo
Hauke Laging
> Hauke Laging:
>
>> screen -d -m -S S1 cat | screen -d -m -S S2 less
>>
>> vermeidet zwar die Fehlermeldung, startet aber nur eine
>> screen-Sitzung. Was da scheitert und warum, habe ich nicht
>> herausbekommen, ...
>
> Das klappt deshalb nicht, weil das erste screen mit dem zweiten
> screen in der Pipe steht, die Programme cat und less aber von ihren
> jeweiligen screens mit eigenem Pseudo-Terminal gestartet werden.
Das kann ich nicht als Grund gelten lassen, weil genau das ja das
Ziel war! :-)
Das Problem liegt beim zweiten Teil des Ziels: Die Pipeline
funktioniert insofern nicht, als screen die Standarddeskriptoren
sofort schließt:
24429 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID
CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f6129bd0780) = 24430
24430 close(0) = 0
24430 open("/dev/null", O_RDONLY) = 0
Offenbar ist mein Wunschszenario nicht vorgesehen.
> Du hast danach einen detached screen, in dem "cat" auf Eingaben
> wartet. Der screen mit less hat sich bereits wieder beendet, weil
> "less" ohne Datei als Parameter auf einem Terminal nur eine
> Fehlermeldung ausgibt.
less ohne Dateiparameter UND mit einem tty als stdin... Aber genau
das passiert ja hier, weil screen das pty auf stdin legt.
> Wäre das mit Eingabeumleitung nicht wesentlich einfacher in den
> Griff zu bekommen?
Na, ja, "einfacher" ist manchmal Ansichtssache. So funktioniert es:
screen -d -m -S S1 bash -c 'cat > fifo' ;
screen -d -m -S S2 bash -c 'less < fifo'
In meinen Augen ist das allerdings unnötiges Gewürge. Aber ich
befürchte, dass man von der Shell aus kein controlling tty öffnen
kann. Irre ich mich da?