Sonderzeichen aus String entfernen

[Elvir È. (elvir)]

Hallo,

Ich schreibe gerade ein Programm, welches aus einer txt-Datei 
Zeilenweise einen eingelesenen String (Namen) vergleicht und dann 
ausgibt, ob der Name existiert oder nicht.

Hier mein Code:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <limits.h>

int main(void)
{
    char content[80];
    char name[20], name2[20];
    int i=0;
    int flag=0;
    
    FILE *fp;
    
    fp = fopen("Liste.txt","r");
    
    if (fp == NULL)
    {
        printf("Datei konnte nicht geöffnet werden\n Vorgang abgebrochen\n");
        fclose(fp);
        exit(0);
    }
    
    else
    {
        printf("Datei wurde korrekt gelesen\n");
    }
    
    
    printf("Geben Sie den zu suchenden Namen ein\n");
    scanf("%s", name);
    
    
    for (i=0; i<20; i++)
    {
        fgets(content, 255, fp);
        sscanf(name, "%s", name2);
    
        if(strcmp(name2, content) != 0)
        {
            flag=0;
        }
            
        else //if(strcmp(name2, content) == 0)
        {
            flag=1;
            break;
        }  
    }
    
    printf("Vergleich beendet\n");
    
    if (flag==0) printf("Der Name existiert NICHT in der Liste\n");
    
    else printf("Der Name existiert in der Liste\n");
     
    fclose(fp);
    
    return 0;
}

Die txt-Datei sind so aus:
Anton
Gustav
Karl
Heinrich
Tobias


Das Problem ist, dass in der txt-Datei das Return mit eingelesen wird. 
Wie filtere ich dieses heraus?



Mit freundlichen Grüßen

[Dirk B. (dirkb2)]

Mit strrchr suchen und ggf. durch '\0' ersetzen.
oder
Selber suchen (for- oder while-Schleife)
oder
kein fgets sondern Zeilen mit fscanf und %s einlesen

Aber noch etwas anderes:
Weißt du wofür die 255 bei fgets(content, 255, fp); steht?
Und wie die mit content zusammen hängt?

[Elvir È. (elvir)]

Danke für die schnelle Antwort!

Ich habe den Fehler schon gefunden

statt

fgets(content, 255, fp);
sscanf(name, "%s", name2);

sollte stehen

fgets(content, 255, fp);
sscanf(content, "%s", name2);

Der String-Compare Befehl filtert sozusagen ja schon das Return heraus.

Zu deiner Frage:
255 ist die Große von content(?). Vorher war das content bei mir 255 
statt 80 und hatte es vergessen im Befehl umzuändern.

Mit freundlichen Grüßen

[Rolf Magnus (Gast)]

Elvir Ègalo schrieb:
> Vorher war das content bei mir 255 statt 80 und hatte es vergessen im
> Befehl umzuändern.

Und was lernst du daraus?
Um's abzukürzen: Du solltest daraus lernen, daß es nie gut ist, solche 
Zahlen mehrfahch irgendwo hinzuschreiben. Was meinst du, was bei einem 
wirklich komplexen Programm passiert, wenn man da mal so eine Größe 
ändert?
Besser ist es, die Größe genau einmal zu definieren:

#define CONTENT_SIZE 255

[...]

{
    char content[CONTENT_SIZE];

[...]

        fgets(content, CONTENT_SIZE, fp);

So kann es nicht passieren, daß die Werte aufgrund einer Änderung 
irgendwann nicht mehr zusammenpassen.

[Dirk B. (dirkb2)]

Elvir Ègalo schrieb:
> Der String-Compare Befehl filtert sozusagen ja schon das Return heraus.

Nein.

Das mach in diesem Fall das sscanf.
\n ist ein Whitespace und da hört sscanf bei %s mit dem Einlesen auf.
Bzw. überliest es am Anfang.

[Karl H. (kbuchegg)]

Das hier

   for (i=0; i<20; i++)
    {
        fgets(content, 255, fp);
        sscanf(content, "%s", name2);
...

ist im übrigen auch keine gute Idee.
Gemeint sind die 20 in der for-Schleife.

Woher weißt du, dass in der Datei 20 Namen stehen? Was ist, wenn da mal 
mehr oder weniger Namen enthalten sind?

Fazit: Anstatt einer for-Schleife, geht man anders vor.
Alle Datei-Leseoperationen in C sind so gestaltet, dass man ihren Return 
Wert in der einen oder anderen Form dazu benutzen kann um eine Antwort 
auf die Frage zu erhalten: konnte von der Datei (noch) gelesen werden 
oder nicht?

D.h. man wird die notwendige Schleife so gestalten, dass sie genau über 
diesen Return Wert gesteuert wird. Wenn gelesen werden konnte, dann 
erfolgt ein weiterer Durchgang durch die Schleife.
Bei fgets sieht die Sache so aus, dass fgets einen von NULL 
verschiedenen Wert liefert, wenn gelesen werden konnte und den Wert NULL 
wenn nicht gelesen werden konnte. Die Schleife sieht dann so aus

...

    while( fgets(content, CONTENT_SIZE, fp) != NULL )
    {
      sscanf(content, "%s", name2);
      ....

    }

Wenn man es ganz genau nimmt, dann müsste man nach Beendigung dieser 
while Schleife noch prüfen, warum diese Schleife abgebrochen wurde, 
warum also fgets nicht mehr lesen konnte. Denn da gibt es ja mehrere 
Möglichkeiten. Eine davon ist, dass die Datei komplett verarbeitet 
wurde, man also bis zum EOF (End Of File) gelesen hat. Ein Aufruf der 
feof()-Funktion klärt das. Liefert er TRUE, dann ist alles in Ordnung. 
Liefert der aber nicht TRUE, dann gab es einen Fehler. Zb. weil jemand 
den USB Stick abgezogen hat, oder die CD einen Lesefehler hatte, oder 
die Netzwerkverbindung zusammengebrochen ist, oder ... Da gibt es viele 
Möglichkeiten, warum fgets den Versuch von einer Datei zu lesen 
abbrechen musste - EOF ist nur eine davon.

[Dirk B. (dirkb2)]

In diesem Fall (nur ein Eintrag pro Zeile, keine Leerzeichen im Namen, 
durch Whitespace getrennt)
geht auch

while( fscanf(fp, "%19s", name2) == 1 )
    {
      if(strcmp(name2, 
      ....

    }

[ah8 (Gast)]

    fp = fopen("Liste.txt","r");
    
    if (fp == NULL)
    {
        printf("Datei konnte nicht geöffnet werden\n Vorgang abgebrochen\n");
        fclose(fp);
        exit(0);
    }

Wenn Dir fopen einen NULL-Pointer zurückgibt und Du anschließend 
versuchst, diesen Pointer mit fclose zu schließen, so könnte Dein 
Programm mit einer segmentation violation abbrechen, wahrscheinlich 
sogar, bevor Du eine Chance hast, die vorhergehende Fehlermeldung zu 
sehen. Denn die geht nach stdout, stdout ist gepuffert und Puffer werden 
bei einem Abbruch meistens nicht mehr geflusht (siehe man fflush). Also, 
schicke Deine Fehlermeldungen mit fprintf nach stderr, dort gehören sie 
hin und es reduziert die Gefahr, dass Dir Meldungen verloren gehen. Vor 
allem aber verzichte auf das fclose an dieser Stelle, es ist mindestens 
konzeptionell falsch. Es kann sein, dass fclose diesen Fehler abfängt, 
das glaube ich aber nicht.

[Rolf Magnus (Gast)]

ah8 schrieb:
> Also, schicke Deine Fehlermeldungen mit fprintf nach stderr, dort gehören
> sie hin und es reduziert die Gefahr, dass Dir Meldungen verloren gehen.

Und am besten auch gleich noch eine etwas genauere Meldung. Eine 
Fehlermeldung liefert strerror(errno) zurück. Für alles zusammen (also 
die Fehleremeldung plus eigenen Text nach stderr schreiben) gibt's auch 
schon die Funktion perror():

    if (fp == NULL)
    {
        perror("Datei konnte nicht geöffnet werden");
        exit(0);
    }

Dann wird dein Text ausgegeben, gefolgt von einem Doppelpunkt und dem 
Grund, warum die Datei nicht geöffnet werden konnte.

[Karl H. (kbuchegg)]

Und wenn man noch ganz lieb ist, dann führt man in der Fehlermeldung 
auch noch an, wie die Datei heißt, die nicht geöffnet werden konnte.

Microsoft hat Millionen Programmierer mit ihrer generischen Meldung "DLL 
konnte nicht geöffnet werden" in die Weißglut getrieben, weil kein 
Mensch wusste, von welcher DLL eigentlich die Rede war. Das ist 
insbesondere dann frustrierend, wenn du einem Kunden am Telefon weiter 
helfen sollst, und der hat nicht mehr als diese Meldung.

[Wolfgang (Gast)]

Karl Heinz schrieb:
> Und wenn man noch ganz lieb ist, dann führt man in der Fehlermeldung
> auch noch an, wie die Datei heißt, die nicht geöffnet werden konnte.

... und nicht nur den Namen sondern mit voller Pfadangabe.

> Microsoft hat Millionen Programmierer mit ihrer generischen Meldung "DLL
> konnte nicht geöffnet werden" in die Weißglut getrieben ...

Dafür gibt es jetzt beim Abdocken eines "USB-Massenspeichergerätes" die 
in ihrer Präzision kaum zu übertreffende Meldung: "Dieses Gerät wird 
gerade verwendet. Schließen Sie alle Programme oder Fenster, die 
möglicherweise das Gerät verwenden, und wiederholen Sie den Vorgang"

[Rolf Magnus (Gast)]

Wolfgang schrieb:
> Dafür gibt es jetzt beim Abdocken eines "USB-Massenspeichergerätes" die
> in ihrer Präzision kaum zu übertreffende Meldung: "Dieses Gerät wird
> gerade verwendet. Schließen Sie alle Programme oder Fenster, die
> möglicherweise das Gerät verwenden, und wiederholen Sie den Vorgang"

Eigentlich unglaublich, aber früher war das doch noch schlechter. Da 
wurde nur gemeldet, daß das Gerät gerade nicht beendet werden kann, 
und man soll es doch später nochmal versuchen. Einfach überhaupt kein 
Hinweis darauf, daß es daran liegen könnte, daß ein Programm noch eine 
Datei auf dem Datenträger offen haben hat.
Meine Lieblingsmeldung aus Lotus Notes:
"Beim Öffnen eines Fensters ist ein Fehler aufgetreten."

[Prog R. (daniel_v)]

Passt zwar thematisch nicht ganz hier rein.
Aber meine liebste Fehlermeldung war mal, als ich mich mit einem 
Lenovo-Notebook (Win7) nicht ins WLAN verbinden konnte:

"Die Problembehandlung konnte aufgrund eines Problems nicht gestartet 
werden."

Den Programmierer hätte ich wirklich gerne mal kennengelernt :)
(Hab ich mir sogar aufgehoben)