Was kommt denn bei einem raus?

Benenne die Dateien mal um. Also ohne das & im Dateinamen.

Auch aus Windows heraus nicht?
Manchmal kann man aber auch mit dem MC noch was erreichen.

In der bash ist doch das "&" ein Zeichen für "hier ist die Zeile zuende; diesen Befehl im Hintergrund ausführen; alles weitere ist der nächste Befehl". Genau das passiert dann auch: Zuerst wird "file bacardi" im Hintergrund ausgeführt und die Datei "bacardi" gibt es nicht, aber die Meldung dazu kommt wahrscheinlich verzögert, weil i.d.R. die bash schneller als "file" ist und daher schon mit dem nächsten vermeintlichen Befehl weitermacht "rufus01_m.jpg", nur gibt es diesen Befehl natürlich nicht und dann sieht man den entsprechenden Fehler. Gleich danach ist "file" aus dem Hintergrund dann auch fertig und meldet, dass es die Datei nicht gefunden hat. Umrandet wird das natürlich von den Meldungen, dass file zunächst im Hintergrund startete (mit [Jobnummer] und PID), zwischen drin wird schonmal das neue Prompt angezeigt, weil im Fordergrund ja nix mehr zu tun ist, und zum Schluß kommt dann die Meldung, dass der Hintergrundprozess "file" fertig ist (mit [Jobnummer] Exit-Status und Befehl hinten). Ist doch alles wie erwartet. Siehe u.a. "man bash" in Sektion JOB CONTROL .

PS: Man kann das "&" escapen oder quoten, z.B. so:

Die Erklärung von oziris ist zwar korrekt, aber ich bezweifle das es wirklich daran gelegen hat. Einsollte sogar von der Bash abgearbeitet bzw. nach TAB expandiert werden.
Entweder eine zu alte Bash oder eine Sony-Cam. Probiers mal mit der Z-Shell aus um die Bash als Fehlerquelle auszuschließen.

file bacardi&rufus01_m.jpg interpretiert die bash als liste mit
1. dem kommando file bacardi, das in einer subshell in den hintergrund geschickt wird und
2. dem kommando rufus01_m.jpg

also quoten hilft auf jeden fall

Moin,

Zitat

Original von VolkerK
...die nutzt schon immer so lange Namen.

Lange Namen sind ja nicht das Problem.

Zitat

..Also die Ratschläge mit quoten, escapen u. auch mit der Z-Shell nutzen leider nichts. ...

Weil das & tatsächlich anders interpretiert wird - das haben linuxerr und oziris schon ganz richtig erklärt. Für mich völlig logisch und war auch mein erster Gedanke als ich den ersten Beitrag gerade las. Es mag Shells geben, die das anders interpretieren, aber die sind wohl die Ausnahme.

Sonderzeichen, besonders ein "&" gehören einfach nicht in Dateinamen. Ebenso wie "$".

Gruß
Jürgen ;-)

Das ist wohl ein Bug im Dateimananger. Wegen solchen Bugs vermeidet man es zwar, diese Zeichen zu verwenden (schon allein, um es sich zu erleichtern, eigene Scripts zu schreiben), man kann es aber eigentlich keinem vorwerfen, wenn er sie trotzdem verwendet. Man sollte diesen Bug versuchen zu melden bzw. nachsehen, ob er bereits gemeldet ist.

Also ich weiß nicht, ob man das als Bug bezeichnen kann. Sicher mag es in der GUI nicht so entscheidend sein wie in der Shell, was für Namen man benutzt, aber letztendlich nutzt ja auch die GUI irgendwo eine Shell für Dateioperationen. Ich arbeite seit über 20 Jahren mit verschiedensten Unix- und Linux-Versionen und für mich erscheint es völlig logisch und normal, dass das mit dem "&" nicht funktioniert, da ich auch mit anderen Sonderzeichen immer mal wieder irgendwo angestoßen bin. Ich rate daher immer von der Benutzung von Sonderzeichen - gerade unter Linux - ab.

Aber es ist mir auch vollkommen klar, dass man das einem "normalen" Benutzer nicht so einfach rüberbringen kann. Heutzutage muss ja scheints alles so abgesichert sein, dass man nix falsch machen kann.

J ;-)

Zitat

Original von DriverAber es ist mir auch vollkommen klar, dass man das einem "normalen" Benutzer nicht so einfach rüberbringen kann. Heutzutage muss ja scheints alles so abgesichert sein, dass man nix falsch machen kann.

Dem muss ich nach ~5 Jahren Arbeit als freiberuflicher IT-Consultant energisch widersprechen. Der Einfallsreichtum von Idioten ist faszinierend und ueber jeden Zweifel erhaben (damit meine ich niemanden aus diesem Thread).

Also ich find' schon, dass wir Programmierer die Pflicht haben, alles ordentlich zu escapen, schon allein, um Code-Injections, also Sicherheitslücken die das ausnutzen, zu verhindern. Natürlich gibt es Spezialfälle, wo man sowas z.B. aus Performance-Gründen nicht macht, aber das muss mit dem späteren Benutzer geklärt und dokumentiert werden. Schießlich sind theoretisch alle Zeichen erlaubt, die auf der Tastatur zu finden sind bzw. vom Dateisystem oder dem engestellten Zeichensatz unterstützt werden.

Zitat

Original von ozirisSchießlich sind theoretisch alle Zeichen erlaubt, die auf der Tastatur zu finden sind bzw. vom Dateisystem oder dem engestellten Zeichensatz unterstützt werden.

Theoretisch.
http://de.wikipedia.org/wiki/Dateiname#Z…ichen_und_Namen

;-)

Das gildet ja hauptsächlich für Windosen und deren Dateisysteme.
Bei GNUs und deren Dateisystemen kann man quasi schon alles benutzen, außer natürlich dem "/" und man darf Dateien/Verzeichnisse natürlich nicht einfach nur "." oder ".." nennen, weil das alles spezielle Bedeutungen hat.
Sowas sollte man auf einem GNU-System mit passendem Dateisystem problemlos durchziehen können:... und auch Umlaute usw. sollten gehen, wenn die entsprechenden Zeichensätze und Schriftarten vorhanden und eingestellt sind (habe ich bei mir z.B. nicht; anderenfalls gibt's seltsame Platzhalter).