Batchdatei: Aufruf von rm produziert Fehler

Bernd schrieb:
> Der unterstehende Aufruf von rm gibt einen Fehler zurück.
>
> Was teilt mir make, rm mit?

Ach es geht um ein Makefile, und nicht um ein Batchfile?
Auf welche Betriebssystem bist du denn unterwegs und wie sieht die 
Make-Regel aus?

Peter II schrieb:
> Nase schrieb:
>> Blöde Frage aber:
>> Macht die bescheuerte Windows-Kommandozeile überhaupt Globbing?
>
> nein zum glück nach, was Linux macht das da bescheuerte;
>
> die bekommt man immer mal bei * das die Komadozeile zu lang ist.

Hab ich noch nie bekommen. Auf meinem System darf die Kommandozeile 2 MB 
lang sein. Wenn du soviele Dateien in einem einzelnen Verzeichnis hast, 
solltest du eh mal darüber nachdenken, die besser zu organisieren.
Wenn man die GNU-Tools unter Windows benutzt, kommt man aber öfter an 
die Grenze, weil dort die Limits viel niedriger sind.

> Den * hat die Anwendung zu bearbeiten.

Sehe ich nicht so.

Für den Fall hier fallen mir mehrere Möglichkeiten ein:

-Der Verzeichnispfad, in dem die Dateien liegen, ist zu lang. Auch diese 
Länge ist unter Windows viel zu stark eingeschränkt.

- Der Name einer der Dateien enthält irgendwelche "verbotenen" Zeichen.

- Das Dateisystem hat einen Fehler.

Peter II schrieb:
> Aus dem Grund finde ich die Windows-Lösung hier besser.

Das Problem bei der Windows-Lösung ist nur, dass jede Anwendung ihre 
teils sehr eigenen Vorstellungen davon hat, welche Arten von Globbing 
wie zu interpretieren sind und ob überhaupt. Genau wie der Wildwuchs 
voneinander inkompatibler und/oder unvollständiger oder nicht 
vorhandenet Möglichkeiten, Anführungszeichen etc. zu escapen. Schon 
blöd, wenn man ein etabliertes Escapezeichen als Pfadtrenner verwendet 
und dann dessen Funktion nicht gleichwertig ersetzt.

Peter II schrieb:
> Rolf M. schrieb:
>> Hab ich noch nie bekommen. Auf meinem System darf die Kommandozeile 2 MB
>> lang sein. Wenn du soviele Dateien in einem einzelnen Verzeichnis hast,
>> solltest du eh mal darüber nachdenken, die besser zu organisieren.
>
> ist schon nach jeden Tag aufgeteilt. Noch mal aufteilen macht keinen
> sinn mehr.
>
> da kann man nicht mal rm *.log machen ohne einen Fehler zu bekommen. Da
> muss man sich die finger mit find *.log --exec rm {} \; (oder so)
> brechen.

Du hast ernsthaft jeden Tag soviele Log-Files, daß deren Namen zusammen 
länger als 2 MB sind? Wie geht denn das? Wenn jedes Logfile einen 20 
Zeichen langen Namen hat, wären das 100.000 Logfiles pro Verzeichnis und 
über einen kompletten Tag verteilt im Schnitt mehr als ein Logfile pro 
Sekunde. Irgendwas stimmt doch da nicht.

Bernd schrieb:
> Die eigentliche Funktion - löschen der Dateien - funktioniert.

Na dann ist es doch o.k.
Unter Windows kannst Du statt rm das ERASE oder DEL-Kommando nehmen.

Dirk schrieb:
> Peter II schrieb:
>
>> find *.log --exec rm {} \;
>
> Besser find . -name '*.log' -print0 | xargs -0 rm
>
> Bei Bedarf noch ein -maxdepth dazu

Nein. Besser find -name '*.log' -exec rm {} +
Mit dem + wird rm auch für mehrere Treffer aufgerufen und spart die 
Pipe.

Dirk schrieb:
> Peter II schrieb:
>
>> find *.log --exec rm {} \;
>
> Besser find . -name '*.log' -print0 | xargs -0 rm
>
> Bei Bedarf noch ein -maxdepth dazu

Du hast aber schon mitbekommen, daß es gerade darum geht, nicht alle 
Dateien einem einzigen rm-Aufruf zu übergeben?

Rolf M. schrieb:
> Du hast aber schon mitbekommen, daß es gerade darum geht, nicht alle
> Dateien einem einzigen rm-Aufruf zu übergeben?

Beide Varianten - -exec ... + oder mit xargs - verteilen die Argumente 
so, dass die Kommandozeile nicht zu lang wird, ohne dadurch auf das 
Zusammenfassen zu wenigen Aufrufen zu verzichten.

Malte S. schrieb:
> Rolf M. schrieb:
>> Du hast aber schon mitbekommen, daß es gerade darum geht, nicht alle
>> Dateien einem einzigen rm-Aufruf zu übergeben?
>
> Beide Varianten - -exec ... + oder mit xargs - verteilen die Argumente
> so, dass die Kommandozeile nicht zu lang wird, ohne dadurch auf das
> Zusammenfassen zu wenigen Aufrufen zu verzichten.

Ok, das war mir nicht bewußt.

Planlos schrieb:
> Peter II schrieb:
>> find hat direkt eine Option zum löschen,
>
> find . -name *.log -delete

So hast du aber den entscheidenden Teil, nämlich das Auswerten von *.log 
durch die Shell gerade nicht vermieden.

Peter II schrieb:
> richtig ist es glaube ich so
>
> find . -name "*.log" -delete

Besser wäre wie schon in vorherigen Beispielen gezeigt '*.log' statt 
"*.log". Letzteres wertet z.B. immer noch Umgebungsvariablen aus. Wenn 
also irgendwo mal in einem Dateinamen ein $ vorkommt, funktioniert das 
nicht mehr richtig.

Rolf M. schrieb:
> Besser wäre wie schon in vorherigen Beispielen gezeigt '*.log' statt
> "*.log". Letzteres wertet z.B. immer noch Umgebungsvariablen aus. Wenn
> also irgendwo mal in einem Dateinamen ein $ vorkommt, funktioniert das
> nicht mehr richtig.

Nein. Nur wenn in "*.log" ein $ vorkäme, wäre das der Fall. Die 
expandierte Form von *.log wird nicht erneut auf Variablen etc. 
ausgewertet.
Dennoch ist ' generell besser, wenn nicht ausdrücklich Expansion 
gewünscht ist.
Wenn es nur um ein einzelnes * geht, tut's natürlich auch \*.log

Peter II schrieb:
> Rolf M. schrieb:
>> Besser wäre wie schon in vorherigen Beispielen gezeigt '*.log' statt
>> "*.log". Letzteres wertet z.B. immer noch Umgebungsvariablen aus. Wenn
>> also irgendwo mal in einem Dateinamen ein $ vorkommt, funktioniert das
>> nicht mehr richtig.
>
> das verstehe ich jetzt nicht.
>
> wenn find der Parameter "*.log" übergeben wird, steht dann ohne " in
> argv drin. Was hat das mit den gefundenen Dateien zu tun?

Stimmt schon. Ich nutze aus dem oben genannten Grund aus Gewohnheit 
immer '', wenn ich nicht explizit will, daß Umgebungsvariablen 
ausgewertet werden. Hier ist das aber an sich kein Problem.

Um mal auf das eigentliche Problem zurückzukommen (die Diskussion
war ja völlig in eine andere Richtung gegangen):

Bernd schrieb:

> Was teilt mir make, rm mit? Wo ist der Fehler?

In der Windows-Version von (GNU) rm, welches du wohl hier aufrufst.

> Was ist zu ändern?

rm wäre zu reparieren. :-)

Es sollte nie "invalid argument" produzieren, sondern bestenfalls
"no such file or directory", wobei letzteres bei Option -f zu
ignorieren ist (damit würde dein "make" fortsetzen).

Die Bourne-Shell übergibt übrigens auch auf Unixen tatsächlich
*.eps etc., wenn keine Datei auf das Muster passt, aber da das
rm unter Unix dann in der Tat "no such file or directory" liefert,
geht's bei rm -f eben weiter.

Der Würgaround in unseren Makefiles (so sie sowohl auf Windows als
auch Unix/Linux lauffähig sein sollen) ist es, jeweils eine solche
Datei vorher anzulegen:

1

C:\Users\Host\Desktop\AVR-Projekte\Fahrrad>make clean

2

echo hi > foo.o

3

echo hi > foo.eps

4

echo hi > foo.png

5

echo hi > foo.pdf

6

echo hi > foo.bak

7

rm -rf *.o fahrrad.elf *.eps *.png *.pdf *.bak

8

rm: Aufruf von lstat für "*.eps" nicht möglich: Invalid argument

9

rm: Aufruf von lstat für "*.png" nicht möglich: Invalid argument

10

rm: Aufruf von lstat für "*.pdf" nicht möglich: Invalid argument

11

rm: Aufruf von lstat für "*.bak" nicht möglich: Invalid argument

12

make: *** [clean] Fehler 1

Damit hat das rm dann was, was es wirklich immer löschen kann, und
es geht weiter.

Alternativ kannst du vor die rm-Aufrufe im Makefile ein Minuszeichen
schreiben.  Damit bekommst du zwar immer noch eine Fehlermeldung,
aber "make" macht dennoch weiter.

Jörg W. schrieb:
> Damit hat das rm dann was, was es wirklich immer löschen kann, und
> es geht weiter.

Unter Windows beschwert sich DEL auch, wenn es nichts zu löschen findet.
Dagegen hilft dann ein Guard:

1

if exist *.tmp del *.tmp

Peter D. schrieb:
> Dagegen hilft dann ein Guard:

Entegen der Überschrift ging's hier aber um ein Makefile, nicht um
ein Batchfile.

Jörg W. schrieb:
> Entegen der Überschrift ging's hier aber um ein Makefile

Dafür gibt es auch Lösungen:

http://stackoverflow.com/questions/5553352/how-do-i-check-if-file-exists-in-makefile

Peter D. schrieb:
> Dafür gibt es auch Lösungen:

Die ich allerdings allesamt noch krückiger finde als „unsere“ Variante,
jeweils eine Dummy-Datei vorher anzulegen.

Aber wie schon geschrieben: der eigentliche Bug ist (meiner Meinung
nach) in GNU rm selbst.  „rm -f irgendwas“ heißt „lösche ‚irgendwas‘,
sofern es existiert, ohne weitere Rückfrage, halt' aber die Klappe,
wenn es nicht existiert“.

Jörg W. schrieb:
> Die ich allerdings allesamt noch krückiger finde als „unsere“ Variante,
> jeweils eine Dummy-Datei vorher anzulegen.

Die mit dem test Kommando scheint mir recht brauchbar zu sein.

Peter D. schrieb:
> Jörg W. schrieb:
> Die ich allerdings allesamt noch krückiger finde als „unsere“ Variante,
> jeweils eine Dummy-Datei vorher anzulegen.
>
> Die mit dem test Kommando scheint mir recht brauchbar zu sein.

Geht nicht, wenn das make mit cmd.exe statt einer Unix-Shell
arbeitet.  Been there, done that.

echo hi > dummy.file

geht in beiden Shells.

Jörg W. schrieb:
> Geht nicht, wenn das make mit cmd.exe statt einer Unix-Shell
> arbeitet.

D.h. die /utils/bin/test.exe gibt es unter Windows nur bei GCC 
Compilern?

Peter D. schrieb:
> Jörg W. schrieb:
> Geht nicht, wenn das make mit cmd.exe statt einer Unix-Shell
> arbeitet.
>
> D.h. die /utils/bin/test.exe gibt es unter Windows nur bei GCC
> Compilern?

Mit dem GCC selbst hat das nicht direkt was zu tun, irgendwer muss
halt die entsprechenden Unix-Kommandos überhaupt installiert
haben (so wie auch das rm.exe).

Altes WinAVR, Atmel Toolchain älterer Version und aktuelle Version
sind da leider alle leicht unterschiedlich, was sie genau mitbringen.

Das ist aber gar nicht so entscheidend, denn die entsprechende
if-Anweisung gehört zur Unix-Shell (die mit dem "fi" hintendran).