Am 04.07.23 um 12:44 schrieb wolfgang bauer (D):

> Als ich einen Starter für eines meiner Programme (ein Konsolenprogramm) anlegte, vergaß ich, die
> Terminal-Option zu aktivieren.
>
> Nach Start erschien natürlich nichts, aber mein Programm lief "unsichtbar" und verbrauchte 100% CPU.
>
> Ich fand dann heraus, das es an einer Warteschleife liegt, welche per fgets bzw. scanf auf eine Eingabe wartet.
>
> Es scheint, das wenn das entspr. Programm NICHT mit einer Konsole gestartet wurde, diese Eingabefunktionen
> direkt zurückkehren und das Programm also in einer Endlosschleife festhängt.
>
> Frage: Wie kann ich feststellen, ob mein Programm mit oder ohne Konsole gestartet wurde ?

#include <unistd.h>
if( isatty( STDIN_FILENO )) /* ... */ ;

F'up2

MfG

04.07.23 , 13:48 , Markus Schaaf:

> #include <unistd.h>
> if( isatty( STDIN_FILENO )) /* ... */ ;

Danke ! Funktioniert. Genau das, was ich suchte.

--
Gruß, Greetings

Am 04.07.2023 um 13:48 schrieb Markus Schaaf:
> Am 04.07.23 um 12:44 schrieb wolfgang bauer (D):
>
>> Als ich einen Starter für eines meiner Programme (ein
>> Konsolenprogramm) anlegte, vergaß ich, die
>> Terminal-Option zu aktivieren.
>>
>> Nach Start erschien natürlich nichts, aber mein Programm lief
>> "unsichtbar" und verbrauchte 100% CPU.
>>
>> Ich fand dann heraus, das es an einer Warteschleife liegt, welche per
>> fgets bzw. scanf auf eine Eingabe wartet.
>>
>> Es scheint, das wenn das entspr. Programm NICHT mit einer Konsole
>> gestartet wurde, diese Eingabefunktionen
>> direkt zurückkehren und das Programm also in einer Endlosschleife
>> festhängt.
>>
>> Frage: Wie kann ich feststellen, ob mein Programm mit oder ohne
>> Konsole gestartet wurde ?
>
> #include <unistd.h>
> if( isatty( STDIN_FILENO )) /* ... */ ;

Wenn man jetzt ganz pedantisch ist könnte man ja noch als Konsolen
-Start annehmen wollen wenn von der Shell das Stdin redirected wurde.
Das wäre unterscheidbar wenn man den Parent-Prozess ermittelt und
schaut ob dessen Handles auf eine Konsole zeigen. Ich drück das mal
so umgangssprachlich aus, denn wie das unter Unix geht weiß ich nicht,
aber unter Windows wüsste ich das mit aufwendigen Mitteln.

Am 17.07.2023 um 18:46 schrieb Bonita Montero:
> Am 04.07.2023 um 13:48 schrieb Markus Schaaf:
>> Am 04.07.23 um 12:44 schrieb wolfgang bauer (D):
>>
>>> Als ich einen Starter für eines meiner Programme (ein
>>> Konsolenprogramm) anlegte, vergaß ich, die
>>> Terminal-Option zu aktivieren.
>>>
>>> Nach Start erschien natürlich nichts, aber mein Programm lief
>>> "unsichtbar" und verbrauchte 100% CPU.
>>>
>>> Ich fand dann heraus, das es an einer Warteschleife liegt, welche per
>>> fgets bzw. scanf auf eine Eingabe wartet.
>>>
>>> Es scheint, das wenn das entspr. Programm NICHT mit einer Konsole
>>> gestartet wurde, diese Eingabefunktionen
>>> direkt zurückkehren und das Programm also in einer Endlosschleife
>>> festhängt.
>>>
>>> Frage: Wie kann ich feststellen, ob mein Programm mit oder ohne
>>> Konsole gestartet wurde ?
>>
>> #include <unistd.h>
>> if( isatty( STDIN_FILENO )) /* ... */ ;
>
> Wenn man jetzt ganz pedantisch ist könnte man ja noch als Konsolen
> -Start annehmen wollen wenn von der Shell das Stdin redirected wurde.
> Das wäre unterscheidbar wenn man den Parent-Prozess ermittelt und
> schaut ob dessen Handles auf eine Konsole zeigen. Ich drück das mal
> so umgangssprachlich aus, denn wie das unter Unix geht weiß ich nicht,
> aber unter Windows wüsste ich das mit aufwendigen Mitteln.

Ich hab neulich ein "time ..." auf einen Prozess gehabt den ich
redirected hat. Interessanterweise wurde nur der Output des Programms
redirected, aber nicht das "time ..." selbst. Wie funktioniert denn
sowas programmiertechnisch ?
Unter Windows würd ich einfach den Parent-Prozess ermitteln und mir
das Konsolen-Handle von dem holen. Unter Linux - keine Ahnung.

On 2023-08-22, Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Ich hab neulich ein "time ..." auf einen Prozess gehabt den ich
> redirected hat. Interessanterweise wurde nur der Output des Programms
> redirected, aber nicht das "time ..." selbst. Wie funktioniert denn
> sowas programmiertechnisch ?

Wahrscheinlich hast du nur stdout umgelenkt; time schreibt aber auf
stderr.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

Am 22.08.2023 um 16:35 schrieb Christian Weisgerber:
> On 2023-08-22, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
>> Ich hab neulich ein "time ..." auf einen Prozess gehabt den ich
>> redirected hat. Interessanterweise wurde nur der Output des Programms
>> redirected, aber nicht das "time ..." selbst. Wie funktioniert denn
>> sowas programmiertechnisch ?
>
> Wahrscheinlich hast du nur stdout umgelenkt; time schreibt aber auf
> stderr.

Interessant bzw. konnte ich auch jetzt so recherchieren.

* Christian Weisgerber:

> On 2023-08-22, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
>> Ich hab neulich ein "time ..." auf einen Prozess gehabt den ich
>> redirected hat. Interessanterweise wurde nur der Output des Programms
>> redirected, aber nicht das "time ..." selbst. Wie funktioniert denn
>> sowas programmiertechnisch ?
>
> Wahrscheinlich hast du nur stdout umgelenkt; time schreibt aber auf
> stderr.

Manche Programme öffnen auch /dev/tty, z.B. um Paßwörter einzulesen.
Das gewöhnliche time-Programm und das Shell-Kommando dürften aber bloß
auf stderr schreiben.

Am 29.08.2023 um 23:02 schrieb Florian Weimer:

> Manche Programme öffnen auch /dev/tty, z.B. um Paßwörter einzulesen.

Man kann auch einfach line-buffering und echoing von stdin abschalten.

* Bonita Montero:

> Am 29.08.2023 um 23:02 schrieb Florian Weimer:
>
>> Manche Programme öffnen auch /dev/tty, z.B. um Paßwörter einzulesen.
>
> Man kann auch einfach line-buffering und echoing von stdin abschalten.

Das funktioniert für less z.B. nicht, weil das andere Programm immer
noch von der Standardeingabe liest.

Am 30.08.2023 um 07:48 schrieb Florian Weimer:

> Das funktioniert für less z.B. nicht, weil das andere Programm immer
> noch von der Standardeingabe liest.

Man kann auch wie bereits beschrieben feststellen ob stdin
wirklich an einer Konsole hängt und das fallweise unterscheiden.

Florian Weimer <fw@deneb.enyo.de>:
> * Bonita Montero:
>
>> Am 29.08.2023 um 23:02 schrieb Florian Weimer:
>>
>>> Manche Programme öffnen auch /dev/tty, z.B. um Paßwörter
>>> einzulesen.
>>>
>>
>> Man kann auch einfach line-buffering und echoing von stdin
>> abschalten.
>>
>
> Das funktioniert für less z.B. nicht,
>

Das ist richtig, aber das folgende ist nicht der Grund dafür.

> weil das andere Programm immer noch von der Standardeingabe
> liest.
>

Der Grund dafür, dass „less“ das „/dev/tty“ öffnet, ist, dass es
im Fall, dass es ein „anderes Programm“ wie beispielsweise im
folgenden Shell‐Kommando

das_andere_Programm spuckt Ausgaben | less

gibt, als Standardeingabe nicht mehr das Terminal hat sondern die
Ausgabeseite des Pipes.  Möchte „less“ also vom Terminal seine
Steuerkommandos lesen, muss es sich das Terminal selber öffnen.

Eine andere Möglichkeit für „less“ wäre gewesen, ihm die Option
„--command-fd“ zu implementieren.  Dann könnte man es so
aufrufen:

{
das_andere_Programm spuckt Ausgaben 3<&- |
less --command-fd 3
} 3<&0

Wenn „das andere Programm“ auch noch vom Terminal liest, gibt es
natürlich Chaos.  Das kann aber weder dadurch behoben
werden, dass „less“ sich das Terminal noch mal selber öffnet,
noch dadurch, dass „less“ die Option „--command-fd“ hätte.

In einer Umgebung, in der ich mehrere (Pseudo‐)Terminals habe,
also beispielsweise in einer X11‐Umgebung mit „xterm“, kann ich
mir so helfen:

das_andere_Programm spuckt Ausgaben |
xterm -e sh -c -- 'exec 0<&3 3<&- && "$@"' sh less 3<&0

Zunächst eine kurze Erklärung zum Shell‐Kommando:  Die
Eingabeumlenkung „3<&0“ am Ende der Kommandozeile bewirkt, dass
die Ausgabeseite des pipes nicht nur über file descriptor Nummer
0 sondern ebensogut über file descriptor Nummer 3 ausgelesen
werden kann.  Das „xterm“, wenn es dann das gewünschte Programm,
hier: das Shell („sh -c -- …“) startet, reicht an das Shell nicht
seine eigene Standardeingabe weiter, sondern erzeugt ein neues
(Pseudo‐)Terminal und gibt dem Shell als Standardeingabe einen
Zugriff auf das neue Terminal mit.  Weil die alte Standardeingabe
aber auch noch über file descriptor Nummer 3 lesbar ist, kann das
Shell mittels „exec 0<& 3<&-“ seine Standardeingabe auf die alte
dem „xterm“ übergebene Standardeingabe zurückstellen und das so
an das „less“ weitergeben.

Das Kommando bewirkt, dass „less“ in einem eigenen „xterm“ läuft
und deshalb nicht versucht, vom selben Terminal wie
„das_andere_Programm“ zu lesen.  Ja, die Entwickler des guten
alten „xterm“s haben sich nicht erdreistet[1], einfach alle file
descriptors zu schließen, sondern sind konservativ vorgegangen: 
File descriptors, die das „xterm“ offen vorfindet, tastet es
nicht an, sondern lässt sie, wie sie sind.  Und das ist auch gut
so.

So kümmert sich das „xterm“ im angeführten Beispiel nicht darum,
dass file descriptor Nummer 3 zum Lesen geöffnet ist und schließt
es etwa, sondern lässt es einfach unangetastet offen und
reicht es dadurch ganz automatisch an das von ihm gestartete
Shell weiter.  Lust, das mal konkret auszuprobieren?  Dann nimm
dieses Beispiel:

cat |
xterm -e sh -c -- 'exec 0<&3 3<&- && "$@"' sh less 3<&0

Da läuft ein „cat“ mit Standardeingabe vom Terminal:  Man kann
also Text eintippen, der von „cat“ gelesen und ans „xterm“
weitergereicht wird.  Im „xterm“ läuft ein Shell, das zuerst eine
Eingabeumlenkung von file descriptor Nummer 0 auf Nummer 3 macht
und Nummer 3 schließt.  Dadurch kommen die Daten bei „less“ wie
gewohnt beim file descriptor Nummer 0 an.

[1] Vor Jahren habe ich dasselbe mal mit einem Gnome‐Terminal
versucht und bin gescheitert, weil die Entwickler des
Gnome‐Terminals der Meinung waren, das Gnome‐Terminal müsste beim
Start erst mal nach allen offenen file descriptors fahnden und
diese dann schließen.