Hallo zusammen, ich arbeite gerade mit CodeBlocks. Immer wenn ich eine cpp-Datei zum ersten mal kompiliert und erstellt habe ist alles ok. Wenn ich den Quellcode ändere und dann erneut kompiliere/erstelle also den Build and Run Button in Codeblocks drücke kommt folgende Meldung: >cannot open output file C:\Programmierung\C++\Kapitel 7\7.3 error >handling.exe Permission denied| >||error: ld returned 1 exit status| Ich hatte früher das Problem nie, wie kann ich das Problem loswerden?
Gast
#4993735
Val H. schrieb: > Hallo zusammen, > > ich arbeite gerade mit CodeBlocks. Immer wenn ich eine cpp-Datei zum > ersten mal kompiliert und erstellt habe ist alles ok. Wenn ich den > Quellcode ändere und dann erneut kompiliere/erstelle also den Build and > Run Button in Codeblocks drücke kommt folgende Meldung: > >>cannot open output file C:\Programmierung\C++\Kapitel 7\7.3 error >>handling.exe Permission denied| > >>||error: ld returned 1 exit status| > > Ich hatte früher das Problem nie, wie kann ich das Problem loswerden? Mach mal den Space zwischen Kapitel und 7 weg. Grüsse, René
René H. schrieb: > Mach mal den Space zwischen Kapitel und 7 weg. Alle Dateinamen in diesem Ordner haben Spaces, was sollte es bringen den Space beim Ordner zu entfernen? Ich verstehe nicht was es mit dem Leerzeichen auf sich haben soll.
Gast
#4993740
Val H. schrieb: > René H. schrieb: > Mach mal den Space zwischen Kapitel und 7 weg. > > Alle Dateinamen in diesem Ordner haben Spaces, was sollte es bringen den > Space beim Ordner zu entfernen? Dann mach alle raus. ;) Grüsse, René
Es ist wohl einfach schon zu spät :-)
Gast
#4993748
Val H. schrieb: > Es ist wohl einfach schon zu spät :-) Es ist nie zu spät, die Spaces zu entfernen. Warum machst du das nicht einfach mal? Oft ist das die Ursache für aufgetretene Fehler...
Na ja, das Gerücht mit den Leerzeichen hält sich unausrottbar. Die Fehlermeldung besagt, das der linker keine Zugriff auf die Datei handling.exe hat. Meine Glaskugel sagt mir, das handling.exe das Programm ist, das erstellt werden soll. Die Standardursache für den Fehler ist, saß handling.exe noch irgendwo läuft. Entweder beendet sich das Programm nicht ordnungsgemäß, oder du hast es nicht beendet. Oliver
Oliver S. schrieb: > Na ja, das Gerücht mit den Leerzeichen hält sich unausrottbar. Leerzeichen in Dateinamen sind kein Gerücht sondern ein Ärgernis und eine real existierende Fehlerquelle in vielen Situationen und eine potentielle Fehlerquelle in allen Situationen in denen Pfade zwischen einzelnen Prozessen über die Kommandozeile herumgereicht werden. Zum Glück kann man das ganz einfach ausschließen indem man sie einfach vermeidet. Im Vorliegenden Fall würd ich aber mal einfach die .exe beenden bevor ich versuche sie neu zu erzeugen und zu überschreiben, Windows besteht nämlich schwachsinnigerweise selbst im Jahre 2017 immer noch darauf darauf jede .exe exklusiv zu sperren solange der zugehörige Prozess läuft (das ist übrigens auch der Grund warum jedes popelige Windows Update immer gleich ein oder zwei Neustarts braucht, das bekommen die in diesem Leben nicht mehr gebacken).
Danach kann ich mal schauen ob die exe noch irgendwo im Hintergrund läuft. Hatte das Problem aber vorher nie, ich frage mich halt warum das jetzt plötzlich ein Problem ist. die Leerzeichen kann ich gerne mal alle entfernen, ist ja kein Aufwand.
Mal davon abgesehen: Ein Tutorial von einem Autor der seinen Schülern beibringt Leerzeichen in die Pfadnamen zu machen (indem er mit diesem Beispiel voran geht) würde ich generell schon mal skeptisch betrachten, der Autor hat offensichtlich null praktische Erfahrung. Wenn man praktische Erfahrung hat erzeugen Leerzeichen und Sonderzeichen im Pfadnamen nämlich schon beim bloßen Betrachten körperliches Unbehagen. Das ist genauso wie Motorrad fahren mit Sandalen, kurzen Hosen und T-Shirt (vor den Augen der Fahrschüler): So ein Fahr(lehr)er hat offenbar null Erfahrung und hat sich noch nie bei 50 km/h auf die Fresse gelegt. Von so einem würd ich mir keine Tricks beibringen lassen wollen. Dummerweise weiß man das als Anfänger nicht, erst wenn man es zum ersten Mal selber erlebt.
Auch Leerzeichen gehen doch als eindeutig definierte Zeichen durch oder etwa doch nicht?
Das Programmvezeichnis in Windows heißt seit Urzeiten "program files", auch in den deutschsprachigen Versionen. Windows hat keinerlei Probleme mit den Leerzeichen, auch nicht auf der Kommandozeile. So langsam sollten sich die linuxoiden Tools doch mal dran gewöhnt haben... Oliver
Gast
#4993986
Val H. schrieb: > Auch Leerzeichen gehen doch als eindeutig definierte Zeichen durch oder > etwa doch nicht? Leider sind sie eindeutig als Trenner für Kommando Zeilen Argumente definiert. Wenn du das in einer Shell aufrufst: gcc.exe Datei 1.c Datei 2.c Dann sucht er nach 4 Dateien, mit den Namen "Datei", "1.c", "Datei", "2.c". Das ist das Problem. Unter Linux/Unix ist das nicht so schlimm, denn da kann man Unter Prozesse auch ohne shell, mit exec () aufrufen, und die Argumente getrennt übergeben (das argv array), so dass der gcc weiß was zusammen gehört. Unter Windows kann man aber die Argumente nicht einzeln, sondern nur als ein langer String übergeben.es hat sich so eingebürgert, dass man einzelne Argumente mittels Anführungszeichen markiert, um Leerzeichen mitzunehmen. Wenn das Argument aber selbst Anführungszeichen enthält, muss man die escapen. Das aufgerufene Programm muss das wieder rückgängig machen. Da das relativ kompliziert ist, wird das nicht von allen Programmen immer sauber gemacht, was zu Problemen führen kann. Das Problem sind also hauptsächlich unixoide Tools, die unter Unix den Komfort des argv Arrays gewohnt sind, aber für Windows nicht an den primitiven Argument String angepasst sind.
Oliver S. schrieb: > So langsam sollten sich die linuxoiden Tools doch mal dran gewöhnt > haben... Nein, der deformierte (zum Glück jetzt absterbende) Schwanz wird bestimmt nicht mehr mit dem Hund wedeln.
Gast
#4994536
Also habe es jetzt getestet, auch die Entfernung aller Leerzeichen hat nichts am Problem geändert. Ich kann auch über den Taskmanager die evtl. nicht beendete exe-Datei nicht finden.
Gast
#4994549
Versuch doch einfach mal die .exe im explorer zu löschen/verschieben. Vielleicht hilft dir die erscheinende Fehlermeldung. Manchmal blockieren auch Virenscanner den Zugriff auf .exe Dateien sodass der Linker die nicht beschreiben kann. Prüf das mal...
Gast
#4994560
Dr. Sommer schrieb: > Manchmal blockieren auch Virenscanner den Zugriff auf .exe Dateien Das wäre denkbar, da habe ich nicht dran gedacht, danke für den Tipp.
Gast
#4994567
Das mit dem Antivirus wars auch nicht. Wenn ich eine vorhandene cpp-Datei unter einem anderen namen speichere geht wieder alles, aber nur genau ein mal. Was ich ich noch bemerkt habe, wenn ich ca. 5min. warte, dann kann ich den Compile und Build Vorgang problemlos wiederholen. Es muss also doch so sein, dass Dateien nicht richtig beendet worden sind und deshalb die Fehlereldung kommt. Da ich aber nirgends einen Prozess sehen kann der auf meine Datei hinweist, wüsste ich wirklich nicht mehr was man da noch tun kann. Evtl. liegts auch an den Rechten? Aber ich bin Adimn an meinem PC.
Gast
#4994573
Ich glaube diese Fehlermeldung ist ein guter Grund mit dem Programmieren aufzuhören.
Gast
#4994581
valheru schrieb: > Ich glaube diese Fehlermeldung ist ein guter Grund mit dem Programmieren > aufzuhören. Nicht doch! Ich hatte da mal so etwas ähnliches. Ich habe in einem Programm temporär Dateien geschrieben und nachdem ich sie nicht mehr benötigt habe gelöscht. Wenn ich das gGanze in eine Schleife gepackt habe ( also mehrfach hintereinander ausführen), dann hat es beim zweiten Mal gekracht, weil die Datei angeblich in Benutzung ist. Im Explorer z.B. war sie aber nicht mehr zu sehen. Nach Beenden des Programmes und Windowsneustart hat alles wieder funktioniert, aber genau nur einmal. Nach langen REcherchen habe ich dann herausgefunden, daß Win die Dateien erst mal nicht wirklich löscht sonder nur versteckt und zum Löschen markiert. Das Ganze ist das Selbe wie der ominöse Roamingordner der irgendwann mal auftaucht aber nicht wirklich da ist im Explorer. Mach mal einen Neustart und Kompiliere dann noch mal. Es wird wahrscheinlich funktionieren. Leerzeichen im Dateinamen sind zwar nicht toll - ich vermeide sie i.d.R - , sollten aber mittlerweile nichts mehr ausmachen und wenn es vorher funktioniert hat, dann ist dies ganz bestimmt nicht die Ursache. Ist vor dieser Veränderung vielleicht ein Windowsupdate gelaufen?
Es gab da mal so ein Tool für Windows das fügte einen Eintrag ins Kontextmenü ein "who is locking this file" und dann konnte man sehen wer verantwortlich ist und mit Gewalt das Lock entfernen oder den verantwortlichen Prozess beenden.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.