Daten kopieren/ Verschiedene Dateiträgerformate

SG1

Hinzufüger schrieb:

Bei Windows dürfte das zwar egal sein,

Windows nutzt auch / als Verzeichnisseparator, unterstützt also ziemlich sicher auch kein / in Dateinamen. Ganz allgemein ist Windows deutlich restriktiver, was ein gültiger Dateiname ist, als Linux.

nman

Ergänzung: Die Unterstützung langer Dateinamen muss man nicht extra aktivieren.

hustbaer

SG1 schrieb:

Ganz allgemein ist Windows deutlich restriktiver, was ein gültiger Dateiname ist, als Linux.

???

nman

Naja, Dateinamen unter Windows dürfen vmtl. keine Doppelpunkte oder Pipes enthalten, oder? Backslashes wohl auch nicht. Nicht, dass das je wehtäte, aber ich nehme an, dass SG1 das meinte.

hustbaer

@nman
Ist mir aber lieber als ein OS wo man dauernd Probleme bekommt wenn man Spaces in Dateinamen verwendet

nman

Weiß nicht so recht was du meinst, ich hatte noch nie Schwierigkeiten mit Spaces in Dateinamen. Muss man eben – genauso wie unter Windows auch – escapen oder quoten oder was auch immer.

Aber SG1 hat das ja auch nicht wertend gemeint. Dass Windows diesbezüglich restriktiver ist, ist ja nicht per se gut oder schlecht.

Du meinst wahrscheinlich in der Bash-Autocompletition, da sind Leerzeichen in den Dateinamen wirklich doof. In der Windowsumgebung wird so gut wie alles komplettiert, auch klein- und grossschreibung spielt hier keine Rolle. Ist vielleicht nur Einstellungssache, in den Default-Settings ist das aber so.

hustbaer

Ich meine Globbing.
Die Sternderl-Sache halt.
Versuch mal mit rm * alle Files in einem Verzeichnis zu löschen, wenn da Files mit Spaces im Filenamen drin liegen.
Vielleicht mit nem File namens "-rf . ext" drinnen.

Klar, ist keine Einschränkung auf die Filenamen die Linux bzw. die unter Linux üblichen File-Systeme grundsätzlich erlauben.
Praktisch ist es aber ein Problem, weil unter Linux dummerweise immer noch verdammt viel mit Spucke und Bindfaden (=shell scripts) zusammengebunden ist.

nman

Verstehe ehrlich gesagt überhaupt nicht was du meinst.

~/foo % touch 'Hallo hustbaer'
~/foo % ls
Hallo hustbaer
~/foo % rm *
zsh: sure you want to delete all the files in ~/foo [yn]? y
~/foo % ls
~/foo %

Klar, das war jetzt natürlich zsh, nicht Bash, weil ich kein Bash-User bin. Aber mit bash sieht das nicht auch anders aus.

~/foo$ touch 'Hallo hustbaer'
~/foo$ ls
Hallo hustbaer
~/foo$ rm *
~/foo$ ls
~/foo$

Shellskripte sind da nirgends involviert. Glob ist seit den Siebzigern ein Shell-Builtin.

BashBash: Kann mich nicht erinnern, dass die Standard-Bash-Completion je Schwierigkeiten mit Leerzeichen im Dateinamen gemacht hätte. Schon bei meinen ersten Linux-Gehversuchen in den Neunzigern hat die brav alle Spaces escaped.

nman

Ach ja, noch ein Nachtrag zu der "-rm ."-Geschichte: Ich werde dabei gewarnt, dass das kein gültiger Aufruf ist und es wird nichts gelöscht. Wenn man zum Löschen statt rm * einfach rm ./* verwendet, funktioniert alles genau wie erwartet.

hustbaer

OK.
Dann versuch das ganze mit einem echten Programm. Also etwas was nicht direkt in der Shell eingebaut ist.

Christoph

hustbaer schrieb:

OK.
Dann versuch das ganze mit einem echten Programm. Also etwas was nicht direkt in der Shell eingebaut ist.

Wenn du "./mein_programm *" aufrufst, wird das genau wenig Probleme machen wie "rm *", weil Leerzeichen von der Shell beim globbing korrekt behandelt werden.

Wenn das Programm selber über die Verzeichniseinträge iteriert mit readdir(), wird es auch keine Probleme mit Leerzeichen bekommen.

Einzige Ausnahme (von der ich weiß) sind schlecht geschriebene Shell-Skripte, bei denen das Selber-Iterieren kein Iterieren ist, sondern ein Hack über stdout und word splitting:

for i in `ls *`; do ...; done

statt einfach

for i in ./*; do ...; done

hustbaer

OK.
Was ist dann der Grund dass bei Linux Programmen kaum bis gar nie Pfade mit Spaces verwendet werden?
Ich hab öfters gehört dass die Shell damit nicht korrekt umgehen kann. Wenn das nicht der Grund ist, was dann?

nman

Cargo Cult? Keine Ahnung.

Ich verwende seit den späten Neunzigern unixoide Betriebssysteme und hatte noch nie Probleme mit Leerzeichen – die von Christoph geschilderten mal ausgenommen.

Was ist dann der Grund dass bei Linux Programmen kaum bis gar nie Pfade mit Spaces verwendet werden?

Moment, was meinst du denn hiermit eigentlich genau? Wo sollen denn Pfade mit Leerzeichen nicht oder schon verwendet werden? Sorry, ich stehe offensichtlich gerade sehr auf der Leitung.

Christoph

hustbaer schrieb:

Was ist dann der Grund dass bei Linux Programmen kaum bis gar nie Pfade mit Spaces verwendet werden?

Ein Grund, den ich mir vorstellen kann: In der Shell ist es etwas nervig, mit Leerzeichen im Dateinamen zu arbeiten. Tabvervollständigung funktioniert zwar, aber erzeugt backslash+space oder setzt gleich den ganzen Namen in quotes.

Dasselbe Problem hat man vermutlich bei Dokumentation. Jetzt kann man unmissverständlich /home schreiben. Mit Leerzeichen müsste man das wohl quoten, um es von zwei Pfaden zu unterscheiden. Simples word splitting an spaces macht Englisch und Deutsch leider auch.

audacia

Ein Kollege von mir hat mal einen halben Tag gegen seine Shell gekämpft, weil irgendein Verzeichnis sich einfach nicht löschen lassen wollte. Ursache: trailing space im Verzeichnisnamen.

Mir selbst passiert es öfter, daß irgendwelche GCC-Makefiles nicht gehen, nur weil ich meinen Code in "...\Eigene Dateien\..." liegen habe. Dann muß ich in einem leerzeichenfreien Ordner eine Junction aufs Verzeichnis anlegen, damit es klappt.

Vermutlich tragen derartige Erlebnisse dazu bei, daß Leerzeichen auf Unixoiden insgesamt gemieden werden.

hustbaer

nman schrieb:

Was ist dann der Grund dass bei Linux Programmen kaum bis gar nie Pfade mit Spaces verwendet werden?
Moment, was meinst du denn hiermit eigentlich genau? Wo sollen denn Pfade mit Leerzeichen nicht oder schon verwendet werden? Sorry, ich stehe offensichtlich gerade sehr auf der Leitung.

z.B. Default-Namen für diverse Verzeichnisse (Install Pfade etc.).
Auf Windows hast du z.B. schonmal vom System aus Pfade wie
`c:\Program Files

c:\Program Files (x86)

c:\Windows\Downloaded Installations

c:\Windows\Offline Web Pages

etc.`

Und bei ThirdParty Programmen gibt's auch sehr häufig Pfade mit Leerzeichen. Natürlich gibt's auch hier Ausnahme, das dumme DDK mag z.B. keine Leerzeichen im Pfad (ist mittlerweile möglicherweise gefixt, das Win2000 DDK mochte auf jeden Fall keine).

Bei Linux Programmen ist mir das noch nicht untergekommen. Mag natürlich auch daran liegen dass ich selbst kaum mit Linux arbeite

SeppJ

Der Hauptgrund gegen Leerzeichen sind meines Wissens nach tatsächlich schlecht geschriebene Shellscripte. Es ist durchaus schwierig, es immer überall korrekt zu machen, eben weil der inkorrekte Weg schneller und einfacher ist. Gleichzeitig sind Scripte sehr verbreitet; bei fast jeder Art von Software werkelt an der einen oder anderen Stelle irgendwo ein Script. Daher sind auch manchmal "professionelle" Produkte von inkorrekt programmierten Scripten betroffen.

Bei Windows hingegen käme niemals jemand auf die Idee, Batchdateien irgendwie ernsthaft einzusetzen, weil die Windowsshell ~~scheiße~~ eher bescheiden ist. Die expandiert ja nicht einmal Wildspaces in Dateinamen!

hustbaer

SeppJ schrieb:

Bei Windows hingegen käme niemals jemand auf die Idee, Batchdateien irgendwie ernsthaft einzusetzen, weil die Windowsshell ~~scheiße~~ eher bescheiden ist. Die expandiert ja nicht einmal Wildspaces in Dateinamen!

Verstehe nicht ganz worauf du mit dem letzten Satz hinaus willst.

nman

hustbaer schrieb:

Auf Windows hast du z.B. schonmal vom System aus Pfade wie
[…]

Ach so. Das gibt es bei unixoiden Betriebssystemen durchaus auch. Nur eben nicht für das Basissystem. Diverse Desktop-Environments und GUI-Tools verwenden aber schon immer wieder Leerzeichen in irgendwelchen Pfaden. Unter OSX, was ja auch nur ein Unix ist, sind Leerzeichen auch in Systempfaden anzutreffen ("~/Library/Application Support" uä.).

Irgendwelche Tools, die sich nach /opt installieren verwenden auch oft Leerzeichen im Pfad. Der große Unterschied ist vmtl. dass unter GNU/Linux die Standardpfade durch den FHS geregelt sind und es nicht so wichtig ist, dass Enduser mit den Ordnernamen irgendwas anfangen können. (Nicht dass sie das bei irgendeiner Plattform _wirklich_ könnten, aber bei "Program Files" uä. war das wohl zumindest der Gedanke.