Ich habe ein altes Turbo-C-Programm, das dos_firstfind und dos_nextfind benutzt um Dateien in Verzeichnissen zu öffnen. Nun möchte ich alle .htm-Dateien in einem Verzeichnis nacheinander öffnen und bearbeiten lassen. Als Compiler nehme ich GCC in der DEV C++ Umgebung. Leider kennt diese Umgebung diese firstfind und nextfind-Befehle nicht. Kann mir jemand sagen (vielleicht mit Hinweis auf ein Code-Beispiel) was ich stattdessen benutzen kann? Vielen Dank ! Matthias
Joachim Drechsel schrieb: > opendir() etc sollte er kennen. Danke. Das kennt er. Gibts zu diesem Thema ein brauchbares Code-Beispiel?
in der WindowsAPI gäbe es da noch FindFirstFile/FindNextFile die ähnlich
den DOS-Befehlen funktionieren.
#include <windows.h>
....
{
HANDLE hFind = NULL;
hFind = FindFirstFile(sPath, &fdFile);
if(hFind == INVALID_HANDLE_VALUE) return 0;
do {
}
while(FindNextFile(hFind, &fdFile));
FindClose(hFind);
}
http://stackoverflow.com/questions/2314542/listing-directory-contents-using-c-and-windows
Dennis Heynlein schrieb: > http://stackoverflow.com/questions/2314542/listing-directory-contents-using-c-and-windows Vielen Dank Dennis ! Leider scheint in dem Installationspaket von GCC die Windows API nicht dabei zu sein. Jedenfalls finde ich FindFirstFile nicht in den Header-Dateien.
MingW magste nicht ? Oder andere Frage, welche GCC für Windows nimmste ? Und Codeblocks ist ein würdiger Nachfolger von Bloodshed Dev C++.
Dennis Heynlein schrieb: > MingW magste nicht ? ich habe keine Abneigung gegen MingW Dennis. Die Dev C++ verwendet das ja meines Wissens. > Oder andere Frage, welche GCC für Windows nimmste ? es gibt ja nicht so viele Möglichkeiten. Cygwin oder MingW. > Und Codeblocks ist ein würdiger Nachfolger von Bloodshed Dev C++. Danke für den Hinweis. Ich kann das mal ansehen. Eclipse gäbe es auch. Das sind halt leider manchmal riesige Pakete. Schwer zu begreifen für einen Einsteiger, der um 1990 mit Turbo C effizient gearbeitet hatte. Turbo C scheint nicht totzukriegen. Ich sah Videos wie man das unter XP bzw. Win7 in Betrieb nimmt. Auch das wäre also möglich.
Schau dir doch mal LCC an: http://www.cs.virginia.edu/~lcc-win32/ damit hab ich "früher" mal gearbeit als ich für Windows ein C-Programm geschrieben habe, hat natürlich keine IDE aber für einfache Sachen braucht es das auch nicht.
Also im Normalfall hat MingW die Includes und die Libs für die Windows
API dabei.
Versuch doch mal:
#include <windows.h>
#include <stdio.h>
int main() {
OSVERSIONINFO oi;
oi.dwOSVersionInfoSize= sizeof(OSVERSIONINFO) ;
if(GetVersionEx(&oi)) {
switch(oi.dwPlatformId) {
case VER_PLATFORM_WIN32_NT: printf("WINNT ");break;
case VER_PLATFORM_WIN32_WINDOWS: printf("WINDOWS ");break;
case VER_PLATFORM_WIN32s: printf("WIN32s ");break;
default: printf("Unknown ");
}
printf("%lu.%lu\r\n",oi.dwMajorVersion,oi.dwMinorVersion);
}
else printf("Fehler\n");
return 0;
}
Dennis Heynlein schrieb: > Also im Normalfall hat MingW die Includes und die Libs für die Windows > API dabei. Hallo Dennis, WINNT 5.1 kommt dabei raus. Codeblocks habe ich installiert. Im Paket war kein GCC dabei. Der muss also noch integriert werden oder ich finde ein Paket wo das mit dabei ist.
GetVersionEx ist eine Funktion der WindowsApi. So einfach lassen die sich einsetzen. Gruß Dennis MingW bringt alles zur WinApi mit, außer eine Hilfedatei.
Dennis schrieb: > GetVersionEx ist eine Funktion der WindowsApi. > So einfach lassen die sich einsetzen. Danke Dennis ! > MingW bringt alles zur WinApi mit, außer eine Hilfedatei. prima. Dev++ bringt eine Menge an Hilfe mit. Das gefällt mir gut. Leider hat mein Versuch Dateien mit Wildcard (*.htm) im Verzeichnis zu finden mit dem Befehl glob nicht geklappt. Die Datei glob.h scheint nicht vorhanden im MingW unter der DEV++ Umgebung. Der Explorer findet auch nichts. So einfach ist das leider nicht das alte Programm das einst unter TC lief wieder zum Leben zu erwecken. Das wird mir immer klarer. Codeblocks läuft noch nicht mit GCC.
leider scheint glob zu fehlen: https://code.zmaw.de/projects/cdo/wiki/Win32 "Globbing: New feature in 1.5.9 cannot be used with the win32 version, because mingw does not include glob.h"
Matthias W. schrieb: > Leider hat mein Versuch Dateien mit Wildcard (*.htm) im Verzeichnis zu > finden mit dem Befehl glob nicht geklappt. Brauchst Du ja auch nicht. Du hast jetzt einen Compiler, mit dem Du die Win32-API verwenden kannst. Und da sind FindFirstFile und FindNextFile Deine Freunde, wie Dennis auch schon schrieb: Beitrag "Re: alle .htm-Dateien im Verzeichnis nacheinander öffnen"
als Compilersatz ist in der DEV++ angegeben: TDM-GCC 4.7.1 32bit Release.
Rufus Τ. Firefly schrieb: > Und da sind FindFirstFile und FindNextFile Deine Freunde Danke für den Hinweis Rufus. Die Funktion hatte ich erst mal nicht gefunden - warum auch immer. Sie steht in der winbase.h. Mein erster Versuch damit orientiert sich an einem MS-Beispiel: #include <windows.h> #include <stdio.h> void main (int argc, char *argv[]) { WIN32_FIND_DATA FindFileData; HANDLE hFind; hFind = FindFirstFile("C:\\doc\\CSRC\\*.htm", &FindFileData); if (hFind == INVALID_HANDLE_VALUE) { printf ("FindFirstFile failed (%d)\n", GetLastError()); return; } else { printf ("The first file found is %s\n",FindFileData.cFileName); FindClose(hFind); } } Leider kommt damit die Meldung "The first file found is c - how can I get this..." Keine Ahnung wieso damit nicht die erste Datei mit der Endung .htm im Verzeichnis C:\\doc\\CSRC\\*.htm gefunden wird. Diese suche ich ja.
Matthias W. schrieb: > Leider kommt damit die Meldung "The first file found is c - how can I > get this..." Du wirst in Deinem Verzeichnis eine Datei haben, die "c - how can I get this..." etc. heißen wird. Vergiss das mit der "ersten" Datei; welche ist die "erste"? Wer legt fest, was die "erste" ist? Eben. Der Explorer sortiert, und je nach Sortierung ist das eine oder das andere das erste. Und auch dir in der Kommandozeile sortiert. Ändere mal Dein Programm zu
1 | void main (int argc, char *argv[]) |
2 | {
|
3 | WIN32_FIND_DATA FindFileData; |
4 | HANDLE hFind; |
5 | |
6 | hFind = FindFirstFile("C:\\doc\\CSRC\\*.htm", &FindFileData); |
7 | if (hFind == INVALID_HANDLE_VALUE) |
8 | {
|
9 | printf ("FindFirstFile failed (%d)\n", GetLastError()); |
10 | return; |
11 | }
|
12 | |
13 | do
|
14 | {
|
15 | printf("File '%s'\n", FindFileData.cFileName); |
16 | }
|
17 | while (FindNextFile(hFind, &FindFileData)); |
18 | |
19 | FindClose(hFind); |
20 | }
|
und sieh Dir die Ausgabe an.
Rufus Τ. Firefly schrieb: > Du wirst in Deinem Verzeichnis eine Datei haben, die "c - how can I get > this..." etc. heißen wird. Danke Rufus ! Das wars. Da ist tatsächlich eine .htm-Datei die so heißt. Das hat mich verwirrt weil ich die Endung nicht gleich sah und vor allem nach Dateien gesucht hatte die viel kürzere Namen haben. Dein Beispiel geht prima. Alle .htm werden aufgelistet.
Du solltest wohl mal das Ausblenden von bekannten Erweiterungen ausschalten in Windows XP :)
Dennis Heynlein schrieb: > Du solltest wohl mal das Ausblenden von bekannten Erweiterungen > ausschalten in Windows XP :) Microsoft wird sich ja wohl was dabei gedacht haben, immerhin ist das auch unter Windows 8 immer noch standardmäßig eingeschaltet. Viren- und Wurmprogrammierern soll das Leben wohl nicht zu schwer gemacht werden ...
Dennis Heynlein schrieb: > Du solltest wohl mal das Ausblenden von bekannten Erweiterungen > ausschalten in Windows XP :) ausgeblendet ist da nichts. Scheint als ob ich eine Brille brauche . . .
Hallo Dennis und Rufus, ich habe anbei das C-file angehängt, das den Ordner nach den .htm-Dateien durchsucht, diese nacheinander öffnet und in diesen Dateien die includes bearbeitet. Eine Rekursion ist bisher nicht realisiert, d.h. wenn ein include eine weitere Datei includiert so wird das nicht aufgelöst. Bis zum 3. include in der ersten Datei klappt es. Dann stürzt die Datei in Codeblocks mit einem Segmentation fault ab. Momentan weiß ich nicht woran das liegt. So sehr groß ist der Code ja nicht.
Haste mal ein paar deiner ominören Dateien wo es abkackt ?
Dennis Heynlein schrieb: > Haste mal ein paar deiner ominören Dateien wo es abkackt ? klar Dennis. Die erste gefundene .htm-Datei ist www.gesundohnepillen.de/abrams.htm. Damit tritt das Problem auf. Die Includes dazu liegen im Verzeichnis www.gesundohnepillen.de/inc. Da der Server die SSI-Befehle ausführt müsstet Du die Dateien wohl per ftp holen. Um Dir das zu ersparen habe ich test.zip gepackt. Die printf-Befehle sind eine Hilfe um zu sehen was passiert.
Dennis Heynlein schrieb: > Wieso benutzt du strtok ? und nicht > http://www.cplusplus.com/reference/cstring/strchr/ ? der Grund ist daß ich ein Beispiel fand mit strok das zu tun schien was ich an Funktion suchte. Wenn mit strchr derselbe Zweck auf eine bessere Art und Weise zu erreichen ist kann ich gerne auch das nehmen. Meine Erfahrungen mit C liegen Jahre zurück. Es ist mühsam mich da einzuarbeiten. Die paar Zeilen Code haben mich 2 Tage gekostet. Wie man Includes in den Include-Dateien selbst behandelt ist nicht gelöst bisher. Natürlich könnte man den Generator erst mal die Includes selbst bearbeiten lassen. Mit Rekursion habe ich keinerlei Erfahrung.
Morgen kuck ichs mir mal an :) strchr sucht die Position von 'char' und liefert nen Pointer Es liegt dann bei dir bei dieser Position ein \0 hinzusetzen. So macht es zumindest strtok.
Deinen Fehler kann ich nicht reproduzieren. Aber du hast da ziemlich wenig Prüfungen ob das Dateiöffnen geklappt hat.
Dennis Heynlein schrieb: > Deinen Fehler kann ich nicht reproduzieren. Vielen Dank Dennis. Das klingt so als ob es dann auch bei mir durchlaufen sollte. Vielleicht ist der Speicher zu knapp. Es sind zwar 4GB verbaut. Nur habe ich oft mehrere Fenster geöffnet und der alte Dreamweaver hat wohl ein Speicherleck. So manches Programm klemmt dann und ich müsste oft neu booten. > Aber du hast da ziemlich wenig Prüfungen ob das Dateiöffnen geklappt hat. Das stimmt. Es gibt sicher noch einiges was man einbauen könnte. Erst mal scheint mir die Funktion wichtig. Die Includes müssen sauber aufgelöst werden. Das ist der nächste Schritt.
Die Größe des Speichers ist ja ansich uninteressant. Dein Programm liefe im Endeffekt sogar problemlos auf DOS (Von der WinAPI mal abgesehen, obwohl es da ja noch Win3.11 gibt). Eventuell sind bei dir ja nicht alle Dateien erreichbar durch das Rechtesystem von Windows. Ich hab hier Windows 7-64bit Prof mit ~ 3,5 GB RAM.
Dennis Heynlein schrieb: > Eventuell sind bei dir ja nicht alle Dateien erreichbar durch das > Rechtesystem von Windows. gute Frage. Ich kann ja Abfragen einbauen ob ein Öffnen möglich ist. Getestet habe ich in der CodeBlocks-Umgebung mit den default Einstellungen. Kann das ein Problem machen? Früher nutzte ich Turbo C. Da gab es kaum Probleme. Es muss sich ja finden lassen warum unter Codeblocks dieser Segmentation fault kommt. Ob das mit Memory models zusammenhängt? Bei Turbo C konnte man damals solche auswählen. Das habe ich diesmal nicht getan.
Solange Du nicht den Rückgabewert hiervon auswertest
> quelldatei=fopen(dummy,"r"); /* oeffne .htm-Quelldatei lesend */
ist jede weitere Fehlersuche sinnlos.
Nein, mit Speichermodellen hat es nicht zu tun, so etwas gibt es
glücklicherweise nicht mehr.
Du solltest Dir mal ansehen, wie man mit Deinem Entwicklungssystem ein
Programm im Debugger laufen lassen kann, da kannst Du nämlich selbst
herausfinden, was schiefläuft.
Es wird wohl ein NULL_Pointer von fopen sein.
Der im weiteren Lauf des Programmes noch mehr Nullpointer provoziert.
Wenn man auf einen Nullpointer schreibt gibts einen Crash.
Man kann "quelldatei=fopen(dummy,"r");" auch so schreiben:
if(!(quelldatei=fopen(dummy,"r"))) { printf("Error open
%s\r\n",dummy);exit(1); }
In Windows gibt es nur noch das Memory-Modell Flat.
Du hast recht Rufus. Da liegt das Problem. Mit dem Debugger fand ich es nicht weil der Fehler erst ziemlich spät auftritt. Auf dem Rechner hatte ich eine Datei umbenannt. Die findet er dann nicht und stürzt ab. Bei dem Datenstand für Dennis hatte ich diese Datei umbenannt. Daher lief es bei ihm. Gott sei Dank bin ich nun einen Schritt weiter. Danke Dir und Dennis !
Dennis Heynlein schrieb: > Es wird wohl ein NULL_Pointer von fopen sein. Danke Dennis. Das ist es wohl. Ich baue Deinen Vorschlag ein: if(!(quelldatei=fopen(dummy,"r"))) { printf("Error open %s\r\n",dummy);exit(1); }
Die Windows-Api besitzt übrigens auch Dateibefehle :) Wenn Du da voll einsteigen möchtest. CreateFile ist der zentrale Befehl für Dateien/Geräte öffnen/erstellen. ReadFile/Writefile für lesen/schreiben CloseHandle für Datei schliessen. http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
Dennis Heynlein schrieb: > Die Windows-Api besitzt übrigens auch Dateibefehle :) Danke für den Hinweis Dennis. Es drückt mich noch immer das Einbinden der Includes. Es bringt Probleme mit sich. Dabei war die Grundidee so einfach: + bearbeite die htm-Dateien mit dem alten Dreamweaver 4 mit Code- und Layout-Fenster gleichzeitig. Das geht intuitiv und schnell + erstelle Kopfzeilen für die Dateien und binde sie über Includes ein. + erstelle Menüs für diese Dateien und binde sie über Includes ein. + verwalte die .htm und die Includes über Dreamweaver + lege alle Includes in einen Ordner inc. + nutze den Linkchecker von Dreamweaver über die .htm und Includes hinweg. + lade die .htm und die Includes per ftp auf den Server und lasse sie dort auflösen. + erstelle ein Tool um für den PC eine lauffähige Varianten zu bekommen, das die Includes direkt in die Dateien einbindet so daß diese direkt mit dem Browser betrachtbar sind. Die Seiten http://www.gesundohnepillen.de und http://www.mweisser.50g.com laufen. So weit so gut. Zu den Problemen: - damit Dreamweaver keine Fehler mit dem Linkchecker meldet musste ich in den Includes den Dateinamen /, /inc, /pic usw. voranstellen. Das geht zwar so am Server macht aber nun Ärger bei der Einbindung der Includes in die htm-Dateien. - die Funktion von Dreamweaver aus die Dateien korrekt im Browser zu betrachten schlägt fehl. Die Includes werden teilweise nicht korrekt umgesetzt, Links passen nicht. - nach dem Includieren mit meinem Programm verweisen die /, /inc, /pic auf das Stammverzeichnis der Festplatte. Dort liegen jedoch die Dateien nicht. Da der Pfad falsch ist werden die Dateien nicht gefunden. Die Links die in den Includes stehen versagen also. Mein Generator müsste das nun reparieren. Ein einfaches Einbinden schlägt fehl. Dies zur Info. Vielleicht kennt jemand ja dieses Problem.
Ich dachte für diese Erreichbarkeit der Quelldateien hast du dieses hier
eingebaut ?
"char quelle[]="C:/doc/Homepage_test";
strcpy (dummy,hilf);
strcat (dummy,quelle);
strcat (dummy,"/");
strcat (dummy,FindFileData.cFileName);
quelldatei=fopen(dummy,"r"); /* oeffne .htm-Quelldatei lesend */"
Es scheitert im Prinzip nur an den Pfäden zu den Dateien.
Das Problem ist ja nicht wirklich ein großes.
Aber mal andere Frage.
PHP auf Serverseite steht dir nicht zur Verfügung ?
Benutzt du keinen Lokalen HTTP-Server um die Dateien dann korrekt
angezeigt zu bekommen über localhost ?
Dennis Heynlein schrieb: > Ich dachte für diese Erreichbarkeit der Quelldateien hast du dieses hier > eingebaut ? Danke Dennis. Die Quelldateien sind durch das Programm erreichbar. Kein Problem damit. > Es scheitert im Prinzip nur an den Pfaden zu den Dateien. ja. Es scheitert daran, daß ich - um den Betrieb und Check im Dreamweaver zu ermöglichen in den Include-Dateien absolute Pfade bezogen auf den Root des Servers in den Includes verwenden musste. Ich musste also einen / vor den Dateinamen einführen. In den eigentlichen htm-Dateien ist sonst kein / davor. Dieser / verhindert nun daß beim Aufruf des Browsers auf dem Laptop vom Dreamweaver aus die Dateien gefunden werden weil sie eben nicht im selben Pfad stehen wie auf dem Server. > Das Problem ist ja nicht wirklich ein großes. es scheint nicht komplett behebbar, weil Dreamweaver scheinbar diese / braucht weil sonst der Link-Check fehlschlägt. So aber schlägt die Anzeige im Browser fehl. Das scheint momentan nicht behebbar. Beheben will ich die Probleme im Offline-Betrieb. Seit 2 Tagen bastele ich an einem Programm das die inc-Dateien so korrigieren soll daß der Offline-Betrieb fehlerfrei klappt. Noch immer sind Fehler im Code, die ich schwer finde. > Aber mal andere Frage. > PHP auf Serverseite steht dir nicht zur Verfügung ? doch. PHP gibt es. Auf dem Server klappt ja alles - auch ohne PHP. > Benutzt du keinen Lokalen HTTP-Server um die Dateien dann korrekt > angezeigt zu bekommen über localhost ? Du meinst auf dem Laptop - offline? Nein - da wollte ich bisher keinen Webserver einrichten. Das wäre natürlich möglich. Mir schien es einfacher das C-Programm zu schreiben, das die Einbindungen auflöst. Natürlich könnte ich auch einen Webserver einrichten und ein php-Programm schreiben, das die Dateien korrekt rausschreibt. Das schien mir bisher der größere Aufwand weil ich keine php-Erfahrung habe.
Matthias W. schrieb: > Mir schien es einfacher das C-Programm zu schreiben, das die > Einbindungen auflöst Wenn du XAMPP nutzt, ist das innerhalb von vielleicht einer halben Stunde eingerichtet vs. eine Woche wo du jetzt mit deinem C-Programm rumprobierst. Matthias W. schrieb: > und ein php-Programm schreiben, das die Dateien korrekt rausschreibt Lass dich doch nicht verwirren, PHP brauchst du hier gar nicht wenn du es nicht auch auf deinem Zielsystem nutzt, von lesen her geh ich mal davon aus das du SSI nutzt? Also XAMPP installieren, daten in den htdocs Ordner "hochladen" und einfach per localhost zugreifen, ggf. musst du SSI noch in der Konfiguration aktivieren und das war es. Ansosnten ist immer noch schleierhaft was du erreichen willst, z.B. warum "die anderen" nicht einfach die Online-Webvariante deiner Dateien nutzen können...
Habe mir mal den Source angesehen... "/meine_vortraege.htm" geht auf einem normalen Windowsrechner nicht. "./meine_vortraege.htm" geht immer.
Habe mir mal den Source angesehen... "/meine_vortraege.htm" geht auf einem normalen Windowsrechner nicht. "./meine_vortraege.htm" geht immer. Ergänzung: Wenn Du bei den Pfaden auf den impliziten Root verzichtest und komplett relative Pfade verwendest, geht das alles sehr problemlos lokal und im Web. Oft sieht man absolute Pfade (mit URL), was lokal nicht so leicht zu testen ist - aber darum scheint es Dir ja nicht zu gehen.
Läubi .. schrieb: > bedeutet aber was komplett anderes! In diesem Fall nicht: Beide Dateien liegen flach auf root-Ebene. Generell hast Du natürlich Recht.
Läubi .. schrieb: > Wenn du XAMPP nutzt, ist das innerhalb von vielleicht einer halben > Stunde eingerichtet vs. eine Woche wo du jetzt mit deinem C-Programm > rumprobierst. Danke für den Hinweis. Natürlich kann ich das mal einrichten. Das Programm jedoch das ich geschrieben habe sollte nun rascher fertig sein nach all den Vorarbeiten. So war meine Hoffnung. > von lesen her geh ich mal davon aus das du SSI nutzt? ja. XAMPP kann das also auflösen. Das hatte ich vermutet. > Ansosnten ist immer noch schleierhaft was du erreichen willst, z.B. > warum "die anderen" nicht einfach die Online-Webvariante deiner Dateien > nutzen können... es gibt Menschen, die meine Seite lieber offline betrachten als online. Für diese möchte ich eine Version bereitstellen die offline mit dem Browser nutzbar ist. Das will ich erreichen.
Hallo Dennis, Dennis Heynlein schrieb: > MingW magste nicht ? Oder andere Frage, welche GCC für Windows nimmste ? > Und Codeblocks ist ein würdiger Nachfolger von Bloodshed Dev C++. Entschuldige bitte, aber der Mann sucht keinen anderen Compiler und keine andere IDE, sondern eine Lösung, wie er die Dateien in einem Verzeichnis auflisten kann. Dazu gibt es genau eine einzige richtige Lösung, nämlich den Standard mit opendir(), listdir(), und closedir(). Diese Lösung ist deswegen richtig, weil sie plattformunabhängig und standardisiert ist. Dabei ist es dann auch völlig egal, welche Version vom GCC, oder überhaupt welchen C-Compiler der OP verwendet, solange dieser standardkonform ist -- was heutzutage wohl so ziemlich jeder C-Compiler sein müßte. Beispiel:
1 | #include <stdio.h> |
2 | #include <stdlib.h> |
3 | #include <sys/types.h> |
4 | #include <dirent.h> |
5 | |
6 | int main(int argc, char* argv[]) { |
7 | DIR* dh = NULL; /* Verzeichnishandle */ |
8 | struct dirent *sd; /* Verzeichniseintrag */ |
9 | |
10 | if(argc != 2) { |
11 | fprintf(stderr, "usage: %s <dir>\n", argv[0]); |
12 | exit(-1); |
13 | }
|
14 | |
15 | dh = opendir(argv[1]); /* Verzeichnishandle oeffnen */ |
16 | if(dh == NULL) { |
17 | fprintf(stderr, "Could not open: %s\n", argv[1]); |
18 | exit(-2); |
19 | }
|
20 | |
21 | while(1) { |
22 | sd = readdir(dh); /* 1 Verzeichniseintrag lesen */ |
23 | if(sd == NULL) break; /* wenn Ende: abbrechen */ |
24 | printf("Datei: %s\n", sd->d_name); /* ausgeben */ |
25 | /* ... hier irgendwas mit der Datei machen ... */
|
26 | }
|
27 | |
28 | closedir(dh); /* Verzeichnishandle schliessen */ |
29 | |
30 | return 0; |
31 | }
|
Diesem Beispiel fehlt die erweiterte Fehlerbehandlung. In Produktionscode sollte mindestens errno bei /readdir() == NULL/ abgefragt werden, weil die Funktion readdir() eine NULL nicht nur am Ende des Verzeichnishandle, sondern auch im Falle eines Fehlers zurückgibt. MfG, Klaus
Matthias W. schrieb: > Für diese möchte ich eine Version bereitstellen die offline mit dem > Browser nutzbar ist. Das will ich erreichen. Hallo Matthias, in diesem Fall wären durchgehend relative Pfade sicherlich der einfachste Weg - eine Ordnerstruktur, die bei Dir lokal funktioniert tut dies dann auch online. Die Klimmzüge mit absoluten Pfaden kenne ich nur dann, wenn "Netzmeister" krampfhaft das Offline-Lesen erschweren wollen und deswegen als Links mit absoluten Pfaden spicken.
Matthias W. schrieb: > es gibt Menschen, die meine Seite lieber offline betrachten als online. > Für diese möchte ich eine Version bereitstellen die offline mit dem > Browser nutzbar ist. Dafür gibt es doch aber nun schon hundertfach Programme die das leisten.
Nicolas S. schrieb: > Habe mir mal den Source angesehen... Danke Nicolas. > Wenn Du bei den Pfaden auf den impliziten Root verzichtest > und komplett relative Pfade verwendest, geht das alles sehr problemlos > lokal und im Web. anfangs hatte ich daher "meine_vortraege.htm" eingebaut. Das ging unter Dreamweaver 4 und im Browser einwandfrei - bis ich die ServerSideIncludes eingebaut habe. In diesen Dateien ging es so nicht. Dreamweaver meldete Fehler. Um diese zu vermeiden stellte ich die Links so um: "/meine_vortraege.htm". > Oft sieht man absolute Pfade (mit URL), was lokal nicht so leicht zu > testen ist - aber darum scheint es Dir ja nicht zu gehen. absolute Pfade vermeide ich wenn ich kann.
"/meine_vortraege.htm" ist ein absoluter Pfad (bezogen auf Server-Root), "./meine_vortraege.htm" ein relativer Pfad.
Hier ist der bisher letzte Stand des C-Programms. Damit wird das
Include-Verzeichnis bearbeitet.
Der Teil der klemmt steht hier. Links die beginnen mit src="/ oder
ref="/ sollen damit umgewandelt werden in src=" oder ref=".
char suche1[]=" src=\"/"; /* suche nach src="/ und entferne / */
char suche2[]=" ref=\"/"; /* suche nach ref="/ und entferne / */
leider scheint der Code das nicht zu tun. Vermutlich ein Codierfehler.
Das erste if sucht die Zeile ab auf das Leerzeichen oder das h von href.
Das zweite if sucht nach dem s oder dem r. So wird geprüft ob da src="
steht und das /-Zeichen am Ende dann beim Kopieren weggelassen. Im
zeilenstring wird das Richtige geliefert - so der Debugger.
for (i=0; ((c=zeilenstring[i])!='\0'); i++){ /* ganze Zeile untersuchen
*/
/* pruefe auf src="/ bzw. ref="/ und entferne dann / */
if ((merker1==0) && ((c==suche1[0])||(c==suche2[0]))) {
merker1=1;
}
if ((merker1==1) && ((c==suche1[1])||(c==suche2[1]))) {
merker1=2;
}
else {
merker1=0;
}
if ((merker1==2) && ((c==suche1[2])||(c==suche2[2]))) {
merker1=3;
}
else {
merker1=0;
}
if ((merker1==3) && ((c==suche1[3])||(c==suche2[3]))) {
merker1=4;
}
else {
merker1=0;
}
if ((merker1==4) && ((c==suche1[4])||(c==suche2[4]))) {
merker1=5;
}
else {
merker1=0;
}
if ((merker1==5) && ((c==suche1[5])||(c==suche2[5]))) {
merker1=6;
}
else {
merker1=0;
}
if ((merker1==6) && ((c==suche1[6])||(c==suche2[6]))) {
merker1=7;
}
else {
merker1=0;
}
if (merker1<7) {
fputc(c,zieldatei); /* zeichenweise kopieren bis auf / */
}
Läubi .. schrieb: > Dafür gibt es doch aber nun schon hundertfach Programme die das leisten. eines das wirklich brauchbar funktioniert würde mir reichen. Probiert hatte ich es mit WinHTTrack. Das dauerte ziemlich lange bis dann am Ende eine Version auf der Platte war, die jedoch leider die Dateinamen verändert hat.
Nicolas S. schrieb: > "/meine_vortraege.htm" ist ein absoluter Pfad (bezogen auf Server-Root), > "./meine_vortraege.htm" ein relativer Pfad. "meine_vortraege.htm" wäre auch ein relativer Pfad gewesen. Nur warum funktionierte er nicht? Etwa deswegen weil das Include im Ordner inc lag?
Hallo Matthias, Matthias W. schrieb: > es gibt Menschen, die meine Seite lieber offline betrachten als online. > Für diese möchte ich eine Version bereitstellen die offline mit dem > Browser nutzbar ist. Das will ich erreichen. Dann benutz' doch einfach den Webserver, damit er tut, was er tun soll. Das heißt: ändere die Seite, lad' sie hoch, und dann lädst Du sie mit einem Programm wie wget(1) wieder herunter -- fertig vom Webserver geparst mit eingesetzen SSIs und allem drum und dran. Dafür brauchst Du kein eigenes Programm und auch sonst nichts, außer natürlich wget(1). Aufruf:
1 | wget -r -x -l0 <url> |
wget für Windows findest Du hier: http://gnuwin32.sourceforge.net/packages/wget.htm . Wenn Du eine Cygwin-Installation für Deinen GCC hast, hast Du es aber wahrscheinlich bereits installiert. HTH, Klaus
Hallo Nicolas, Nicolas S. schrieb: > in diesem Fall wären durchgehend relative Pfade sicherlich der > einfachste Weg - eine Ordnerstruktur, die bei Dir lokal funktioniert tut > dies dann auch online. Nein, das tut sie leider nicht. Matthias verwendet Server Side Includes (SSI), die geparst und ausgeführt werden müssen. Deswegen geht es hier nicht um die üblichen Problemchen bei der Referenzierung von externen Objekten, sondern um die Referenzierung durch SSIs. Beste Grüße, Karl
Klaus Maus schrieb:
Vielen Dank Klaus für das Beispiel. Ich nehme momentan FindFirstFile und
FindNextFile. Das hat recht rasch funktioniert mit *.htm. Die
Unix-Äquivalente schienen unter meiner GCC-Installation nicht zu finden.
Klaus Maus schrieb: > Dann benutz' doch einfach den Webserver, damit er tut, was er tun soll. also XAMPP installieren? Dann meine Seite da hineinladen. > Das heißt: ändere die Seite, lad' sie hoch, und dann lädst Du sie mit > einem Programm wie wget(1) wieder herunter -- fertig vom Webserver > geparst mit eingesetzen SSIs und allem drum und dran. klar. Das macht der Webserver. > wget -r -x -l0 <url> danke für dem Hinweis. Das klingt umsetzbar.
Matthias W. schrieb: > Probiert hatte ich es mit WinHTTrack. Das dauerte ziemlich lange bis > dann am Ende eine Version auf der Platte war, die jedoch leider die > Dateinamen verändert hat. Solange es funktioniert? Ansonsten: http://alternativeto.net/software/httrack/
Läubi .. schrieb: > Solange es funktioniert? er ist halt für Nutzer verwirrend wenn die Dateien die man im Netz mit der Endung .htm kennengelernt hat nun .html heißen. Ebenso seltsam ist es wenn beim Klick auf das Homesymbol nicht so wie erwartet index.htm geladen wird sondern ein zusätzlich angelegtes index-2.html. Wer kann das verstehen? Meine Frage nach dem Warum blieb leider unbeantwortet. Im Forum dort fand ich Hinweise daß eine Kopie eines 800MB-Datenbestands 30GB in Anspruch genommen haben soll. So sehr brauchbar erschien mir das nicht.
Klaus Maus schrieb: > Matthias verwendet Server Side Includes (SSI) OK, da hört mein Wissen auf. Betrachtet also alle meine Anmerkungen als gegenstandslos.
Matthias W. schrieb: > er ist halt für Nutzer verwirrend wenn die Dateien die man im Netz mit > der Endung .htm kennengelernt hat nun .html heißen Naja, auch nicht weniger verwirrend als file://C:/UserData/ItsMe/.../ anstelle von http://domain.de ;-) Matthias W. schrieb: > Ebenso seltsam ist es wenn beim Klick auf das Homesymbol nicht so wie > erwartet index.htm geladen wird sondern ein zusätzlich angelegtes > index-2.html Das geschieht häufig wenn du Parameter an andere Seiten übergibst (sortierung?) oder unter gleichen URLs (z.B. / und /index.htm sind da Kandidaten) gleichen Content hast. Ich habe vor einiger Zeit mal eine "aktive" Seite so in statisches HTML umgewandelt, klar man muss ggf. die ein oder andere Sonderbarkeit hinnehmen, oder etwas die Seitenstruktur tunen, aber im großen und ganzen hat das gut geklappt. Matthias W. schrieb: > fand ich Hinweise daß eine Kopie eines 800MB-Datenbestands 30GB in > Anspruch genommen haben soll s.o. es wird (leider) wohl keine duplicate-content Analyse gemacht. Wie groß ist den deine Seite überhaupt im Quellcode? Für Spielereien und test bietet sich trotz allem ein lokaler Webserver immer an.
Hallo Nicolas, Nicolas S. schrieb: > Klaus Maus schrieb: >> Matthias verwendet Server Side Includes (SSI) > > OK, da hört mein Wissen auf. Betrachtet also alle meine Anmerkungen als > gegenstandslos. Das ist eine, nunja, etwas ältere Technologie, die heute kaum mehr genutzt wird. Im Prinzip funktioniert das ein bisschen ähnlich wie PHP: Du schreibst in Deine HTML-Seite spezielle Kommentare, die der Webserver dann durch irgendwas ersetzt. Beispiel:
1 | <html><head><title>Beispiel</title></head> |
2 | <body><!--#include file="navigation.html"--> |
3 | <h1>Hallo!</h1></body></html> |
Anstelle des '<!--#include file="navigation.html"-->' setzt der Webserver hier die Datei "navigation.html" ein. Man kann an dieser Stelle aber auch CGIs oder Kommandos aufrufen, deren Ausgabe dann an dieser Stelle in die Datei eingefügt wird. Diese Technik wurde bei statischen Webseiten gerne benutzt, um die Navigation nur in einer Datei pflegen zu müssen. Sie ist heute ein wenig in Vergessenheit geraten, da heute meistens PHP, Content-Management-Systeme, Skriptsprachen oder Templateengines verwendet werden, die meist viel mehr Möglichkeiten bieten und dabei performanter sind. HTH, Klaus
Läubi .. schrieb: Danke für die Hinweise Läubi. > s.o. es wird (leider) wohl keine duplicate-content Analyse gemacht. Wie > groß ist den deine Seite überhaupt im Quellcode? ca. 75 MB. Das ist nicht so viel für mehr als 400 htm-Dateien. Der Code ist schlank gehalten. > Für Spielereien und > test bietet sich trotz allem ein lokaler Webserver immer an. ja. Wenn ich mal mehr Zeit habe sollte ich das näher ansehen. Momentan bin ich froh daß der Converter nun endlich klappt. So erstelle ich in 5 Minuten eine lauffähige Kopie der Seite.
hast du denn Zugriff auf den Server ? So ala CGI/PHP/Perl-tralala ?
Dennis Heynlein schrieb: > hast du denn Zugriff auf den Server ? ja Dennis. Die Seiten http://www.mweisser.50g.com und http://www.gesundohnepillen.de sind meine Seiten. Beide Seiten nutzen dieselbe Datenbasis und werden nur über ein paar Softwareschalter unterschiedlich behandelt. > So ala CGI/PHP/Perl-tralala ? per ftp. Da ich den content erstelle habe ich die Quellen. Daher klappt es für mich rascher die Dateien mit ein paar selbstgeschriebenen C-Programmen zusammenzubasteln als runterzuladen. PHP wird bisher nur für das Gästebuch verwendet. Leider benutzt das kaum noch einer. Vielleicht überfordert die Captcha-Abfrage und die Frage darüber?
Hallo Matthias, nur eins verstehe ich nicht: Wenn Du die Dateien bei Dir ohnehin lokal mit einem C-Programm manipulierst, und auch den Webserver komplett unter Kontrolle hast, warum erzeugst Du sie dann mit SSI gespickt, anstelle direkt die html-Dateien zu erzeugen, die sich der Leser nachher auch anschauen soll? Warum die Unterscheidung zwischen Online- und Offline-Version? Viele Grüße Nicolas
Nicolas S. schrieb: > nur eins verstehe ich nicht: Wenn Du die Dateien bei Dir ohnehin lokal > mit einem C-Programm manipulierst, und auch den Webserver komplett unter > Kontrolle hast, warum erzeugst Du sie dann mit SSI gespickt, anstelle > direkt die html-Dateien zu erzeugen, die sich der Leser nachher auch > anschauen soll? Vielen Dank Nicolas für Dein Interesse. Der Grund für das Einführen der SSI war, daß so viel leichter zu erreichen ist daß der Kopf der Dateien einheitlich ist. Der oberste Kopfteil ist ein SSI-Teil. Dieser enthält einen weiteren SSI-Teil. Die Fußzeile ist ein SSI, die Navigation rechts usw. Auf diese Art und Weise kann ich die Seiten rascher pflegen und konsistent halten. Ohne SSI war das ein Kraftakt, weil jede Änderung in allen 450 Dateien gemacht werden musste. Das wird so weitgehend vermieden. Ein anderer Grund ist daß bei Änderungen nun meist nicht mehr so viele Dateien neu online gestellt werden müssen. Beim Jahreswechsel änderte ich früher den Copyright-Vermerk unten in den Dateien. Dann musste ich alle neu hochladen. Nun ist es nur noch die kleine Fußzeile die ich neu hochlade. Der Server setzt diese automatisch in die Dateien ein. Das sind schon große Vorteile. Die Nachteile sind jedoch: - mein Programm stellt die Dateien beim Bearbeiten nicht mehr so dar wie es auf dem Server dann aussieht. Auch die Vorschau im Browser klappt leider nicht mehr. Vielleicht wäre das mit einem neueren Dreamweaver besser. Nur müsste ich dazu Win7 installieren. Das möchte ich erst mal vermeiden. > Warum die Unterscheidung zwischen Online- und Offline-Version? Die Offline-Version ist viel schneller als die Online-Version. Da doch einiges eingebunden ist auf diesen Seiten macht es schon einen Unterschied in der Performance. Nicht jeder ist ständig im Netz. So besteht die Chance das auch ohne Netz ansehen zu können. Manche nutzen das.
Matthias W. schrieb: > Der oberste Kopfteil ist ein SSI-Teil. Dieser enthält einen weiteren > SSI-Teil. Die Fußzeile ist ein SSI, die Navigation rechts usw. > > Auf diese Art und Weise kann ich die Seiten rascher pflegen und > konsistent halten. Ohne SSI war das ein Kraftakt, weil jede Änderung in > allen 450 Dateien gemacht werden musste. Das wird so weitgehend > vermieden. > > Ein anderer Grund ist daß bei Änderungen nun meist nicht mehr so viele > Dateien neu online gestellt werden müssen. Beim Jahreswechsel änderte > ich früher den Copyright-Vermerk unten in den Dateien. Dann musste ich > alle neu hochladen. Nun ist es nur noch die kleine Fußzeile die ich neu > hochlade. Der Server setzt diese automatisch in die Dateien ein. > > Das sind schon große Vorteile. Den Grund verstehe ich. Matthias W. schrieb: > Die Offline-Version ist viel schneller als die Online-Version. Da doch > einiges eingebunden ist auf diesen Seiten macht es schon einen > Unterschied in der Performance. Nicht jeder ist ständig im Netz. So > besteht die Chance das auch ohne Netz ansehen zu können. Manche nutzen > das. Den Grund verstehe ich auch. Aber dadurch, daß die zweite Version existieren soll mußt die "fertigen" HTML-Dateien (wie sie der Leser als Offline-Version bekommt) sowieso "offline" erzeugen- was Du mit Deinem C-Programm machst. Warum erzeugst Du dann auf Deinem Server die gleichen Dateien aus den gleichen Quellen noch einmal - wo sie doch Offline schon existieren müssen? Matthias W. schrieb: > Beim Jahreswechsel änderte > ich früher den Copyright-Vermerk unten in den Dateien. Dann musste ich > alle neu hochladen. Nun ist es nur noch die kleine Fußzeile die ich neu > hochlade. Der Server setzt diese automatisch in die Dateien ein. Da hat das "einfach Hochladen der neuen Dateien" natürlich eine andere Größe - aber ist der Unterschied so groß, daß er die Arbeit, zwei Versionen jeder HTML-Datei vorhalten zu müssen rechtfertigt?
P.S.: Mein eigenes "Webprojekt" kommt an Deines von Größe und Anspruch nie heran. Ich hatte damals beim Start keine Möglichkeit auf serverseitige Scripte- also erzeuge ich einfach alle HTML-Dateien offline mit einem Matlab-Skript- vermutlich die Entsprechung zu Deinem C-Programm. Damit sind die Offline-Version auf meinem PC und die Online-Version komplett identisch. Es war auch bei mir eine bewußte Entscheidung, die Seiten ohne Tricks herunterladbar zu machen.
Nicolas S. schrieb: > Ich hatte damals beim Start keine Möglichkeit auf > serverseitige Scripte - also erzeuge ich einfach alle HTML-Dateien > offline mit einem Matlab-Skript- vermutlich die Entsprechung zu Deinem > C-Programm. das ist auch ein Weg. Meist führen ja mehrere Wege führen zum Ziel. > Es war auch bei mir eine bewußte Entscheidung, die Seiten ohne Tricks > herunterladbar zu machen. das macht Sinn. Ich bin erst mal froh diese Umbauphase an der Seite hinter mir zu haben. Leider gibt es noch das Link-Problem. Viele Links sind mittlerweile weg. Und so laufen die Klicks ins Leere. Viele Seiten hatten ich abgespeichert. Nun könnte ich anstelle eines toten Links eine txt-Datei hinterlegen wo der alte Link vermerkt ist. Wenn man Zeit hat kann man dann versuchen die Dateien zu ergänzen mit Links auf archive.org etc. Bei 10000 defekten Links kann da leicht ein Jahr weg sein. Das klingt wenig lohnend.
Es gab ein Werkzeug, um tote Links zu suchen (funktioniert offline). Sie stehen dann in einer Liste, die Du sicher mit Deinem C-Programm auch automatisch bearbeiten könntest. Ich schaue heute abend nach, wie dieses Programm hieß (wenn nicht vorher schon jemand im Forum die Antwort schreibt).
http://validator.w3.org/checklink z.B. HTTrack kann das auch... hilft ihm aber vermutlich nicht viel wenn er gerne auf den Inhalt verlinkt hätte. Manches findet sich noch im Google Cache.
P.S.: Generell ist es ja auch kein Problem, so ein Programm selbst zu schreiben, wget sei dank. Aber es gibt soetwas definitiv schon.
Guten Morgen, das Finden der toten Links ist ja nur der erste Schritt. Das ginge automatisch. Zweiter Schritt wäre das Testen, ob der tote Link bei archive.org ein Pendant hat. Das ginge auch automatisch. Im dritten Schritt würden die Ersatz-Links in der eigenen Website mit dem entsprechenden Hinweis ersetzt. Das ginge auch automatisch. Am Ende müßte man sich nur mit den übrigen Links beschäftigen, die tot sind und nicht bei Archive.org hinterlegt sind. Ich gehe mal davon aus, daß die Zahl bedeutend kleiner ist. Viele Grüße Nicolas
Nicolas S. schrieb: > Es gab ein Werkzeug, um tote Links zu suchen (funktioniert offline). Sie > stehen dann in einer Liste, die Du sicher mit Deinem C-Programm auch > automatisch bearbeiten könntest. das ist eine gute Idee. Ich könnte so erst mal die Links die nicht mehr gehen - also auf einen Fehler laufen durch txt-Dateien wo ich den Link dann einbette ersetzen lassen. Diese txt-Dateien könnte ich automatisch durchnumerieren lassen von 00000.txt bis 99999.txt. Mehr Links machen wohl keinen Sinn. > Ich schaue heute abend nach, wie dieses Programm hieß (wenn nicht vorher > schon jemand im Forum die Antwort schreibt). vielen Dank Nicolas. Mir ist nur nicht klar wie das offline gehen soll. Es müsste doch eine Prüfung erfolgen ob die Seite im Netz noch besteht. Um es sauber zu machen müsste man jeden Link selbst ansehen und überlegen ob man suchen will nach einer Alternative oder die Kopie in archive.org oder google-Cache nutzen will. Ggf. könnte man ein pdf erstellen von der Seite und das auf einem Datenträger anbieten. Der Aufwand für all das erscheint immens. Ist die Frage wer einen Nutzen davon hätte und bereit wäre sich am Aufwand zu beteiligen. Als one-man-show ist das schwer.
Nicolas S. schrieb: > P.S.: Generell ist es ja auch kein Problem, so ein Programm selbst zu > schreiben, wget sei dank. Aber es gibt soetwas definitiv schon. ich bekam mal einen Hinweis auf ein existentes Tool. Der Report des Tools war jedoch sehr lang und für mich schwer zu verstehen. Daher verfolgte ich das erstmal nicht weiter.
Nicolas S. schrieb: > das Finden der toten Links ist ja nur der erste Schritt. Das ginge > automatisch. Danke Nicolas. Das stimmt. Manchmal wurde jedoch die Seite aufgegeben und es kommt stattdessen so eine Werbeseite. Das sollte man erkennen. > Zweiter Schritt wäre das Testen, ob der tote Link bei archive.org ein > Pendant hat. Das ginge auch automatisch. leider ist das nicht so einfach. Seiteninhalte ändern sich. Nicht immer findet archive automatisch was. Oft musste ich mehrere Fassungen ansehen und mich dann für eine entscheiden. Bei meiner eigenen Seite gab es jahrelang fast jeden Monat einen neuen Stand. http://web.archive.org/web/*/http://www.mweisser.50g.com zeigt daraus nur 57 Schnappschüsse mit sehr großen Löchern ab 2005. Ich verwies auf Inhalte von www.in-for-mationen.de/InfoTexte. Die Seite verschwand und war anfangs noch in archive.org verfügbar. Dann setzte jemand in der robots.txt einen Leseschutz: Page cannot be crawled or displayed due to robots.txt. So kann man heute nicht mehr zugreifen. Was mache ich mit solchen Seiten? > Im dritten Schritt würden die Ersatz-Links in der eigenen Website mit > dem entsprechenden Hinweis ersetzt. Das ginge auch automatisch. das geht sicher. > Am Ende müßte man sich nur mit den übrigen Links beschäftigen, die tot > sind und nicht bei Archive.org hinterlegt sind. Ich gehe mal davon aus, > daß die Zahl bedeutend kleiner ist. ja. Am Ende sind das weniger. Mir wird klar daß man um es gut zu machen den Verstand nutzen muss. Automatisch geht nur manches. Verweise auf Inhalte auf meiner Festplatte sind automatisch schwer machbar. Manchmal mag es auch Schreibfehler geben. Manche Links erscheinen nicht mehr so wichtig. Das ist ein großes arbeitsintensives Feld. Die Beschäftigung damit kostet viel Zeit - bietet aber auch die Chance für substanzielle Verbesserung. Nur wer finanziert das alles? Seit 13 Jahren stemme ich das alleine. Viele Grüße Matthias
Ich hatte den Zettel, daß ich das Linksuchtool noch suchen wollte doch tatsächlich ungelesen in der Hosentasche von der letzten Woche. Es hieß "Xenu". http://home.snafu.de/tilman/xenulink.html
Nicolas S. schrieb: > Es hieß "Xenu". http://home.snafu.de/tilman/xenulink.html Vielen Dank Nicolas !
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.