Discussion:
Befehl mit & hinten und Terminal beenden stört manche Prozesse
(zu alt für eine Antwort)
Tim Landscheidt
2024-02-20 12:40:04 UTC
Permalink
Ich starte viele Programme mit Befehl & im xterm und beende dann das
xterm mit Ctrl+D. Bei aisleriot hat das den Effekt, dass in vielen
Fällen das Programm abstürzt. Lässt man das Terminal offen kommt eine
Meldung, die aber den Ablauf nicht stört.
Ist dieses Verhalten so beabsichtigt?
Ich meine mich dunkel an eine GNU-Software erinnern zu kön-
nen, die in ihrer Testsuite unter anderem prüfte, dass das
Programm auch tatsächlich nicht auf stdin/stdout(/stderr?)
zugriff. Wenn aisleriot darauf zugreift, muss man halt von/
nach /dev/null umleiten.

Tim
Thomas Kempkes
2024-02-20 12:48:07 UTC
Permalink
Hallo zusammen!
Ich starte viele Programme mit Befehl & im xterm und beende dann das
xterm mit Ctrl+D. Bei aisleriot hat das den Effekt, dass in vielen
Fällen das Programm abstürzt. Lässt man das Terminal offen kommt eine
Meldung, die aber den Ablauf nicht stört.
Ist dieses Verhalten so beabsichtigt?
Ich bezweifele, dass dieses Verhalten auf dem expliziten Wunsch basiert
in diesem Fall die Programme hart abstürzen zu lassen - so wie die
Interaktion der Programme mit dem aufrufenden Programm funktioniert
wirst du mit diesem Verhalten klarkommen müssen, da wird sich in
absehbarer Zeit nichts ändern.
Mit den Stichworten "nohup" und "screen" kannst du aber "drumherum"
arbeiten und am Ende wahrscheinlich das erreichen was dir vorschwebt?

BYe Thomas
--
Yes, I've heard of "decaf." What's your point?
Helmut Waitzmann
2024-02-22 19:16:36 UTC
Permalink
Ist denn die Vorgehensweise, Programme aus dem xterm zu starten
und dieses zu beenden überhaupt sinnvoll?
Wenn sichergestellt ist, dass das Programm sein Terminal nicht
braucht, spricht nichts dagegen.  Ich würde das Programm dann
trotzdem mit umgeleiteter Standard‐Eingabe und Standard‐ und
Fehler‐Ausgabe, beispielsweise von und zu „/dev/null“, starten.


Als POSIX‐Shell‐Kommandozeile:


( Programm < /dev/null > /dev/null 2>&1 & ) && exit
Marco Moock
2024-02-22 19:42:17 UTC
Permalink
Post by Helmut Waitzmann
Wenn sichergestellt ist, dass das Programm sein Terminal nicht
braucht, spricht nichts dagegen.  Ich würde das Programm dann
trotzdem mit umgeleiteter Standard‐Eingabe und Standard‐ und
Fehler‐Ausgabe, beispielsweise von und zu „/dev/null“, starten.
Wie machen das dann die ganzen "Starter", wie z.B: das Fenster, was
sich bei LXDE mit Alt+F2/Win+R öffnet?

Das würde ich hier gerne auch machen.
--
Gruß
Marco

Spam und Werbung bitte an ***@cartoonies.org
Helmut Waitzmann
2024-02-22 21:34:37 UTC
Permalink
Post by Marco Moock
Post by Helmut Waitzmann
Wenn sichergestellt ist, dass das Programm sein Terminal nicht
braucht, spricht nichts dagegen.  Ich würde das Programm dann
trotzdem mit umgeleiteter Standard‐Eingabe und Standard‐ und
Fehler‐Ausgabe, beispielsweise von und zu „/dev/null“, starten.
Wie machen das dann die ganzen "Starter", wie z.B: das Fenster,
was sich bei LXDE mit Alt+F2/Win+R öffnet?
Keine Ahnung.  Ich vermute, dass sie die Standardeingabe an
„/dev/null“ anschließen und die Standard‐ und die Fehlerausgabe
vielleicht an eine Log‐Datei oder einen Log‐Dienst (das wäre dann
vielleicht ein FIFO oder ein socket).


Jedenfalls gibt es meines Wissens die Konvention, dass jedes
Programm davon ausgehen darf, dass es beim Start die
Standardeingabe und die Standard‐ und die Fehlerausgabe geöffnet
vorfindet.  Davon würde ich nicht ohne Not abweichen.
Post by Marco Moock
Das würde ich hier gerne auch machen.
Ich verwende in der Tat gerne ein interaktives Shell in einem
„xterm“ als Starter.  Da kann ich gestartete Programme auch
leicht abschießen, sollte das nötig sein.  Da kann ich Programme
mit einem anderen „nice“‐Wert oder in einem anderen
Arbeitsverzeichnis starten: Flexibilität, die mir ein grafischer
Starter nicht bietet.
Thomas Dorner
2024-02-23 17:36:42 UTC
Permalink
Post by Marco Moock
Post by Helmut Waitzmann
Wenn sichergestellt ist, dass das Programm sein Terminal nicht
braucht, spricht nichts dagegen.  Ich würde das Programm dann
trotzdem mit umgeleiteter Standard‐Eingabe und Standard‐ und
Fehler‐Ausgabe, beispielsweise von und zu „/dev/null“, starten.
Wie machen das dann die ganzen "Starter", wie z.B: das Fenster, was
sich bei LXDE mit Alt+F2/Win+R öffnet?
Die machen in der Regel¹ gar nichts, sondern erben die Ausgabe des
Desktops, schreiben also in dessen Log-Datei.

¹ Ich habe hier in /usr/share/applications genau 1 von über 200 Desktop
Dateien, deren "Exec=" eine Ausgabeumleitung (nach /dev/null) vornimmt.

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!
Lutz Falke
2024-02-23 22:14:51 UTC
Permalink
Post by Thomas Dorner
Post by Marco Moock
Post by Helmut Waitzmann
Wenn sichergestellt ist, dass das Programm sein Terminal nicht
braucht, spricht nichts dagegen.  Ich würde das Programm dann
trotzdem mit umgeleiteter Standard‐Eingabe und Standard‐ und
Fehler‐Ausgabe, beispielsweise von und zu „/dev/null“, starten.
Wie machen das dann die ganzen "Starter", wie z.B: das Fenster, was
sich bei LXDE mit Alt+F2/Win+R öffnet?
Die machen in der Regel¹ gar nichts, sondern erben die Ausgabe des
Desktops, schreiben also in dessen Log-Datei.
Genau, das wird bei der Erzeugung der Session erledigt. Die
"/etc/X11/Xsession" hier enthält die Zeile:

exec >>"$ERRFILE" 2>&1

Musste ich auch erst nachlesen. Ein "exec" ohne Parameter ersetzt
nicht den Prozess sondern bewirkt nur eine Ein-/Ausgabeumleitung
innerhalb der laufenden Shell. Der Desktop und dessen Kinder (die über
die "Starter" gestartet werden) erben das dann.

$ERRFILE ist typischerweise auf "~/.xsession-errors" gesetzt.

Lutz
Sieghard Schicktanz
2024-02-23 21:05:46 UTC
Permalink
Hallo Marco,
Post by Marco Moock
Wie machen das dann die ganzen "Starter", wie z.B: das Fenster, was
sich bei LXDE mit Alt+F2/Win+R öffnet?
Höchstwahrscheinlich so, daß sie "stdin", "stdout" und "stderr" nach Start
zumachen, zusehen, daß sie die nicht mehr brauchen und allfällige Ausgaben
in ein Log-File schieben. Die Grafik-Anzeige ist ja ein davon völlig
unabhängiger Kanal.
(Ich hatte mal so ein Problem mit einem Python-Programm, das partout
"stdout"/"stderr" nicht zmachen wollte - da hat dann die Umleitung nach
"/dev/null" helfen müssen. Eingabe von "stdin" war ja im Zugriff des
Programms selber, das war vermeidbar, trotzdem bestand Python auf einem
_echten_ Eingabekanal - ich habe ihr dann eine unbenutzte virtuelle Konsole
vorgeworfen. "/dev/zero" hat sie [auch] nicht akzeptiert...)
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Sieghard Schicktanz
2024-02-23 20:58:34 UTC
Permalink
Hallo Helmut,
Post by Helmut Waitzmann
( Programm < /dev/null > /dev/null 2>&1 & ) && exit
$ cat < /dev/null > unsinn &

$ ls -l unsinn
-rw-r--r-- 1 hardi 0 Feb 23 21:55 unsinn
[1]+ Done cat < /dev/null > unsinn

Hmmm. Funktioniert "nicht ganz" wie erwartet?
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Lutz Falke
2024-02-23 22:04:51 UTC
Permalink
Post by Sieghard Schicktanz
Hallo Helmut,
Post by Helmut Waitzmann
( Programm < /dev/null > /dev/null 2>&1 & ) && exit
$ cat < /dev/null > unsinn &
$ ls -l unsinn
-rw-r--r-- 1 hardi 0 Feb 23 21:55 unsinn
^
Was ist denn das für ein komisches "ls"? Da fehlt entweder der
Besitzer oder die Gruppe.
Post by Sieghard Schicktanz
[1]+ Done cat < /dev/null > unsinn
Hmmm. Funktioniert "nicht ganz" wie erwartet?
Was soll da nicht wie erwartet funktioneren? Das tut genau was es
soll.

Die Aufgabe von "cat" ist es nunmal, von STDIN zu lesen. Da es von
/dev/null nichts zu lesen gibt, fängt es sich direkt beim ersten
Versuch ein end-of-file ein und beendet sich. Die Datei "unsinn"
erzeugt die Shell bevor sie den Prozess für "cat" erzeugt. Es ist
ganz normal, dass die Datei dann nach dieser Aktion eine Größe von 0
Bytes hat.

Ein Programm, was tatsächlich etwas von der Standardeingabe lesen
will, funktioniert in so einer Umgebung natürlich nicht sinnvoll.

Lutz
Sieghard Schicktanz
2024-02-24 19:13:01 UTC
Permalink
Hallo Lutz,
Post by Lutz Falke
Was ist denn das für ein komisches "ls"?
Mein verbogenes.
Post by Lutz Falke
Post by Sieghard Schicktanz
[1]+ Done cat < /dev/null > unsinn
Hmmm. Funktioniert "nicht ganz" wie erwartet?
Was soll da nicht wie erwartet funktioneren? Das tut genau was es
soll.
Ja, aber wohl nicht das, was im Thread angesproche n wurde, nämlich zur
"Befriedigung" von Eingabeanforderung eines Programms zu sorgen, das nicht
ohne "stdin" laufen will.
...
Post by Lutz Falke
Ein Programm, was tatsächlich etwas von der Standardeingabe lesen
will, funktioniert in so einer Umgebung natürlich nicht sinnvoll.
Vor allem dann nicht, wenn es ohne Eingangsdaten garnichts mehr tun will
oder sich (z.B. bei EoF) gleich beendet.
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Helmut Waitzmann
2024-02-24 20:49:51 UTC
Permalink
Post by Sieghard Schicktanz
Hallo Lutz,
Post by Lutz Falke
Was soll da nicht wie erwartet funktioneren? Das tut genau was
es soll.
Ja, aber wohl nicht das, was im Thread angesproche n wurde,
nämlich zur "Befriedigung" von Eingabeanforderung eines
Programms zu sorgen, das nicht ohne "stdin" laufen will. ...
Eher nicht.  Ein Programm, was tatsächlich Daten in der
Standardeingabe angeliefert haben will, kann man nicht dadurch
befriedigen, dass man ihm als Standardeingabe einen Anschluss auf
„/dev/null“ oder „/dev/zero“ gibt.  Aber das ist auch nicht
unbedingt der Sinn einer Umleitung der Standardeingabe auf
„/dev/null“.  Der Sinn ist vielmehr eine Vorsichtsmaßnahme, die
den im folgenden beschriebenen Angriffsvektor verhindert:


Wenn ein Programm P keine Daten aus der Standardeingabe lesen
will, sondern statt dessen seine Datenquelle Q selber öffnet,
kann es passieren, wenn die Standardeingabe beim Programmstart
geschlossen ist, dass die selbstgeöffnete Datenquelle als file
descriptor die Nummer 0, also die üblicherweise für die
Standardeingabe verwendete Nummer, erhält.  Wenn sich das
Programm P nun zur Erledigung seiner Aufgabe anderer
Dienstprogramme bedient (so etwas kommt beispielsweise in
Shell‐Skripten häufig vor), erhalten diese anderen
Dienstprogramme – sofern bei der Entwicklung des Programms P
nicht daran gedacht wurde, vor dem Start der Dienstprogramme die
Standardeingabe von der Datenquelle Q zu trennen – möglicherweise
als Standardeingabe versehentlich die Datenquelle Q, obwohl sie
im Fehlerfall aus ihrer Standardeingabe eine bestätigende Antwort
des Anwenders (beispielsweise „Remove file (y/n)?“) erwarten. 
Das hat zur Folge, dass sie erstens möglicherweise Unsinn machen
und zweitens jedenfalls dem Programm P Daten aus dessen aus der
Datenquelle Q gespeisten Datenstrom „weglesen“.


Deshalb bricht man die Konvention, dass ein Programm beim Start
davon ausgehen darf, dass es die Standardeingabe, Standardausgabe
und Fehlerausgabe geöffnet vorfindet, nicht ohne Not:  Will man
dem Programm in der Tat keine Daten über die Standardeingabe
liefern, ruft man es mit auf „/dev/null“ umgelenkter
Standardeingabe, nicht mit geschlossener Standardeingabe, auf.
Stefan Wiens
2024-02-29 00:42:48 UTC
Permalink
Helmut Waitzmann <***@xoxy.net> writes:

[...]
Deshalb bricht man die Konvention, dass ein Programm beim Start davon
ausgehen darf, dass es die Standardeingabe, Standardausgabe und
Fehlerausgabe geöffnet vorfindet, nicht ohne Not:  Will man dem
Programm in der Tat keine Daten über die Standardeingabe liefern, ruft
man es mit auf „/dev/null“ umgelenkter Standardeingabe, nicht mit
geschlossener Standardeingabe, auf.
,----[ <https://pubs.opengroup.org/onlinepubs/9699919799/functions/execve.html> ]
|
| If a standard utility or a conforming application is executed with
| file descriptor 0 not open for reading or with file descriptor 1 or 2
| not open for writing, the environment in which the utility or
| application is executed shall be deemed non-conforming, and
| consequently the utility or application might not behave as described
| in this standard.
| [...]
| Applications should not execute programs with file descriptor 0 not
| open for reading or with file descriptor 1 or 2 not open for writing,
| as this might cause the executed program to misbehave. In order not to
| pass on these file descriptors to an executed program, applications
| should not just close them but should reopen them on, for example,
| /dev/null. Some implementations may reopen them automatically, but
| applications should not rely on this being done.
`----
--
Stefan
Lutz Falke
2024-03-09 22:09:00 UTC
Permalink
Post by Sieghard Schicktanz
Hallo Lutz,
Post by Lutz Falke
Was ist denn das für ein komisches "ls"?
Mein verbogenes.
Ah. Ich habe heute zufällig die ls-Option "-o" in der Manpage
entdeckt. Sachen gibts. ;)
Post by Sieghard Schicktanz
Post by Lutz Falke
Post by Sieghard Schicktanz
[1]+ Done cat < /dev/null > unsinn
Hmmm. Funktioniert "nicht ganz" wie erwartet?
Was soll da nicht wie erwartet funktioneren? Das tut genau was es
soll.
Ja, aber wohl nicht das, was im Thread angesproche n wurde, nämlich zur
"Befriedigung" von Eingabeanforderung eines Programms zu sorgen, das nicht
ohne "stdin" laufen will.
Wenn du das willst, kannst du das Programm auch einfach in einen
"screen" stecken. Den kann man auch gleich abgekoppelt starten:

$ screen -d -m programm

Das funktioniert dann auch für Programme, die ein Terminal als
stdin/-out erwarten.

Lutz

Christian Garbs
2024-02-22 20:47:47 UTC
Permalink
Mahlzeit!
Post by Thomas Kempkes
Mit den Stichworten "nohup" und "screen" kannst du aber "drumherum"
arbeiten und am Ende wahrscheinlich das erreichen was dir vorschwebt?
Der Absturz (Schema-Ausnahmefehler) findet beim Spiel statt, es startet
dann ein neues Spiel. Das war von mir nicht klar formuliert.
Der Fehler ist vom Zeitpunkt unabhängig von Ctrl+D.
nohup verhindert den.
Ist denn die Vorgehensweise, Programme aus dem xterm zu starten und
dieses zu beenden überhaupt sinnvoll?
Für ein normales X11-Programm sollte das eigentlich kein Problem
darstellen. emacs, firefox, inkscape, gimp, andere xterms – all das
lässt sich ohne Verrenkungen aus einem xterm starten und wenn ich das
xterm zumache, laufen die Programme klaglos weiter. Selbst wine, das
ja meist viel auf stdout/stderr loggt, kommt damit klar, wenn man ihm
die mitten im Betrieb klaut.

Wenn aisleriot das nicht überlebt, scheint es nicht besonders robust
programmiert zu sein. Inhaltlich zwingend notwendig dürfte es für ein
grafisches Kartenspiel eher nicht zu sein, dass es auf stdout loggen
können muss.

Wäre einen Bugreport wert, denke ich.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Beaumarchais muss den deutschen Schlager vorausgeahnt
haben, als er sagte:
"Was zu dumm ist, gesagt zu werden, wird gesungen."
Christian Garbs
2024-03-07 18:50:08 UTC
Permalink
Mahlzeit!
Post by Christian Garbs
Wenn aisleriot das nicht überlebt, scheint es nicht besonders robust
programmiert zu sein. Inhaltlich zwingend notwendig dürfte es für ein
grafisches Kartenspiel eher nicht zu sein, dass es auf stdout loggen
können muss.
Einmal im Monat gestartet und prompt hat es sich hier reingedrängelt:
Der Discord-Client ist genauso ein Kandidat. Wenn man dem nach dem
Starten sein Terminal klaut, dann öffnet er ein Popup-Fenster mit
einem Java-Stacktrace und sobald man den wegklickt, kommt der nächste.

Das ganze Ding lässt sich dann nur noch über (x)kill abschießen,
bedienbar ist es nicht mehr.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Ich habe eine Berufsuntätigkeitsversicherung. (Kalle)
Stefan+ (Stefan Froehlich)
2024-03-09 08:13:03 UTC
Permalink
Post by Christian Garbs
Ist denn die Vorgehensweise, Programme aus dem xterm zu starten
und dieses zu beenden überhaupt sinnvoll?
Why not? Mit Ausnahme von xterms starte ich eigentlich alle
Programme aus xterms heraus.
Post by Christian Garbs
Für ein normales X11-Programm sollte das eigentlich kein Problem
darstellen. emacs, firefox, inkscape, gimp, andere xterms – all
das lässt sich ohne Verrenkungen aus einem xterm starten und wenn
ich das xterm zumache, laufen die Programme klaglos weiter.
Firefox (wenigstens bei mir) interessanterweise erst dann, sobald er
irgendetwas nach stdout (oder stderr, ich hab's nie nachgeprüft)
geschrieben hat. Beende ich das xterm davor, beendet sich auch der
Firefox noch bevor das erste Fenster geöffnet wird.

Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Der gieraffige Nachbar nimmt Stefan. Und Sie?
(Sloganizer)
Ralph Aichinger
2024-03-09 08:26:07 UTC
Permalink
Post by Stefan+ (Stefan Froehlich)
Why not? Mit Ausnahme von xterms starte ich eigentlich alle
Programme aus xterms heraus.
Ich mach das normalerwesie nicht, eben gerade weil ich dann ein xterm
(oder in meinem Fall eine "Console" von Gnome) rumliegen hab, und wenn
ich das Fenster versehentlich zumache auch indirekt gestartete Programme
sterben.

Drum versuche ich für alle Programme die nicht reine
commandline-Programme sind einen Starter im Desktop hinzuzufügen, und
Programme bei denen das schwierig ist (ich glaub die
Arduino-Progrmamierumgebung war der letzte Fall bei mir) nervt mich das.

/ralph
Stefan+ (Stefan Froehlich)
2024-03-09 13:32:04 UTC
Permalink
Post by Ralph Aichinger
Post by Stefan+ (Stefan Froehlich)
Why not? Mit Ausnahme von xterms starte ich eigentlich alle
Programme aus xterms heraus.
Ich mach das normalerwesie nicht, eben gerade weil ich dann ein
xterm (oder in meinem Fall eine "Console" von Gnome) rumliegen
hab, und wenn ich das Fenster versehentlich zumache auch indirekt
gestartete Programme sterben.
Verständlich; andererseits benötige ich kaum GUI-Programme. Browser
sind permanent offen, gelegentlich ein LibreOffice oder Gimp für ein
paar Stunden - ansonsten gerade einmal PDF- oder Imageviewer für
wenige Minuten, und daher auch nicht versehentlich terminierbar.
Post by Ralph Aichinger
Drum versuche ich für alle Programme die nicht reine
commandline-Programme sind einen Starter im Desktop hinzuzufügen,
und Programme bei denen das schwierig ist (ich glaub die
Arduino-Progrmamierumgebung war der letzte Fall bei mir) nervt
mich das.
Ursprünglich hatte ich auch damit begonnen, ein entsprechendes
fvwm-Menü zu bestücken, aber letztendlich werden davon nur die
diversen xterms (für jeden Zielhost ein Eintrag) wirklich bedient.
Der ganze Rest ist so selten in Benutzung, dass sich das nicht
lohnt.

Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Für den sympathischen Halunken von Welt - werben mit Stefan!
(Sloganizer)
Enrik Berkhan
2024-02-20 12:33:11 UTC
Permalink
Ich starte viele Programme mit Befehl & im xterm und beende dann das
xterm mit Ctrl+D. Bei aisleriot hat das den Effekt, dass in vielen
Fällen das Programm abstürzt. Lässt man das Terminal offen kommt eine
Meldung, die aber den Ablauf nicht stört.
Ist dieses Verhalten so beabsichtigt?
Passiert das auch, wenn du das verdächtige Programm mittels `nohup'
startest?

Zum Debuggen könntest du es noch mit `strace' starten (Ausgabe natürlich
in Datei schreiben lassen etc.) oder einen Debugger aus einem anderen
xterm heraus starten und an den jeweiligen Prozess attachen, bevor du
das originale xterm schließt.

Gruß,
Enrik
Helmut Waitzmann
2024-02-22 18:49:17 UTC
Permalink
Hallo zusammen!
Ich starte viele Programme mit Befehl & im xterm und beende dann
das xterm mit Ctrl+D. Bei aisleriot hat das den Effekt, dass in
vielen Fällen das Programm abstürzt. Lässt man das Terminal
offen kommt eine Meldung, die aber den Ablauf nicht stört.
Ist dieses Verhalten so beabsichtigt?
Das Verhalten ist zwangsläufig:  Wenn „aisleriot“ versucht, auf
sein Terminal (hier: vom „xterm“ bereitgestelltes pseudo
terminal) zu schreiben, scheitert es dabei, wenn es das Terminal
nicht mehr gibt (hier:  Wenn das „xterm“ sich beendet, schließt
es auch das von Betriebssystem bereitgestellte pseudo terminal). 
Was „aisleriot“ in diesem Fall unternimmt, hängt davon ab, wie es
programmiert ist.


Offensichtlich ist es nicht sinnvoll, „aisleriot“ so zu
betreiben:  Schließlich will es ab und zu Meldungen ausgeben
können.


Wenn du partout kein (pseudo) terminal verwenden willst, um
„aisleriot“ zu betreiben, empfiehlt es sich, ihm andere
Möglichkeiten zu geben, die Meldungen auszugeben: indem du es so
startest, dass seine Standard‐ und Fehler‐Ausgabekanäle woanders
hinführen, beispielsweise in eine Datei, in ein FIFO oder ein
anderes Gerät.
Loading...