Hallo

Ich arbeite hier unter Linux (Cinnamon).

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 ?

Die Lösungen aus diesem Thread helfen hier nicht weiter:

https://stackoverflow.com/questions/6839508/test-if-stdin-has-input-for-c-windows-and-or-linux

--
Gruß, Greetings

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

wolfgang bauer (D) <schutz@gmx.de> schrieb:
>
> Hallo
>
> Ich arbeite hier unter Linux (Cinnamon).
>
> 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.

Prinzipiell ist es gute Praxis in C, sich die Rückgabewerte von
Eingabefunktionen anzuschauen und entsprechend zu reagieren,
wenn was nicht stimmt.

Andere Sprachen brechen bei missingender Eingabe mit Fehler ab,
aber die I/O - Funktionen von C schieben die ganze Verantwortung
auf dem Programmierer. Muss man nicht mögen, aber wenn man C
verwendet, sollte man sich drauf einstellen.

Eine Schleife in der From

/* Irgendwann muss der User doch mal was vernünftiges eingeben... */
while (scanf(...) == 0)
;

ist halt bei EOF oder einer Fehlerbedingung eine Endlosschleife.

> 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.

Sie geben dann 0 bzw NULL zurück.

> Frage: Wie kann ich feststellen, ob mein Programm mit oder ohne
> Konsole gestartet wurde ?

Innerhalb der C-Norm: Gar nicht. Innerhalb von POSIX: isatty().

Aber willst du tatsächlich, das das Programm nur interaktiv
funktioniert und z.B. nicht aus einer Datei oder von einer Pipe
gefüttert werden kann? Hat dein Anwendungsfall Besonderheiten,
die nur interaktive Ausführung interessant machen?

04.07.23 , 15:07 , Thomas Koenig:

>> Ich fand dann heraus, das es an einer Warteschleife liegt,
>> welche per fgets bzw. scanf auf eine Eingabe wartet.
>
> Prinzipiell ist es gute Praxis in C, sich die Rückgabewerte von
> Eingabefunktionen anzuschauen und entsprechend zu reagieren,
> wenn was nicht stimmt.

Ja. Manchmal ist man unbewusst zu faul. Aber nur manchmal ;-)

Die hier vorgeschlagene Methode per "isatty" erspart mir im vorliegenden Fall
weitere Anpassungen so das ich die Schleife lasse, wie sie ist. Ansonsten
muss ich mir wirklich angewöhnen, die Rückgabewerte zu beachten.

> Aber willst du tatsächlich, das das Programm nur interaktiv
> funktioniert und z.B. nicht aus einer Datei oder von einer Pipe
> gefüttert werden kann? Hat dein Anwendungsfall Besonderheiten,
> die nur interaktive Ausführung interessant machen?

Ja. Das ist hier Absicht. Das Programm holt sich zwar Daten aus Dateien,
aber es gehört hier zum Bedienkonzept, das es dann per Konsole gesteuert wird.

--
Gruß, Greetings

Am 04.07.2023 um 16:54 schrieb wolfgang bauer (D):
> 04.07.23 , 15:07 , Thomas Koenig:
>> Aber willst du tatsächlich, das das Programm nur interaktiv
>> funktioniert und z.B. nicht aus einer Datei oder von einer Pipe
>> gefüttert werden kann? Hat dein Anwendungsfall Besonderheiten,
>> die nur interaktive Ausführung interessant machen?
>
> Ja. Das ist hier Absicht. Das Programm holt sich zwar Daten aus Dateien,
> aber es gehört hier zum Bedienkonzept, das es dann per Konsole gesteuert wird.

Die Konsole kann auch abhandenkommen, z.B. /dev/ttyUSB0, wenn das
USB-Gerät abgezogen wird.

Für ein Wegwerf-Programm mag ein einmaliger Test im Voraus ausreichend
sein. Aber ansonsten kostet so ein Test wirklich nicht viel.

Das ist das gleiche Niveau wie Testen des Rückgabewertes von malloc. In
Wegwerfprogrammen mag es ok sein, das zu ignorieren, aber eigentlich
sollte man sich das von vornherein angewöhnen. Nichts hält länger als
ein Provisorium.

(Mein "mal eben eine serielle Schnittstelle und ein Rich-Text-Widget
zusammengeknotet" Programm von 2005 ist immer noch im Produktiveinsatz.)

Stefan

On 2023-07-04 14:54, wolfgang bauer (D) <schutz@gmx.de> wrote:
> 04.07.23 , 15:07 , Thomas Koenig:
>> Aber willst du tatsächlich, das das Programm nur interaktiv
>> funktioniert und z.B. nicht aus einer Datei oder von einer Pipe
>> gefüttert werden kann? Hat dein Anwendungsfall Besonderheiten,
>> die nur interaktive Ausführung interessant machen?
>
> Ja. Das ist hier Absicht. Das Programm holt sich zwar Daten aus
> Dateien, aber es gehört hier zum Bedienkonzept, das es dann per
> Konsole gesteuert wird.

In diesem Fall sollte EOF allerdings als Kommando zum Beenden des
Programms interpretiert werden.

hp

Stefan Reuther <stefan.news@arcor.de> schrieb:

> Das ist das gleiche Niveau wie Testen des Rückgabewertes von malloc. In
> Wegwerfprogrammen mag es ok sein, das zu ignorieren, aber eigentlich
> sollte man sich das von vornherein angewöhnen. Nichts hält länger als
> ein Provisorium.

In diesem Zusammenhang:

https://xkcd.com/2730/