Discussion:
lesen von stdin endet in einer Endlosschleife ....
(zu alt für eine Antwort)
Walter H.
2015-10-08 13:40:53 UTC
Permalink
Raw Message
Hallo,

folgendes Code-Snippet läuft in eine Endlosschleife, nur warum?

char* psz = szBuf; /* szBuf ist ein hinreichend */
/* großer statischer Buffer */
int nLen;

while ( ( nLen = read( 0, psz, 256 ) ) > 0 )
{
psz += nLen;
*psz = '\0';
}

Grüße,
Walter
Thomas Richter
2015-10-08 13:54:42 UTC
Permalink
Raw Message
Post by Walter H.
Hallo,
folgendes Code-Snippet läuft in eine Endlosschleife, nur warum?
Nicht endlos, nur eben bis zum Auftreten eines Fehlers. Ein EOF ist kein
Fehler. read() liefert eben nur die Anzahl der gelesenen Zeichen zurück,
und das sind eben weniger als 256, speziell eben auch 0.
Walter H.
2015-10-08 16:42:36 UTC
Permalink
Raw Message
Post by Thomas Richter
Post by Walter H.
Hallo,
folgendes Code-Snippet läuft in eine Endlosschleife, nur warum?
Nicht endlos, nur eben bis zum Auftreten eines Fehlers. Ein EOF ist kein
Fehler. read() liefert eben nur die Anzahl der gelesenen Zeichen zurück,
und das sind eben weniger als 256, speziell eben auch 0.
sollte die Schleife denn bei Rückgabe von 0 nicht abbrechen?

while ( ( nLen = read( 0, psz, 256 ) ) > 0 )
Heinz Saathoff
2015-10-08 14:00:21 UTC
Permalink
Raw Message
Post by Walter H.
folgendes Code-Snippet läuft in eine Endlosschleife, nur warum?
char* psz = szBuf; /* szBuf ist ein hinreichend */
/* großer statischer Buffer */
int nLen;
while ( ( nLen = read( 0, psz, 256 ) ) > 0 )
{
psz += nLen;
*psz = '\0';
}
Die Endlosschleife kommt daher, dass read vom stdin-handle
keine 0 byte liest, weil read
blockiert und auf Zeichen wartet
Zeichen zurückgibt und damit return > 0 ist

Bei End Of File sollte read unter Unix allerdings 0 zurüggenben. Bei
Terminaleingaben müsste das EOF mit spezieller Tastenkombination
erzeugbar sein.


- Heinz
Claus Reibenstein
2015-10-08 14:10:16 UTC
Permalink
Raw Message
Post by Walter H.
folgendes Code-Snippet läuft in eine Endlosschleife, nur warum?
char* psz = szBuf; /* szBuf ist ein hinreichend */
/* großer statischer Buffer */
Wie groß ist denn "hinreichend groß"?
Post by Walter H.
int nLen;
while ( ( nLen = read( 0, psz, 256 ) ) > 0 )
{
psz += nLen;
*psz = '\0';
}
read() ist kein ANSI-C, sondern eine POSIX-Funktion.

read() liefert 0 bei EOF. Du musst also auf Deiner Tastatur die
entsprechende Tastenkombination drücken (hängt vom Betriebssystem ab).
Dann hört die Schleife auch auf zu laufen.

Im Übrigen finde ich es ganz schön mutig, sich blind darauf zu
verlassen, dass der statische Buffer hinreichend groß genug sei.
Zugegebenermaßen wird man einen mehrere GB großen Buffer kaum per
Tastatur vollbekommen. Aber man braucht ja nur mal die Eingabe auf eine
hinreichend große Datei umzulenken, und schon ist Dein Buffer nicht mehr
hinreichend groß.

Gruß
Claus
Walter H.
2015-10-08 16:51:51 UTC
Permalink
Raw Message
Post by Claus Reibenstein
Post by Walter H.
folgendes Code-Snippet läuft in eine Endlosschleife, nur warum?
char* psz = szBuf; /* szBuf ist ein hinreichend */
/* großer statischer Buffer */
Wie groß ist denn "hinreichend groß"?
ein vielfaches dessen, was maximal kommen kann ...
Post by Claus Reibenstein
Post by Walter H.
int nLen;
while ( ( nLen = read( 0, psz, 256 ) )> 0 )
{
psz += nLen;
*psz = '\0';
}
read() ist kein ANSI-C, sondern eine POSIX-Funktion.
soll mir recht sein; diese Code-Snippet entstammt eines Helper-Programms
unter Linux ...
Post by Claus Reibenstein
read() liefert 0 bei EOF. Du musst also auf Deiner Tastatur die
entsprechende Tastenkombination drücken (hängt vom Betriebssystem ab).
Dann hört die Schleife auch auf zu laufen.
genau das dachte ich ja, dass bei EOF der Wert 0 geliefert wird,
aber anscheinend kommt der Wert 0 nie ...
Post by Claus Reibenstein
Im Übrigen finde ich es ganz schön mutig, sich blind darauf zu
verlassen, dass der statische Buffer hinreichend groß genug sei.
in dem Fall nicht mutig, weil würde er zu klein werden hast in dem Fall
ein ganz anderes Problem;
Post by Claus Reibenstein
Zugegebenermaßen wird man einen mehrere GB großen Buffer kaum per
Tastatur vollbekommen.
Du wirst auch 16 kB nicht vollbekommen, wenn das maximal mögliche (mein
Einsatz) nur 5 6-8 kByte sind;
Post by Claus Reibenstein
Aber man braucht ja nur mal die Eingabe auf eine
hinreichend große Datei umzulenken,
in dem Fall handelt es sich um eine Eingabe mittels einer pipe und dort
wären mehr als 16 KByte bereits ein anderes Problem ...
Post by Claus Reibenstein
und schon ist Dein Buffer nicht mehr hinreichend groß.
In der Tat, ich weiß was ich tu;

Grüße,
Walter
Rainer Weikusat
2015-10-08 17:06:01 UTC
Permalink
Raw Message
[...]
Post by Walter H.
Post by Claus Reibenstein
Post by Walter H.
int nLen;
while ( ( nLen = read( 0, psz, 256 ) )> 0 )
{
psz += nLen;
*psz = '\0';
}
[...]
Post by Walter H.
Post by Claus Reibenstein
read() liefert 0 bei EOF. Du musst also auf Deiner Tastatur die
entsprechende Tastenkombination drücken (hängt vom Betriebssystem ab).
Dann hört die Schleife auch auf zu laufen.
genau das dachte ich ja, dass bei EOF der Wert 0 geliefert wird,
aber anscheinend kommt der Wert 0 nie ...
Wenn dem so ist, dann liegt das an etwas anderem als dem geposteten
Code. Wenn man den in ein entsprechendes Programm einbaut (Beispiel
anderswo gepostet), liest er Daten bis er ein EOF sieht (via ^D).
Post by Walter H.
in dem Fall handelt es sich um eine Eingabe mittels einer pipe und dort
wären mehr als 16 KByte bereits ein anderes Problem ...
Von einer pipe bekommst Du nur dann ein EOF wenn die niemand mehr zum
Schreiben geoeffnet hat, dh auch nicht der Prozess, der die Daten liest,
und an den der entsprechende Handle moeglicherweise via fork/exec
vererbt wurde.
Rainer Weikusat
2015-10-08 19:20:54 UTC
Permalink
Raw Message
[...]
Post by Rainer Weikusat
Post by Walter H.
in dem Fall handelt es sich um eine Eingabe mittels einer pipe und dort
wären mehr als 16 KByte bereits ein anderes Problem ...
Von einer pipe bekommst Du nur dann ein EOF wenn die niemand mehr zum
Schreiben geoeffnet hat, dh auch nicht der Prozess, der die Daten liest,
und an den der entsprechende Handle moeglicherweise via fork/exec
vererbt wurde.
Hier sei noch erwaehnt, dass der haeufiger gemachte Fehler wohl der ist,
die pipe im Vaterprozess zu erzeugen und einen Datenproduktionsprozess
zu forken, der den Schreibhandle benutzt, um Ausgaben an seinen Erzeuger
zu schicken. Der sieht aber nur dann ein EOF nach Ende des Kindprozesses
falls seine Kopie des Schreibhandles explizit geschlossen wurde.
Peter J. Holzer
2015-10-10 08:16:21 UTC
Permalink
Raw Message
Post by Walter H.
Post by Claus Reibenstein
Im Übrigen finde ich es ganz schön mutig, sich blind darauf zu
verlassen, dass der statische Buffer hinreichend groß genug sei.
in dem Fall nicht mutig, weil würde er zu klein werden hast in dem Fall
ein ganz anderes Problem;
Post by Claus Reibenstein
Zugegebenermaßen wird man einen mehrere GB großen Buffer kaum per
Tastatur vollbekommen.
Du wirst auch 16 kB nicht vollbekommen, wenn das maximal mögliche (mein
Einsatz) nur 5 6-8 kByte sind;
Auch noch in ein paar Jahren? Auch dann, wenn das andere Ende der Pipe
von jemand anderem (weiter-)entwickelt wird?
Post by Walter H.
Post by Claus Reibenstein
Aber man braucht ja nur mal die Eingabe auf eine hinreichend große
Datei umzulenken,
in dem Fall handelt es sich um eine Eingabe mittels einer pipe und dort
wären mehr als 16 KByte bereits ein anderes Problem ...
Warum sollen mehr als 16 kByte bei einer Pipe ein Problem sein? Ich
schicke ziemlich regelmäßig Gigabytes durch Pipes ...
Post by Walter H.
Post by Claus Reibenstein
und schon ist Dein Buffer nicht mehr hinreichend groß.
In der Tat, ich weiß was ich tu;
Das mag sein, aber Deine Begründungen klingen eher nicht so.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Helmut Schellong
2015-10-10 10:48:52 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Post by Walter H.
Post by Claus Reibenstein
Im Übrigen finde ich es ganz schön mutig, sich blind darauf zu
verlassen, dass der statische Buffer hinreichend groß genug sei.
[...]
Post by Peter J. Holzer
Post by Walter H.
Du wirst auch 16 kB nicht vollbekommen, wenn das maximal mögliche (mein
Einsatz) nur 5 6-8 kByte sind;
Auch noch in ein paar Jahren? Auch dann, wenn das andere Ende der Pipe
von jemand anderem (weiter-)entwickelt wird?
Man sollte unbedingt prinzipiell wie nachfolgend programmieren:

while ( psze-psz>256 && (nLen= read( 0, psz, 256 )) > 0 )
{
psz += nLen;
*psz = '\0';
}
if (psze-psz<=256) xyz_Err(3, "psize");
Post by Peter J. Holzer
Post by Walter H.
Post by Claus Reibenstein
Aber man braucht ja nur mal die Eingabe auf eine hinreichend große
Datei umzulenken,
in dem Fall handelt es sich um eine Eingabe mittels einer pipe und dort
wären mehr als 16 KByte bereits ein anderes Problem ...
Warum sollen mehr als 16 kByte bei einer Pipe ein Problem sein? Ich
schicke ziemlich regelmäßig Gigabytes durch Pipes ...
Es handelt sich gar nicht um eine Pipe!

#stdin mit Tastatur verknüpft
0<datei
#stdin mit datei verknüpft
while readline Z
do
#...
done
Post by Peter J. Holzer
<
#stdin mit Tastatur verknüpft

Die Entsprechung in C wäre hier zu groß gewesen.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Claus Reibenstein
2015-10-11 16:28:14 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Peter J. Holzer
Warum sollen mehr als 16 kByte bei einer Pipe ein Problem sein? Ich
schicke ziemlich regelmäßig Gigabytes durch Pipes ...
Es handelt sich gar nicht um eine Pipe!
Wie kommst Du darauf?
Post by Helmut Schellong
#stdin mit Tastatur verknüpft
0<datei
#stdin mit datei verknüpft
while readline Z
do
#...
done
Post by Peter J. Holzer
<
#stdin mit Tastatur verknüpft
Wo steht, dass Walter Derartiges tut? Und wer sagt, dass "datei" keine
Pipe sei? Named Pipes sind Dir ein Begriff?

Bei Pipes denke ich allerdings eher an so etwas:

#stdin mit Tastatur verknüpft
blah | blub
#stdin von blub per Pipe mit stdout von blah verknüpft

Wenn Du schon vorgibst, Ahnung von Linux/Unix zu haben, solltest Du
solche Mechanismen kennen.

Gruß
Claus
Helmut Schellong
2015-10-11 17:54:29 UTC
Permalink
Raw Message
Post by Claus Reibenstein
Post by Helmut Schellong
Post by Peter J. Holzer
Warum sollen mehr als 16 kByte bei einer Pipe ein Problem sein? Ich
schicke ziemlich regelmäßig Gigabytes durch Pipes ...
Es handelt sich gar nicht um eine Pipe!
Wie kommst Du darauf?
Wegen des Textes, auf den ich antwortete:
==========================================================================
Post by Claus Reibenstein
Post by Helmut Schellong
Post by Peter J. Holzer
Aber man braucht ja nur mal die Eingabe auf eine hinreichend große
Datei umzulenken,
in dem Fall handelt es sich um eine Eingabe mittels einer pipe und dort
wären mehr als 16 KByte bereits ein anderes Problem ...
==========================================================================

Die Eingabe auf eine Datei umlenken hat allgemein nichts mit einer Pipe
zu tun, sondern genau mit: 0 < datei (in einem Shell-Programm)

Die oben stehende Antwort mit 'mittels einer pipe' ist falsch.
Post by Claus Reibenstein
Wo steht, dass Walter Derartiges tut? Und wer sagt, dass "datei" keine
Pipe sei? Named Pipes sind Dir ein Begriff?
Du kennst den Thread nicht, oder Du tut so als ob!

Der Original-Poster hatte keine Überlauf-Sicherheit programmiert.
Er wurde deshalb kritisiert und wehrte sich.
Jemand schrieb dann:
"mal die Eingabe auf eine hinreichend große Datei umzulenken"
als Warnung.
Post by Claus Reibenstein
#stdin mit Tastatur verknüpft
blah | blub
#stdin von blub per Pipe mit stdout von blah verknüpft
Ganz genau!
Nur, es geht ja gar nicht um eine Pipe!
Beziehungsweise, es hat jemand auf einem Irrtum beruhend eine Pipe
ins Spiel gebracht.
Post by Claus Reibenstein
Wenn Du schon vorgibst, Ahnung von Linux/Unix zu haben, solltest Du
solche Mechanismen kennen.
Das auf einem Irrtum beruhende Einbringen einer pipe hatte ich als
einer der größten Fachleute auf diesem Gebiet bemerkt.

Ich bin schließlich der Entwickler des leistungsfähigsten
Shell-Programms der Welt und kenne mich bis zum Erbrechen
mit Funktionen wie pipe(), dup(), dup2(), fork(), wait(),
open(), read(), write(), close(), ..., aus - seit 1995.

Es ist wirklich 'entzückend', mir Ahnungslosigkeit hinsichtlich
Linux/Unix vorzuwerfen.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Walter H.
2015-10-11 18:33:26 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Claus Reibenstein
Post by Helmut Schellong
Post by Peter J. Holzer
Warum sollen mehr als 16 kByte bei einer Pipe ein Problem sein? Ich
schicke ziemlich regelmäßig Gigabytes durch Pipes ...
Es handelt sich gar nicht um eine Pipe!
Wie kommst Du darauf?
==========================================================================
Post by Claus Reibenstein
Post by Helmut Schellong
Post by Peter J. Holzer
Aber man braucht ja nur mal die Eingabe auf eine hinreichend große
Datei umzulenken,
in dem Fall handelt es sich um eine Eingabe mittels einer pipe und dort
wären mehr als 16 KByte bereits ein anderes Problem ...
==========================================================================
nur beruht Deine Annahme von etwas falschem auf tatsächlich richtigen
Fakten;
es werden maximal 8 kByte mittels pipe übertragen;
Post by Helmut Schellong
Die Eingabe auf eine Datei umlenken hat allgemein nichts mit einer Pipe
zu tun, sondern genau mit: 0 < datei (in einem Shell-Programm)
Die oben stehende Antwort mit 'mittels einer pipe' ist falsch.
ne ist sie leider ganz und gar nicht;

mach mal "man 2 pipe"
(und genau das verwendet der aufrufende Prozess)
Post by Helmut Schellong
Post by Claus Reibenstein
Wo steht, dass Walter Derartiges tut? Und wer sagt, dass "datei" keine
Pipe sei? Named Pipes sind Dir ein Begriff?
Du kennst den Thread nicht, oder Du tut so als ob!
Der Original-Poster hatte keine Überlauf-Sicherheit programmiert.
bei Problemen, daß es seltsamerweise in eine Endlosschleife entartet,
ist die nicht vorhandene Überlauf-Sicherheit eines unmöglichen Überlaufs
das kleinere Problem ;-)
Post by Helmut Schellong
Er wurde deshalb kritisiert und wehrte sich.
"mal die Eingabe auf eine hinreichend große Datei umzulenken"
als Warnung.
über die Sinnhaftigkeit dessen muss ich dann wohl eh nichts anmerken;
Post by Helmut Schellong
Post by Claus Reibenstein
#stdin mit Tastatur verknüpft
blah | blub
#stdin von blub per Pipe mit stdout von blah verknüpft
Ganz genau!
Nur, es geht ja gar nicht um eine Pipe!
würde es um was anderes gehen wäre es aber Käse ;-)

Ausgaben von meinem Programm auf 1 (stdout) werden vom aufrufenden
Prozess weiterverarbeitet, und Ausgaben auf 2 (stderr) landem in einem
der vielen Logfiles des aufrufenden Prozesses;
Post by Helmut Schellong
Ich bin schließlich der Entwickler des leistungsfähigsten
Shell-Programms der Welt und kenne mich bis zum Erbrechen
mit Funktionen wie pipe(), dup(), dup2(), fork(), wait(),
open(), read(), write(), close(), ..., aus - seit 1995.
pipe() <-- der Name ist Programm ;-)
Post by Helmut Schellong
Es ist wirklich 'entzückend', mir Ahnungslosigkeit hinsichtlich
Linux/Unix vorzuwerfen.
weiß mans ;-)
Helmut Schellong
2015-10-11 20:39:19 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Claus Reibenstein
Post by Helmut Schellong
Post by Peter J. Holzer
Warum sollen mehr als 16 kByte bei einer Pipe ein Problem sein? Ich
schicke ziemlich regelmäßig Gigabytes durch Pipes ...
Es handelt sich gar nicht um eine Pipe!
Wie kommst Du darauf?
==========================================================================
Post by Claus Reibenstein
Post by Helmut Schellong
Post by Peter J. Holzer
Aber man braucht ja nur mal die Eingabe auf eine hinreichend große
Datei umzulenken,
in dem Fall handelt es sich um eine Eingabe mittels einer pipe und dort
wären mehr als 16 KByte bereits ein anderes Problem ...
==========================================================================
nur beruht Deine Annahme von etwas falschem auf tatsächlich richtigen Fakten;
es werden maximal 8 kByte mittels pipe übertragen;
Post by Helmut Schellong
Die Eingabe auf eine Datei umlenken hat allgemein nichts mit einer Pipe
zu tun, sondern genau mit: 0 < datei (in einem Shell-Programm)
Die oben stehende Antwort mit 'mittels einer pipe' ist falsch.
ne ist sie leider ganz und gar nicht;
Doch:
==========================================================================
Post by Helmut Schellong
Post by Claus Reibenstein
Aber man braucht ja nur mal die Eingabe auf eine hinreichend große
Datei umzulenken,
==========================================================================
Lies doch mal diesen Satz ganz genau.
Eine Pipe ist keine Datei mit einer bestimmten Inhaltsgröße.
"hinreichend große Datei" paßt nicht zu einer Pipe.
Im Regelfall ist eine Pipe gar keine Datei.

Der oben stehende Antwortsatz paßt nicht zu dem Satz, zu dem
die Antwort erfolgt.
Die beiden Sätze lassen sich nicht korrekt kombinieren.

Daß Dein Programm in Wahrheit doch mit Pipe arbeitet, ist irrelevant,
denn dann paßt der erste oben stehende Satz nicht zum zweiten.

Jemand hat ein bestimmtes Szenario angenommen, um seine Warnung
zu belegen.
Zu diesem Szenario paßt der Folgesatz nicht.
Das bemerkte ich.
Daß Dein reales Szenario nicht zu dem angenommenen paßt, schließt eine
Argumentation damit innerhalb des angenommenen Szenarios aus!
Das hast Du jedoch nicht bemerkt.

[...]
Post by Helmut Schellong
Es ist wirklich 'entzückend', mir Ahnungslosigkeit hinsichtlich
Linux/Unix vorzuwerfen.
weiß mans ;-)
Wer seit Jahrzehnten routiniert mit mehreren verschiedenen Unixoiden
umgeht, einschließlich Kernel-Programmierung, /device-Entwicklung,
Shell-Entwicklung, hunderte C-Programme entwickelte, bemerkt schnell
diverse Feinheiten/Unstimmigkeiten, die andere nicht bemerken.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Walter H.
2015-10-12 09:50:15 UTC
Permalink
Raw Message
Post by Helmut Schellong
==========================================================================
Post by Claus Reibenstein
Aber man braucht ja nur mal die Eingabe auf eine hinreichend große
Datei umzulenken,
==========================================================================
Lies doch mal diesen Satz ganz genau.
a ist der Käse und
b stammt der auch nicht von mir ;-)
Walter H.
2015-10-12 10:14:12 UTC
Permalink
Raw Message
Post by Helmut Schellong
[...]
Post by Walter H.
Post by Helmut Schellong
Es ist wirklich 'entzückend', mir Ahnungslosigkeit hinsichtlich
Linux/Unix vorzuwerfen.
weiß mans ;-)
Wer seit Jahrzehnten routiniert mit mehreren verschiedenen Unixoiden
umgeht, einschließlich Kernel-Programmierung, /device-Entwicklung,
Shell-Entwicklung, hunderte C-Programme entwickelte, bemerkt schnell
diverse Feinheiten/Unstimmigkeiten, die andere nicht bemerken.
ja ich bin meinem Problem auch auf die Schliche gekommen,
in einem .conf-File hatte ich einen Shellscript angegeben
welcher nur einen weiteren Shellscript aufruft, der das ganze dann tun
sollte, und genau da hackte es;

.conf file

... = /usr/mylib/doit.sh <-- steht hier helper.sh dann klappt es,
erklär des mal jemand, warum?

doit.sh

#!/bin/sh

/usr/mylib/helper.sh 2>>/tmp/debug.log

helper.sh

#!/bin/sh

FILE=$(/usr/mylib/myprog) <-- und genau hier hackte es

...
Helmut Schellong
2015-10-12 11:06:54 UTC
Permalink
Raw Message
Post by Walter H.
ja ich bin meinem Problem auch auf die Schliche gekommen,
in einem .conf-File hatte ich einen Shellscript angegeben
welcher nur einen weiteren Shellscript aufruft, der das ganze dann tun
sollte, und genau da hackte es;
.conf file
... = /usr/mylib/doit.sh <-- steht hier helper.sh dann klappt es,
erklär des mal jemand, warum?
doit.sh
#!/bin/sh
/usr/mylib/helper.sh 2>>/tmp/debug.log
helper.sh
#!/bin/sh
FILE=$(/usr/mylib/myprog) <-- und genau hier hackte es
Dies ist massiv OffTopic.
Nach diesem kurzen Posting mache ich hier hierzu kein weiteres.

Die .conf gehört zu einem unbekannten Kommando, das diese .conf liest
und in unbekannter Weise interpretiert.
Dazu kann ich nichts weiter sagen.

FILE=$(/usr/mylib/myprog)

Die Ausgabe stdout von myprog wird in der Variablen FILE
gespeichert.
Sollen Zwischenraumzeichen eliminiert werden?
Falls nicht:
FILE="$(/usr/mylib/myprog)"
Anhängender Zeilenvorschub kann Probleme machen.

Was ist mit 'export FILE'?

doit.sh und helper.sh sind normalerweise separate Prozesse, so daß
'export FILE' für das Kommando, welches .conf liest, sinnlos wäre.
(export funktioniert nicht prozeß-rückwärts!)

Es kann aber sein, daß dieses Kommando das angegebene Skript
per '. helper.sh' direkt ausführt (Dot-Kommando).
Dann würde (in) helper.sh $FILE (ohne export) zugreifbar sein.

Es ist auch unbekannt, ob das .conf-Kommando weitere Prozesse
erzeugt, die noch relevant sind.

Jedenfalls ist der Inhalt von $FILE im doit.sh-Prozeß
nicht erreichbar.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Walter H.
2015-10-12 11:47:44 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Walter H.
ja ich bin meinem Problem auch auf die Schliche gekommen,
in einem .conf-File hatte ich einen Shellscript angegeben
welcher nur einen weiteren Shellscript aufruft, der das ganze dann tun
sollte, und genau da hackte es;
.conf file
... = /usr/mylib/doit.sh <-- steht hier helper.sh dann klappt es,
erklär des mal jemand, warum?
doit.sh
#!/bin/sh
/usr/mylib/helper.sh 2>>/tmp/debug.log
helper.sh
#!/bin/sh
FILE=$(/usr/mylib/myprog) <-- und genau hier hackte es
Dies ist massiv OffTopic.
Nach diesem kurzen Posting mache ich hier hierzu kein weiteres.
Die .conf gehört zu einem unbekannten Kommando, das diese .conf liest
und in unbekannter Weise interpretiert.
Dazu kann ich nichts weiter sagen.
FILE=$(/usr/mylib/myprog)
Die Ausgabe stdout von myprog wird in der Variablen FILE
gespeichert.
Sollen Zwischenraumzeichen eliminiert werden?
FILE="$(/usr/mylib/myprog)"
Anhängender Zeilenvorschub kann Probleme machen.
Was ist mit 'export FILE'?
doit.sh und helper.sh sind normalerweise separate Prozesse, so daß
'export FILE' für das Kommando, welches .conf liest, sinnlos wäre.
(export funktioniert nicht prozeß-rückwärts!)
Es kann aber sein, daß dieses Kommando das angegebene Skript
per '. helper.sh' direkt ausführt (Dot-Kommando).
Dann würde (in) helper.sh $FILE (ohne export) zugreifbar sein.
Es ist auch unbekannt, ob das .conf-Kommando weitere Prozesse
erzeugt, die noch relevant sind.
Jedenfalls ist der Inhalt von $FILE im doit.sh-Prozeß
nicht erreichbar.
es geht auch nicht um stdout od. stderr, sondern darum, daß myprog
nur dann die Inhalte des den .conf-File interpretierenden Prozesses in
stdin vorfindet, wenn dieses direkt od. maximal mit einer Indirektion
aufgerufen wird;
auch wenn folgendes

simulierterinhalt.file | helper.sh
bzw.
simulierterinhalt.file | doit.sh

beim Lesen von stdin via read keine Probleme ergibt ...
Rainer Weikusat
2015-10-12 11:15:32 UTC
Permalink
Raw Message
"Walter H." <Walter.H-***@mathemainzel.info> writes:

[...]
Post by Walter H.
#!/bin/sh
FILE=$(/usr/mylib/myprog) <-- und genau hier hackte es
Dann wollen wir mal hoffen, dass es nichts abgehackt hat ...
Peter J. Holzer
2015-10-12 16:40:28 UTC
Permalink
Raw Message
Post by Helmut Schellong
==========================================================================
Post by Claus Reibenstein
Aber man braucht ja nur mal die Eingabe auf eine hinreichend große
Datei umzulenken,
==========================================================================
Lies doch mal diesen Satz ganz genau.
Eine Pipe ist keine Datei mit einer bestimmten Inhaltsgröße.
"hinreichend große Datei" paßt nicht zu einer Pipe.
Im Regelfall ist eine Pipe gar keine Datei.
Der oben stehende Antwortsatz paßt nicht zu dem Satz, zu dem
die Antwort erfolgt.
Die beiden Sätze lassen sich nicht korrekt kombinieren.
Daß Dein Programm in Wahrheit doch mit Pipe arbeitet, ist irrelevant,
denn dann paßt der erste oben stehende Satz nicht zum zweiten.
Jemand hat ein bestimmtes Szenario angenommen, um seine Warnung
zu belegen.
Zu diesem Szenario paßt der Folgesatz nicht.
Doch, der passt genau. Walter wollte damit ausdrücken, dass das von
seinem Vorposter genannte Szenario ("Eingabe auf eine hinreichend große
Datei umlenken") in seinem Fall nicht auftreten kann, weil er aus einer
Pipe liest.

(was meiner Meinung nach nichts am Problem ändert, aber das habe ich
schon geschrieben)
Post by Helmut Schellong
Das bemerkte ich.
Daß Dein reales Szenario nicht zu dem angenommenen paßt, schließt eine
Argumentation damit innerhalb des angenommenen Szenarios aus!
Das hast Du jedoch nicht bemerkt.
Doch, das hat er sogar geschrieben. Das hast nur Du nicht bemerkt :-)

(Seine Formulierung war nicht eindeutig. Die könnte man rein grammatisch
so auslegen, wie Du das offenbar gemacht hast. Nur ergibt das ganze dann
wenig Sinn (wie Du ja bemerkt hast), also ist es näherliegend, sie so
auszulegen, wie sie gemeint war.)

hp

PS: Es ist in einer Diskussion im allgemeinen besser, ein
Missverständnis zur Kenntnis zu nehmen und mit den geklärten Fakten
weiterzudiskutieren und nicht darauf zu bestehen, dass das, was man
irgendwann (miss)verstanden hat, die Wahrheit sein muss ("aber das hat er
doch schwarz auf weiß geschrieben!!1elf!") und alle weiteren Argumente
davon abzuleiten.
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Helmut Schellong
2015-10-12 18:43:01 UTC
Permalink
Raw Message
[...]
Post by Peter J. Holzer
Doch, das hat er sogar geschrieben. Das hast nur Du nicht bemerkt :-)
(Seine Formulierung war nicht eindeutig. Die könnte man rein grammatisch
so auslegen, wie Du das offenbar gemacht hast. Nur ergibt das ganze dann
wenig Sinn (wie Du ja bemerkt hast), also ist es näherliegend, sie so
auszulegen, wie sie gemeint war.)
"Seine Formulierung war nicht eindeutig."
Genau das ist der Fall.
Seine Formulierung ist nach einigen Postings (>>) in die Irre leitend:
==========================================================================
Post by Peter J. Holzer
Post by Walter H.
Post by Claus Reibenstein
Aber man braucht ja nur mal die Eingabe auf eine hinreichend große
Datei umzulenken,
in dem Fall handelt es sich um eine Eingabe mittels einer pipe und dort
wären mehr als 16 KByte bereits ein anderes Problem ...
==========================================================================

Ich sah Vorstehendes als Block und reagierte entsprechend.
Und ich hatte prinzipiell recht:
Das mit '16 kByte' hatte auch jemand anderen verwirrt!
Und ich verstand es so, als ob jemand behauptete, eine Umlenkung
auf eine Datei sei generell ein Lesen aus einer Pipe.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Helmut Schellong
2015-10-12 18:48:22 UTC
Permalink
Raw Message
On 10/12/15 18:40, Peter J. Holzer wrote:
[...]
Post by Peter J. Holzer
PS: Es ist in einer Diskussion im allgemeinen besser, ein
Missverständnis zur Kenntnis zu nehmen und mit den geklärten Fakten
weiterzudiskutieren und nicht darauf zu bestehen, dass das, was man
irgendwann (miss)verstanden hat, die Wahrheit sein muss ("aber das hat er
doch schwarz auf weiß geschrieben!!1elf!") und alle weiteren Argumente
davon abzuleiten.
Mir war nicht bekannt, daß es ein Mißverständnis gibt.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Claus Reibenstein
2015-10-14 13:48:15 UTC
Permalink
Raw Message
Post by Walter H.
Post by Helmut Schellong
Die oben stehende Antwort mit 'mittels einer pipe' ist falsch.
ne ist sie leider ganz und gar nicht;
mach mal "man 2 pipe"
Ich glaube, hier liegt ein Irrtum Deinerseits vor.

Eine Pipe kann sehr wohl mehr als 16 KB übertragen. Es gibt keinerlei
Begrenzung für die zu übertragenden Daten. Lediglich die Puffergröße ist
begrenzt (bei aktuellen Linux-Systemen auf 64 KB).

man 7 pipe

Gruß
Claus
Claus Reibenstein
2015-10-14 13:34:28 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Claus Reibenstein
Post by Helmut Schellong
Post by Peter J. Holzer
Warum sollen mehr als 16 kByte bei einer Pipe ein Problem sein? Ich
schicke ziemlich regelmäßig Gigabytes durch Pipes ...
Es handelt sich gar nicht um eine Pipe!
Wie kommst Du darauf?
==========================================================================
Post by Claus Reibenstein
Post by Helmut Schellong
Post by Peter J. Holzer
Aber man braucht ja nur mal die Eingabe auf eine hinreichend große
Datei umzulenken,
in dem Fall handelt es sich um eine Eingabe mittels einer pipe und dort
wären mehr als 16 KByte bereits ein anderes Problem ...
==========================================================================
Hast Du den Text auch im Zusammenhang gelesen? Ich habe nicht den Eindruck.
Post by Helmut Schellong
Die Eingabe auf eine Datei umlenken hat allgemein nichts mit einer Pipe
zu tun, sondern genau mit: 0 < datei (in einem Shell-Programm)
Niemand hat etwas Anderes behauptet.
Post by Helmut Schellong
Die oben stehende Antwort mit 'mittels einer pipe' ist falsch.
Was genau ist daran falsch? Wenn der OP sagt, dass seine Eingabe mittels
einer Pipe erfolgt, dann ist zunächst einmal davon auszugehen, dass dem
auch so ist.
Post by Helmut Schellong
Post by Claus Reibenstein
Wo steht, dass Walter Derartiges tut? Und wer sagt, dass "datei" keine
Pipe sei? Named Pipes sind Dir ein Begriff?
Du kennst den Thread nicht, oder Du tut so als ob!
Im Gegensatz zu Dir kenne ich ihn sehr genau.
Post by Helmut Schellong
Der Original-Poster hatte keine Überlauf-Sicherheit programmiert.
Er wurde deshalb kritisiert und wehrte sich.
Die Kritik stammte von mir.
Post by Helmut Schellong
"mal die Eingabe auf eine hinreichend große Datei umzulenken"
als Warnung.
Auch das war ich.
Post by Helmut Schellong
Post by Claus Reibenstein
#stdin mit Tastatur verknüpft
blah | blub
#stdin von blub per Pipe mit stdout von blah verknüpft
Ganz genau!
Nur, es geht ja gar nicht um eine Pipe!
Beziehungsweise, es hat jemand auf einem Irrtum beruhend eine Pipe
ins Spiel gebracht.
Das war der OP höchstpersönlich!
Post by Helmut Schellong
Ich bin schließlich der Entwickler des leistungsfähigsten
Shell-Programms der Welt
LOL :-)
Post by Helmut Schellong
und kenne mich bis zum Erbrechen
mit Funktionen wie pipe(), dup(), dup2(), fork(), wait(),
open(), read(), write(), close(), ..., aus - seit 1995.
Erst seit 1995? Da kann ich rund 10 Jahre mehr bieten.
Post by Helmut Schellong
Es ist wirklich 'entzückend', mir Ahnungslosigkeit hinsichtlich
Linux/Unix vorzuwerfen.
Deine Antworten ließen kaum einen anderen Schluss zu.

Gruß
Claus
Helmut Schellong
2015-10-14 14:53:11 UTC
Permalink
Raw Message
[...]
Die Angelegenheit - ein Mißverständnis wegen mißverständlichem Text
- ist längst geklärt.
Post by Claus Reibenstein
Post by Helmut Schellong
und kenne mich bis zum Erbrechen
mit Funktionen wie pipe(), dup(), dup2(), fork(), wait(),
open(), read(), write(), close(), ..., aus - seit 1995.
Erst seit 1995? Da kann ich rund 10 Jahre mehr bieten.
Ich schrieb 'bis zum Erbrechen' seit 1995.
Ich kenne diese Funktionen seit etwa 1988, nur nicht
derartig gut wie seit 1995.
Einige Funktionen davon kenne ich sogar aus dem K&R1
seit 1981. Zu der Zeit wurde man neugierig auf C
an der FHS Bielefeld.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Walter H.
2015-10-11 18:18:30 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Post by Walter H.
Post by Claus Reibenstein
Im Übrigen finde ich es ganz schön mutig, sich blind darauf zu
verlassen, dass der statische Buffer hinreichend groß genug sei.
in dem Fall nicht mutig, weil würde er zu klein werden hast in dem Fall
ein ganz anderes Problem;
Post by Claus Reibenstein
Zugegebenermaßen wird man einen mehrere GB großen Buffer kaum per
Tastatur vollbekommen.
Du wirst auch 16 kB nicht vollbekommen, wenn das maximal mögliche (mein
Einsatz) nur 5 6-8 kByte sind;
Auch noch in ein paar Jahren? Auch dann, wenn das andere Ende der Pipe
von jemand anderem (weiter-)entwickelt wird?
ja auch noch in Zeiten, in denen die Architektur von heute tot ist;
Post by Peter J. Holzer
Post by Walter H.
Post by Claus Reibenstein
Aber man braucht ja nur mal die Eingabe auf eine hinreichend große
Datei umzulenken,
in dem Fall handelt es sich um eine Eingabe mittels einer pipe und dort
wären mehr als 16 KByte bereits ein anderes Problem ...
Warum sollen mehr als 16 kByte bei einer Pipe ein Problem sein? Ich
schicke ziemlich regelmäßig Gigabytes durch Pipes ...
nicht ein Problem, sondern ein anderes Problem ...
Post by Peter J. Holzer
Post by Walter H.
Post by Claus Reibenstein
und schon ist Dein Buffer nicht mehr hinreichend groß.
In der Tat, ich weiß was ich tu;
Das mag sein, aber Deine Begründungen klingen eher nicht so.
hast Du sie denn verstanden?
Peter J. Holzer
2015-10-12 16:49:34 UTC
Permalink
Raw Message
Post by Walter H.
Post by Peter J. Holzer
Post by Walter H.
In der Tat, ich weiß was ich tu;
Das mag sein, aber Deine Begründungen klingen eher nicht so.
hast Du sie denn verstanden?
Was soll man auf diese Frage anderes als "ja" antworten?

Deine Begründungen klingen ja nicht kompliziert, nur sehr blauäugig.

Ich wäre da vorsichtig und würde einen entsprechenden Check einbauen.
Das kostet weniger Zeit als Du jetzt hier in dieser Diskussion
verschwendet hast und sehr viel weniger als Du potentiell zur Behebung
aufwenden müsstest (Prognosen sind ja bekanntlich schwierig, vor allem,
wenn sie die Zukunft betreffen).

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Walter H.
2015-10-16 06:57:44 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Post by Walter H.
Post by Peter J. Holzer
Post by Walter H.
In der Tat, ich weiß was ich tu;
Das mag sein, aber Deine Begründungen klingen eher nicht so.
hast Du sie denn verstanden?
Was soll man auf diese Frage anderes als "ja" antworten?
das war keine rethorische Frage;
Post by Peter J. Holzer
Deine Begründungen klingen ja nicht kompliziert, nur sehr blauäugig.
nein; aber ich gewinne den Eindruck, daß viele irgendwelchen Probleme
als Ursache sehen, worum es eigentlich gar nicht geht;
fast so als wolle man mir einreden, nur weil der Scheinwerfer am Auto
defekt ist, aus der Kurve zu rutschen; daß aber eine erhöhte
Geschwindigkeit und/oder mangelnde Bereifung das verursachen vergisst
dabei jeder;
Juergen Ilse
2015-10-16 08:38:41 UTC
Permalink
Raw Message
Hallo,
Post by Walter H.
Post by Peter J. Holzer
Post by Walter H.
Post by Peter J. Holzer
Post by Walter H.
In der Tat, ich weiß was ich tu;
Das mag sein, aber Deine Begründungen klingen eher nicht so.
hast Du sie denn verstanden?
Was soll man auf diese Frage anderes als "ja" antworten?
das war keine rethorische Frage;
Post by Peter J. Holzer
Deine Begründungen klingen ja nicht kompliziert, nur sehr blauäugig.
nein; aber ich gewinne den Eindruck, daß viele irgendwelchen Probleme
als Ursache sehen, worum es eigentlich gar nicht geht;
fast so als wolle man mir einreden, nur weil der Scheinwerfer am Auto
defekt ist, aus der Kurve zu rutschen; daß aber eine erhöhte
Geschwindigkeit und/oder mangelnde Bereifung das verursachen vergisst
dabei jeder;
Auch wenn die Puffer-groesse beim lesen aus der Pipe <= 16 kb ist, wuerde
ich mich nicht darauf verlassen wollen, dass mit einem einzigen read()
nicht ggfs. auch mehr als 16 kb gelesen werden koennten. Deine Begruendung,
weshalb bei dir der Buffer "garantiert gross genug" waere, erscheint mir
daher nicht plausibel (und das war es, was auch andere dir bereits mitge-
teilt haben).

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Walter H.
2015-10-16 09:40:08 UTC
Permalink
Raw Message
Post by Juergen Ilse
Deine Begruendung,
weshalb bei dir der Buffer "garantiert gross genug" waere, erscheint mir
daher nicht plausibel (und das war es, was auch andere dir bereits mitge-
teilt haben).
und auch Du damit keinen Beitrag zur Sache geliefert hast ...
merke: aus der Kurve zu fliegen liegt nicht am defekten Scheinwerfer ;-)
Juergen Ilse
2015-10-16 10:29:31 UTC
Permalink
Raw Message
Hallo,
Post by Walter H.
Post by Juergen Ilse
Deine Begruendung,
weshalb bei dir der Buffer "garantiert gross genug" waere, erscheint mir
daher nicht plausibel (und das war es, was auch andere dir bereits mitge-
teilt haben).
und auch Du damit keinen Beitrag zur Sache geliefert hast ...
merke: aus der Kurve zu fliegen liegt nicht am defekten Scheinwerfer ;-)
Dass dein Problem vermutlich *keine* Endlosschleife ist, und worin es
vermulitch liegt, wurde bereits in den Postings mit den folgenden Message-IDS
geklaert:

<***@doppelsaurus.mobileactivedefense.com>
<***@doppelsaurus.mobileactivedefense.com>

Dass in deinem Programm ein weiteres (latentes) Problem liegen koennte
(und worin es liegt), ist hier durchaus OnTopic, und egal wie sehr du
jetzt "ist nicht hilfreich" schreibst: es ist hilfreich (vielleicht
nicht fuer dich, sofern du in der Beziehung lernresistent bist, wohl
aber fuer andere, die ihre Programme nicht mit dem selben potentiellen
Fehler ausstatten moechten). Wenn dich diese Hinweise stoeren, dann
ignoriere sie einfach. Du musst sie nicht jedesmal kommentieren.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
PS: deine urspruengliche Frage ist hier OffTopic gewesen, auch wenn sie
kompetent beantwortet wurde, da die library-Funktion read() nicht zum
Sprachumfang und ist damit hier in der Gruppe OffTopic, sofern man nicht
gerade ueber den in C-Source einer bestimmten Implementierung diskutieren
moechte. OnTopic waere das wohl in der unix-programmier-Gruppe, da read()
zwar nicht im C-Standard, wohl aber im POSIX-Standard definiert ist.
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Claus Reibenstein
2015-10-16 12:40:10 UTC
Permalink
Raw Message
Post by Walter H.
merke: aus der Kurve zu fliegen liegt nicht am defekten Scheinwerfer ;-)
Was immer Du damit sagen willst ...

Gruß
Claus
Peter J. Holzer
2015-10-23 06:42:48 UTC
Permalink
Raw Message
Post by Juergen Ilse
Post by Walter H.
Post by Peter J. Holzer
Post by Walter H.
Post by Peter J. Holzer
Post by Walter H.
In der Tat, ich weiß was ich tu;
Das mag sein, aber Deine Begründungen klingen eher nicht so.
hast Du sie denn verstanden?
Was soll man auf diese Frage anderes als "ja" antworten?
das war keine rethorische Frage;
Post by Peter J. Holzer
Deine Begründungen klingen ja nicht kompliziert, nur sehr blauäugig.
nein; aber ich gewinne den Eindruck, daß viele irgendwelchen Probleme
als Ursache sehen, worum es eigentlich gar nicht geht;
Worum es geht, bestimmt in einer Usenet-Diskussion nicht der OP. Dein
Problem mit dem hängenden read (keine! Endlosschleife) wurde
wahrscheinlich von Rainer bereits beantwortet (Ich kann mich übrigens
nicht erinnern, dass Du darauf eingegangen wärst).

In diesem Teilthread geht es um defensive Programmierung beim Lesen von
mehr oder weniger bekannten Datenquellen. Ein Thema, das eigentlich seit
dem Morris-Wurm 1988 keines mehr sein sollte, aber offenbar ist das "Das
kann *mir* nicht passieren"-Mindset unausrottbar.
Post by Juergen Ilse
Post by Walter H.
fast so als wolle man mir einreden, nur weil der Scheinwerfer am Auto
defekt ist, aus der Kurve zu rutschen; daß aber eine erhöhte
Geschwindigkeit und/oder mangelnde Bereifung das verursachen vergisst
dabei jeder;
Auch wenn die Puffer-groesse beim lesen aus der Pipe <= 16 kb ist, wuerde
ich mich nicht darauf verlassen wollen, dass mit einem einzigen read()
nicht ggfs. auch mehr als 16 kb gelesen werden koennten.
Das einzelne read ist hier nicht das Problem (das wird mit count=256
aufgerufen, kann also maximal 256 Bytes lesen), sondern die Summe aller
reads. Die Schleife hat nur EOF bzw. Fehler als Abbruchbedingung, also
darf das Programm am anderen Ende insgesamt nicht mehr als 16 kB in die
Pipe schreiben. Ob es ein Problem gibt, hängt also ausschließlich von
diesem anderen, unbekannten Programm ab. Und da wäre ich halt lieber
defensiv und würde einen Check einbauen statt mich auf Aussagen wie "das
Programm liefert 5 bis 8 kB, und das ist für alle Ewigkeit garantiert"
zu verlassen. Solche "Ewigkeiten" können manchmal kurz sein ...

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Rainer Weikusat
2015-10-08 14:14:47 UTC
Permalink
Raw Message
Post by Walter H.
folgendes Code-Snippet läuft in eine Endlosschleife, nur warum?
char* psz = szBuf; /* szBuf ist ein hinreichend */
/* großer statischer Buffer */
int nLen;
while ( ( nLen = read( 0, psz, 256 ) ) > 0 )
{
psz += nLen;
*psz = '\0';
}
Folgendes Program,

--------
#include <unistd.h>

static char szBuf[65536];

int main(void)
{
char* psz = szBuf; /* szBuf ist ein hinreichend */
/* großer statischer Buffer */
int nLen;

while ( ( nLen = read( 0, psz, 256 ) ) > 0 )
{
psz += nLen;
*psz = '\0';
}

return 0;
}
--------

funktioniert fuer mich 'wie erwartet' (dh es beendet sich nach einem
EOF). Das heisst allerdings nicht notwendigerweise etwas fuer Dein
Program und waere in einer UNIX(*)-Gruppe besser untergebracht ...
Herbert Rosenau
2015-10-08 14:39:51 UTC
Permalink
Raw Message
Post by Rainer Weikusat
funktioniert fuer mich 'wie erwartet' (dh es beendet sich nach einem
EOF). Das heisst allerdings nicht notwendigerweise etwas fuer Dein
Program und waere in einer UNIX(*)-Gruppe besser untergebracht ...
Das beweeist einmal mehr daß der Weikusat absolut keinen Schimmer von C hat.

Das Programm ist kompatibel zu so seltenen Systemen wie DOD, OS/2,
Windows (alle Versionen), AIX, Munix, Apple OS /alle Versionen) usw., usw.

Weikusat wird in 1000 Jahren nicht begreifen können was C ist. Er hat es
im vergangenen Jahrtausend nicht kapiert und wird es den Rest seines
Lebens nicht kapieren können. Jegliche Aussagen von ihm über C sind mit
allergrößter Vorsicht zu genießen. Die Wahrscheinlichkeit daß eine
seiner Aussagen wirklich korrekt ist, tendiert gegen 0, zero.
Rainer Weikusat
2015-10-08 15:10:36 UTC
Permalink
Raw Message
Post by Herbert Rosenau
Post by Rainer Weikusat
funktioniert fuer mich 'wie erwartet' (dh es beendet sich nach einem
EOF). Das heisst allerdings nicht notwendigerweise etwas fuer Dein
Program und waere in einer UNIX(*)-Gruppe besser untergebracht ...
Das beweeist einmal mehr daß der Weikusat absolut keinen Schimmer von C hat.
Das "beweist" hoechstens, das mein killfile einer Ergaenzung bedarf ...
Claus Reibenstein
2015-10-08 16:16:44 UTC
Permalink
Raw Message
Post by Herbert Rosenau
Post by Rainer Weikusat
funktioniert fuer mich 'wie erwartet' (dh es beendet sich nach einem
EOF). Das heisst allerdings nicht notwendigerweise etwas fuer Dein
Program und waere in einer UNIX(*)-Gruppe besser untergebracht ...
Das beweeist einmal mehr daß der Weikusat absolut keinen Schimmer von C hat.
Soso.
Post by Herbert Rosenau
Das Programm ist kompatibel zu so seltenen Systemen wie DOD, OS/2,
Windows (alle Versionen), AIX, Munix, Apple OS /alle Versionen) usw., usw.
Irrelevant.
Post by Herbert Rosenau
Weikusat wird in 1000 Jahren nicht begreifen können was C ist.
Und Du wohl auch nicht.

read() ist keine ANSI-C-Funktion, sondern POSIX (schrieb ich in
<***@mid.individual.net> bereits), und POSIX stammt aus der
Unix-Welt.

Gruß
Claus
Helmut Schellong
2015-10-09 08:52:57 UTC
Permalink
Raw Message
[...]
Post by Claus Reibenstein
read() ist keine ANSI-C-Funktion, sondern POSIX (schrieb ich in
Unix-Welt.
Zunächst einmal handelt es sich um ein C-Programm, das in dieser
Newsgroup generell richtig ist.

Es kann lediglich einen Ausschluß von ganz bestimmten Fragen
zu diesem C-Programm geben.

Beispielsweise kann eine Funktion ksl_Read() statt read()
verwendet werden.
Zu dieser Funktion ksl_Read() gibt es eine Definition, die
zufällig der Definition von read() entspricht.
Und nun?
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Claus Reibenstein
2015-10-09 10:04:35 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Claus Reibenstein
read() ist keine ANSI-C-Funktion, sondern POSIX (schrieb ich in
Unix-Welt.
Zunächst einmal handelt es sich um ein C-Programm, das in dieser
Newsgroup generell richtig ist.
Das Programm als solches ist ja auch vollkommen korrekt.
Post by Helmut Schellong
Es kann lediglich einen Ausschluß von ganz bestimmten Fragen
zu diesem C-Programm geben.
Zum Beispiel Fragen zur Funktion read().
Post by Helmut Schellong
Beispielsweise kann eine Funktion ksl_Read() statt read()
verwendet werden.
Zu dieser Funktion ksl_Read() gibt es eine Definition, die
zufällig der Definition von read() entspricht.
Und nun?
Keine Ahnung, was Du mir damit sagen willst.

Gruß
Claus
Helmut Schellong
2015-10-09 15:13:49 UTC
Permalink
Raw Message
Post by Claus Reibenstein
Post by Helmut Schellong
Beispielsweise kann eine Funktion ksl_Read() statt read()
verwendet werden.
Zu dieser Funktion ksl_Read() gibt es eine Definition, die
zufällig der Definition von read() entspricht.
Und nun?
Keine Ahnung, was Du mir damit sagen willst.
Die Funktion ksl_Read() wäre 100% OnTopic.
Alle Fragen dazu auch.

Da ksl_Read() vollkommen gleich definiert ist wie read(),
muß read() automatisch ebenfalls vollkommen OnTopic sein.
Das gebietet ganz einfache Logik.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Claus Reibenstein
2015-10-09 16:47:02 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Claus Reibenstein
Post by Helmut Schellong
Beispielsweise kann eine Funktion ksl_Read() statt read()
verwendet werden.
Zu dieser Funktion ksl_Read() gibt es eine Definition, die
zufällig der Definition von read() entspricht.
Und nun?
Keine Ahnung, was Du mir damit sagen willst.
Die Funktion ksl_Read() wäre 100% OnTopic.
Alle Fragen dazu auch.
Da ksl_Read() vollkommen gleich definiert ist wie read(),
muß read() automatisch ebenfalls vollkommen OnTopic sein.
Das gebietet ganz einfache Logik.
Vorausgesetzt, ksl_Read() ist in ANSI-C definiert. Das wiederum setzt
voraus, dass read() ebenfalls in ANSI-C definiert ist.

So viel zu "ganz einfache Logik".

Gruß
Claus
Helmut Schellong
2015-10-09 19:51:26 UTC
Permalink
Raw Message
Post by Claus Reibenstein
Post by Helmut Schellong
Post by Claus Reibenstein
Post by Helmut Schellong
Beispielsweise kann eine Funktion ksl_Read() statt read()
verwendet werden.
Zu dieser Funktion ksl_Read() gibt es eine Definition, die
zufällig der Definition von read() entspricht.
Und nun?
Keine Ahnung, was Du mir damit sagen willst.
Die Funktion ksl_Read() wäre 100% OnTopic.
Alle Fragen dazu auch.
Da ksl_Read() vollkommen gleich definiert ist wie read(),
muß read() automatisch ebenfalls vollkommen OnTopic sein.
Das gebietet ganz einfache Logik.
Vorausgesetzt, ksl_Read() ist in ANSI-C definiert. Das wiederum setzt
voraus, dass read() ebenfalls in ANSI-C definiert ist.
So viel zu "ganz einfache Logik".
Es sind nur der Prototyp und eine Beschreibung der Argumente
und des Rückgabewertes beider Funktionen bekannt.
Die Definitionen der Funktionen sind nicht bekannt;
das müssen sie auch nicht.
read() muß keine POSIX-Funktion sein.
Es kann auch ein Makro sein, oder die Lib hat gar kein POSIX.

Ein diese Funktionen verwendendes C-Programm ist hier
zwangsläufig voll OnTopic.
Andernfalls müßte ja jede beliebige Funktion überprüft
werden, ob sie eventuell direkt oder indirekt einen Aufruf
einer POSIX-Funktion enthält und dann zutreffenderweise das
aufrufende C-Programm als hier nicht diskutabel erklärt werden.
Das jedoch geht 'irgendwie' nicht.

Falls Informationen wie
. include <unistd.h>
. [ECONNRESET] The fd argument refers to a socket, and
und ähnlich auftauchen, dann ist es OffTopic.
Falls nicht, dann nicht.

Es kann nicht sein, daß eine OffTopic-Situation automatisch eintritt,
sobald irgendwo in einem Posting der Name einer (vermeintlichen)
POSIX-Funktion erkennbar ist.

Man kann einem Poster doch z.B. seine Fehler bei Argumentübergabe
an eine POSIX-Funktion aufzeigen. Das wäre doch OnTopic.
Daß es eine POSIX-Funktion ist, interessiert dabei doch gar nicht.
Fehler bei Argumentübergabe sind übergreifend.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Peter J. Holzer
2015-10-10 08:08:53 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Claus Reibenstein
Post by Helmut Schellong
Post by Claus Reibenstein
Post by Helmut Schellong
Beispielsweise kann eine Funktion ksl_Read() statt read()
verwendet werden.
Zu dieser Funktion ksl_Read() gibt es eine Definition, die
zufällig der Definition von read() entspricht.
Und nun?
Keine Ahnung, was Du mir damit sagen willst.
Die Funktion ksl_Read() wäre 100% OnTopic.
Alle Fragen dazu auch.
Da ksl_Read() vollkommen gleich definiert ist wie read(),
muß read() automatisch ebenfalls vollkommen OnTopic sein.
Das gebietet ganz einfache Logik.
Vorausgesetzt, ksl_Read() ist in ANSI-C definiert. Das wiederum setzt
voraus, dass read() ebenfalls in ANSI-C definiert ist.
So viel zu "ganz einfache Logik".
Es sind nur der Prototyp und eine Beschreibung der Argumente
und des Rückgabewertes beider Funktionen bekannt.
Die Definitionen der Funktionen sind nicht bekannt;
Dann ist jede Diskussion darüber, unter welchen Bedingungen es passieren
kann, dass diese Funktion nie einen nicht-positiven Wert zurückliefert,
nicht nur off-topic, sondern vor allem vollkommen sinnlos. Wenn niemand
weiß, was die Funktion macht, was sollte man da diskutieren?

(Dass es für den Abbruch der Schleife notwendig ist, dass die Funktion
irgendwann einen Wert <= 0 zurückliefert, wäre on-topic, ist aber so
offensichtlich, dass es keiner Diskussion bedarf)

Bei read() hingegen weiß man - wenn es sich hier um eine
POSIX-kompatible Plattform handelt - was es tun soll, und dass die
Return-Werte 0 und -1 tatsächlich unter bestimmten wohldefinierten
Bedingungen, die einem Ende der Eingabe entsprechen, auftreten. Man kann
also sagen, dass die Schleife so korrekt ist. Die Diskussion darüber,
unter welchen Bedingungen read() nie 0 zurückliefern wird, ist in diesem
Fall ebenfalls sinnvoll, aber in einer Unix-Gruppe on-topic, da man
dafür Unix-Konzepte (Pipes, Devices, Prozesse, ...) braucht. (Rainer
dürfte die richtige Lösung übrigens gefunden haben, auch wenn ich dieses
Verhalten nicht als "Endlosschleife" bezeichnen würde)

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Helmut Schellong
2015-10-10 10:30:23 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Post by Helmut Schellong
Es sind nur der Prototyp und eine Beschreibung der Argumente
und des Rückgabewertes beider Funktionen bekannt.
Die Definitionen der Funktionen sind nicht bekannt;
Dann ist jede Diskussion darüber, unter welchen Bedingungen es passieren
kann, dass diese Funktion nie einen nicht-positiven Wert zurückliefert,
nicht nur off-topic, sondern vor allem vollkommen sinnlos. Wenn niemand
weiß, was die Funktion macht, was sollte man da diskutieren?
Der Inhalt jeder beliebigen Library-Funktion ist unbekannt.
Das gilt für C-Lib, POSIX-Lib, XYZ-Lib.

Dennoch kann in vollem Umfang darüber diskutiert werden.
Siehe C-Lib.
Dem C-Standard ist es egal, wie die Standard-Funktionen, die er
beschreibt, definiert sind: zum Beispiel in Assembler!

Ich beschreibe ksl_Read():

int ksl_Read(int handle, char *buf, int n);
// Beschreibung der Argumente
// Beschreibung des Rückgabewertes

Ab hier kann darüber diskutiert werden, genau so wie über
jede Standard-Funktion.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Claus Reibenstein
2015-10-11 16:39:58 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Peter J. Holzer
Post by Helmut Schellong
Es sind nur der Prototyp und eine Beschreibung der Argumente
und des Rückgabewertes beider Funktionen bekannt.
Die Definitionen der Funktionen sind nicht bekannt;
Dann ist jede Diskussion darüber, unter welchen Bedingungen es passieren
kann, dass diese Funktion nie einen nicht-positiven Wert zurückliefert,
nicht nur off-topic, sondern vor allem vollkommen sinnlos. Wenn niemand
weiß, was die Funktion macht, was sollte man da diskutieren?
Der Inhalt jeder beliebigen Library-Funktion ist unbekannt.
Das gilt für C-Lib, POSIX-Lib, XYZ-Lib.
Dennoch kann in vollem Umfang darüber diskutiert werden.
Nein.
Post by Helmut Schellong
Siehe C-Lib.
Du meinst die Standard-C-Library, nehme ich an. Diese ist die einzige
Ausnahme, da deren Funktionen im Standard definiert ist.

read() ist jedoch _nicht_ im Standard enthalten.
Post by Helmut Schellong
Dem C-Standard ist es egal, wie die Standard-Funktionen, die er
beschreibt, definiert sind: zum Beispiel in Assembler!
Dem Anwender ebenfalls.
Post by Helmut Schellong
int ksl_Read(int handle, char *buf, int n);
// Beschreibung der Argumente
// Beschreibung des Rückgabewertes
Ab hier kann darüber diskutiert werden, genau so wie über
jede Standard-Funktion.
Aber nur über die Anwendung der Funktion, nicht jedoch über deren Interna.

Bei read() ist es genauso. Vorausgesetzt, es handelt sich tatsächlich um
eine Implementierung der POSIX-Funktion, wovon ich ausgehe.

Gruß
Claus
Helmut Schellong
2015-10-11 18:16:45 UTC
Permalink
Raw Message
Post by Claus Reibenstein
Du meinst die Standard-C-Library, nehme ich an. Diese ist die einzige
Ausnahme, da deren Funktionen im Standard definiert ist.
read() ist jedoch _nicht_ im Standard enthalten.
Post by Helmut Schellong
Dem C-Standard ist es egal, wie die Standard-Funktionen, die er
beschreibt, definiert sind: zum Beispiel in Assembler!
Dem Anwender ebenfalls.
Zuvor waren Deine Argumente:
======================================================================
Vorausgesetzt, ksl_Read() ist in ANSI-C definiert. Das wiederum setzt
voraus, dass read() ebenfalls in ANSI-C definiert ist.
======================================================================
Post by Claus Reibenstein
Post by Helmut Schellong
int ksl_Read(int handle, char *buf, int n);
// Beschreibung der Argumente
// Beschreibung des Rückgabewertes
Ab hier kann darüber diskutiert werden, genau so wie über
jede Standard-Funktion.
Aber nur über die Anwendung der Funktion, nicht jedoch über deren Interna.
Ganz genau!
Über die Interna der C-Standard-Funktionen kann ebensowenig
diskutiert werden.

int ksl_Read(int handle, char *buf, int n)
{
return read(handle, buf, n);
}
Post by Claus Reibenstein
Bei read() ist es genauso. Vorausgesetzt, es handelt sich tatsächlich um
eine Implementierung der POSIX-Funktion, wovon ich ausgehe.
read() muß allerdings vor einer Diskussion hier erklärt werden.
Genau so hinreichend wie der Standard seine Funktionen erklärt.

Es ist egal, woher eine Nicht-Standard-Funktion kommt.
Hauptsache, sie ist hinreichend erklärt.
Der Funktionskörper muß nie bekannt sein; es sei denn, ein Fehler
im Körper soll herausanalysiert werden; dann muß der Körper
selbstverständlich vollständig gültiges C enthalten.

Der Hinweis eines Fragestellers:
"Zu den auch verwendeten POSIX-Funktionen muß ich hier nichts erklären -
sind ja bekannt."
würde die Angelegenheit OffTopic machen.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Stefan Reuther
2015-10-08 16:44:58 UTC
Permalink
Raw Message
Post by Herbert Rosenau
Post by Rainer Weikusat
funktioniert fuer mich 'wie erwartet' (dh es beendet sich nach einem
EOF). Das heisst allerdings nicht notwendigerweise etwas fuer Dein
Program und waere in einer UNIX(*)-Gruppe besser untergebracht ...
Das beweeist einmal mehr daß der Weikusat absolut keinen Schimmer von C hat.
Das Programm ist kompatibel zu so seltenen Systemen wie DOD, OS/2,
Windows (alle Versionen), AIX, Munix, Apple OS /alle Versionen) usw., usw.
Selbst wenn das so wäre (was es nicht ist), bewiese das nur, dass die
Systeme eine hinreichend gute Unix-Emulation mitbringen.

In der Realität gilt hingegen
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
u.c:
Error E2209 u.c 1: Unable to open include file 'unistd.h'
Warning W8065 u.c 11: Call to function 'read' with no prototype in
function main
oder
Turbo C Version 2.01 Copyright (c) 1987, 1988 Borland International
u.c:
Error u.c 1: Unable to open include file 'unistd.h'
Error u.c 3: Array size too large
Error u.c 3: Size of structure or array not known
*** 3 errors in Compile ***
oder
Error C:\digitalmars\include\unistd.h 6: "unistd.h is not for
Windows use"
--- errorlevel 1

(Die Systeme aus der DOS / OS/2 / Windows-Klasse, die eine read-Funktion
mitbringen, tun das normalerweise in einer <io.h>.)


Stefan
Walter H.
2015-10-08 18:58:16 UTC
Permalink
Raw Message
Post by Stefan Reuther
(Die Systeme aus der DOS / OS/2 / Windows-Klasse, die eine read-Funktion
mitbringen, tun das normalerweise in einer<io.h>.)
in der <io.h> von Microsoft's Compiler - egal ob 16-bit wie MS-C 6.0 od.
der mit Visual C++ 1.x mitgelieferte Compiler oder die 32-bit bzw.
64-bit Compiler der neuesten Generation findet man sowas:

### int __cdecl _read(int, void *, unsigned int);

bzw.

/* Non-ANSI names for compatibility */

### int __cdecl read(int, void *, unsigned int); // im !__STDC__ block

und das ### soll nur die Unterschiede je nach Compilierung bzw.
Code-Generierung andeuten: mit multi-threaded Runtime, eingebunden
oder dynamisch als DLL gelinkt andeuten;
analog mit den anderen Funktionen wie: creat, close, open, write, ...

Quellcode-kompatibel bekommt hier eine ganz neue Bedeutung ...

Grüße,
Walter

p.s. Du solltest nicht umbedingt mit einem 16-bit compiler Datenblöcke
mit mehr als 64 kByte haben, ausgenommen im Speichermodell HUGE, wo
diese explizit auch als sogenannte huge-Arrays definiert sind, und damit
auch zu DOS-Zeiten ein paar 100 kByte linear adressiert werden konnten;
der compiler kümmerte sich durch das 'huge' um die korrekte Adressierung;
absolute Adresse im Read-Mode: 16*segment + offset
was automatisch heißt, daß segment+1 bzw. offset-16 die absolute Adresse
unverändert läßt;
Helmut Schellong
2015-10-09 08:38:49 UTC
Permalink
Raw Message
Post by Herbert Rosenau
Das beweeist einmal mehr daß der Weikusat absolut keinen Schimmer von C hat.
Weikusat wird in 1000 Jahren nicht begreifen können was C ist. Er hat es im
vergangenen Jahrtausend nicht kapiert und wird es den Rest seines Lebens
nicht kapieren können. Jegliche Aussagen von ihm über C sind mit allergrößter
Vorsicht zu genießen. Die Wahrscheinlichkeit daß eine seiner Aussagen
wirklich korrekt ist, tendiert gegen 0, zero.
Ich verstehe nicht, wie man so etwas schreiben und formulieren kann.

Bist Du gerade in einer Mordlust-/Hass-Schleife?
Sachlich betrachtet hält das keiner Überprüfung stand.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Juergen Ilse
2015-10-09 10:59:08 UTC
Permalink
Raw Message
Hallo,
Post by Herbert Rosenau
Post by Rainer Weikusat
funktioniert fuer mich 'wie erwartet' (dh es beendet sich nach einem
EOF). Das heisst allerdings nicht notwendigerweise etwas fuer Dein
Program und waere in einer UNIX(*)-Gruppe besser untergebracht ...
Das beweeist einmal mehr daß der Weikusat absolut keinen Schimmer von C hat.
Nicht von dir auf andere schliessen, bitte.
Post by Herbert Rosenau
Das Programm ist kompatibel zu so seltenen Systemen wie DOD, OS/2,
Windows (alle Versionen), AIX, Munix, Apple OS /alle Versionen) usw., usw.
Aber nur deshlab, weil die entsprechenden C-Implementierungen sich nicht
auf den ANSI-Standard beschraenken, sondern auch Teile des POSIX-Standards
mitimplementieren (wie bei dem hier diskutierten Fall z.B. read()).
Post by Herbert Rosenau
Weikusat wird in 1000 Jahren nicht begreifen können was C ist.
Eigentlich bist es eher du, der damit ein Problem hat. Der Sprachstandard
kennt kein read() sondern nur fread(). Das read trotzdem bei vielen Imple-
mentierungen vorhanden ist, besagt nicht, dass es Teil des sprachstandards
waere.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Loading...