wxpte
Anmeldungsdatum: 20. Januar 2007
Beiträge: 1182
Wohnort: Schäl Sick
|
OT: rklm schrieb: ... damit Namen mit Leerzeichen oder Newlines das nicht kaputt machen.
Dass Dateien Leerzeichen enthalten können kann ich ja noch nachvollziehen, aber Newlines? So einen Dateinamen überhaupt zu generieren, ist doch mit einigem Mehraufwand verbunden. Wer macht denn sowas? Moderiert von rklm: Abgetrennt von diesem Thema, da sich die Diskussion deutlich von der ursprünglichen Fragestellung entfernt.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12832
|
WinXP to Edgy schrieb:
Dass Dateien Leerzeichen enthalten können kann ich ja noch nachvollziehen, aber Newlines? So einen Dateinamen überhaupt zu generieren, ist doch mit einigem Mehraufwand verbunden. Wer macht denn sowas?
In der bash ist das einfach, aber auch in der sh geht das mit printf und dem passenden Quoting leicht: $ touch $'foo\nbar'
$ ls -l
total 0
-rw-rw-r-- 1 robert robert 0 Mai 16 15:23 foo?bar
$ echo foo*
foo
bar
$ touch "$(printf 'abc\ndef')"
$ ls -l
total 0
-rw-rw-r-- 1 robert robert 0 Mai 16 15:24 abc?def
-rw-rw-r-- 1 robert robert 0 Mai 16 15:23 foo?bar
$ for f in *; do echo "> $f <"; done
> abc
def <
> foo
bar <
|
wxpte
(Themenstarter)
Anmeldungsdatum: 20. Januar 2007
Beiträge: 1182
Wohnort: Schäl Sick
|
Ja, das schon; aber wer sich etwas ausführlicher mit der Shell befasst, der weiß doch eigentlich auch um die Tücken solcher Sonderzeichen. Meine Frage ging eher in die Richtung, wer auf die Idee kommen würde, mehrzeilige Dateinamen zu generieren. Bei den Leerzeichen kann ich das noch nachvollziehen, schließlich war ich selbst einmal hauptsächlich in der Windows-Welt unterwegs und kenne deshalb auch die Angewohnheiten eines durchschnittlichen Anwenders:
Dateien werden meist aus Anwendungen heraus angelegt beim Speichern einer neuen Datei wird, ohne viel nachzudenken, erst einmal alles eingegeben, was das Eingabefeld so nimmt. Leerzeichen gehören dazu, Zeilenumbrüche dagegen nicht
Meine Frage war also eher nicht nach dem "wie", sondern nach dem "warum". 😉
|
nitsnatsnok
Anmeldungsdatum: 27. Oktober 2013
Beiträge: 160
|
Also ich kopier gerne mal den (per OCR gewonnenen) Titel einer PDF-Datei raus und nenne die PDF-Datei so, und da ist nicht selten mindestens eine newline dabei. Natürlich beseitige ich die für gewöhnlich manuell, aber: Auf solchem Wege könnte ein Dateiname eine erhalten. Auch wenn du das natürlich nicht getan hast: Ich finde es falsch, vom Nutzer zu erwarten, sich an ein eigentlich ungerechtfertigtes Leerzeichenverbot zu halten – ist ja nicht so, dass die Shell damit nich umgehen könnte, nur will sie es eben für gewöhnlich nicht! Was diesbezüglich angepasst werden muss, ist nicht der Nutzer, sondern die Shell. ☺
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12832
|
nitsnatsnok schrieb:
Auch wenn du das natürlich nicht getan hast: Ich finde es falsch, vom Nutzer zu erwarten, sich an ein eigentlich ungerechtfertigtes Leerzeichenverbot zu halten – ist ja nicht so, dass die Shell damit nich umgehen könnte, nur will sie es eben für gewöhnlich nicht!
Naja, der Shell ist das herzlich egal, denn
Was diesbezüglich angepasst werden muss, ist nicht der Nutzer, sondern die Shell. ☺
genau: man muss sie nur richtig bedienen. ☺
|
ExcitedSpoon
Anmeldungsdatum: 17. Juli 2010
Beiträge: 226
Wohnort: /home/berlin
|
nitsnatsnok schrieb: Was diesbezüglich angepasst werden muss, ist nicht der Nutzer, sondern die Shell. ☺
Ich finde, dass genau andersherum eine Anpassung stattfinden sollte. Die Shell muss nicht leichter verständlich werden, sondern die Nutzer sollten mehr über die Fallstricke, in die man mit naivem Verhalten reinrennen kann, besser aufgeklärt werden. Ich will da kein Dialog-Fenster haben, das mir sagt: "du hast nen zeilenumbruch im dateinamen, are you sure?" Wer die shell benutzerfeundlicher haben will, der sollte sie meiden und auf GUI-Werkzeuge zurückgreifen, die hoffentlich das Problem lösen. Für die meisten Anwendungen gibt es auch unter Linux etwas, das den speziellen usecase bedient. Die shell bliebt die shell. Durch z.B. dieses Forum ist sie auch kein unlösbares mysterium, wenn ich an die (für mich gefühlt) fleißsten erklärbären denke: rklm, track, user unknown 👍
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12832
|
ExcitedSpoon schrieb: nitsnatsnok schrieb: Was diesbezüglich angepasst werden muss, ist nicht der Nutzer, sondern die Shell. ☺
Ich finde, dass genau andersherum eine Anpassung stattfinden sollte. Die Shell muss nicht leichter verständlich werden, sondern die Nutzer sollten mehr über die Fallstricke, in die man mit naivem Verhalten reinrennen kann, besser aufgeklärt werden. Ich will da kein Dialog-Fenster haben, das mir sagt: "du hast nen zeilenumbruch im dateinamen, are you sure?"
Ich glaube, Ihr meint beide ungefähr das gleiche: Ich denke, nitsnatsnok meinte genau das: die Shell selber muss sich nicht ändern, weil sie schon die Mittel mitbringt, mit solchen Namen ordentlich umzugehen. Aber die Autoren von Skripten sollten sie so schreiben, dass sie auch mit diesen merkwürdigen Namen umgehen können, damit die Benutzer der Skripte sich nicht anpassen müssen (also sich an ein "Leerzeichenverbot" halten).
Die shell bliebt die shell. Durch z.B. dieses Forum ist sie auch kein unlösbares mysterium, wenn ich an die (für mich gefühlt) fleißsten erklärbären denke: rklm, track, user unknown 👍
Danke! ☺
|
nitsnatsnok
Anmeldungsdatum: 27. Oktober 2013
Beiträge: 160
|
Exakt das meinte ich, entschuldigt meine Ungenauigkeit – wir sind uns also einig. ☺
Die Shell benutzt das Leerzeichen nun mal als Feldtrenner, was jeder Programmierer stets im Kopf haben sollte – Aussagen wie „Na dann benutz halt keine Leerzeichen in Dateinamen!“ maskieren nur den Fehler des Programmierers, nicht des Nutzers. Theoretischerweise könnte man einen anderen Feldtrenner in Erwägung ziehen, aber leider ist ja jedes halbwegs leicht erreichbare Zeichen schon belegt. Dennoch: So ein beliebiger Feldtrenner wie bei sed-Skripten auch für die Shell hätte was:
| if°grep°-q°foo mit Leerzeichen°bar;then°echo°Super kuhl!;fi
|
Schon wird die Maskierung mit Backslash oder Anführungszeichen unnötig. Bloß ob das wirklich die leichtere Variante ist, sei mal dahingestellt… 😉
|
Mooi
Anmeldungsdatum: 15. August 2014
Beiträge: 187
|
Eigentlich ist es gar nicht so schwer, die volle Breitseite an Zeichen in Dateinamen zuzulassen, nämlich alles außer Slash und Nullbyte.
Im Nullbyte steckt auch die Lösung aller Dateilisten, die weiter verarbeitet werden sollen, ohne dass es zu Problemen kommt. Richtig bequem und sicher ist find -exec ... Sollen Zeichen verändert werden, benutze ich gerne find ... -print0 | awk 'BEGIN { RS="\0" } ... Quoten lässt man am besten mit einem Werkzeug der Shell selbst (builtin). In der Bash bietet sich printf %q an. So ergibt z.B.:
eine schön gequotete Dateiliste. Ach ja: Der Feldtrenner steckt in der Env-Vari $IFS und enthält normalerweise Leerzeichen, Tab und Newline.
|
nitsnatsnok
Anmeldungsdatum: 27. Oktober 2013
Beiträge: 160
|
Mooi schrieb: Ach ja: Der Feldtrenner steckt in der Env-Vari $IFS und enthält normalerweise Leerzeichen, Tab und Newline.
So einfach ist es leider nicht:
| /> IFS=°
/> ls°-l
ls°-l: Befehl nicht gefunden.
|
http://www.livefirelabs.com/unix_tip_trick_shell_script/oct_2003/10132003.htm sagt: The shell uses the value stored in IFS (…) to delimit words for the read and set commands, when parsing output from command substitution, and when performing variable substitution.
|
wxpte
(Themenstarter)
Anmeldungsdatum: 20. Januar 2007
Beiträge: 1182
Wohnort: Schäl Sick
|
rklm schrieb: Aber die Autoren von Skripten sollten sie so schreiben, dass sie auch mit diesen merkwürdigen Namen umgehen können, damit die Benutzer der Skripte sich nicht anpassen müssen (also sich an ein "Leerzeichenverbot" halten).
Um ein "Zeichenverbot" ging es mir eigentlich nie. Mich hatte lediglich die Motivation, ein Newline in einen Dateinamen einzufügen, interessiert. Dateinamen, die sich über mehrere Zeilen erstrecken, würden mich eher verwirren - schon deswegen würde ich Newlines aus eigenem Antrieb heraus vermeiden. Vor allem frage ich mich auch, ob man mit diesen Dateinamen in Standardanwendungen nicht mehr Ärger als Nutzen hat.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12832
|
WinXP to Edgy schrieb:
Um ein "Zeichenverbot" ging es mir eigentlich nie. Mich hatte lediglich die Motivation, ein Newline in einen Dateinamen einzufügen, interessiert. Dateinamen, die sich über mehrere Zeilen erstrecken, würden mich eher verwirren - schon deswegen würde ich Newlines aus eigenem Antrieb heraus vermeiden.
Vermutlich sollte man das tun. Aber das schöne ist ja, dass die Mittel zur ordentlichen Behandlung von Dateinamen mit Leerzeichen (Quoten, find -print0, xargs -0 & Co.) ebenfalls Namen mit Newlines ordentlich behandeln. ☺
Vor allem frage ich mich auch, ob man mit diesen Dateinamen in Standardanwendungen nicht mehr Ärger als Nutzen hat.
Und, was hast Du Dir geantwortet? 😉
|
wxpte
(Themenstarter)
Anmeldungsdatum: 20. Januar 2007
Beiträge: 1182
Wohnort: Schäl Sick
|
rklm schrieb: Und, was hast Du Dir geantwortet? 😉
Nichts. Ich hab's jetzt einfach mal ausprobiert. In der Titelleiste ist nur die erste Zeile zu sehen, und beim Speichern über die Anwendung wird das Newline-Zeichen als Kästchen dargestellt. Vorteile gegenüber dem einzeiligen Dateinamen sehe ich keine.
- Bilder
|
wxpte
(Themenstarter)
Anmeldungsdatum: 20. Januar 2007
Beiträge: 1182
Wohnort: Schäl Sick
|
Rückblick: aus meiner Sicht ist das Ergebnis dieses kleinen Ausflugs in die Welt der Sonderzeichen lediglich, dass diese auch in Dateinamen vorkommen können und daher beim Skripten berücksichtigt werden sollten. Also nix neues. 😉 Im speziellen Fall des Newline-Zeichens schließe ich aus dem oben Geschriebenen, dass diese in Dateinamen keinen speziellen Zweck haben, außer zu zeigen, dass "man es kann". In der alltäglichen Praxis ist mir jedenfalls ein mehrzeiliger Dateiname noch nicht untergekommen, und ich werde sicher auch nicht damit anfangen, sie in Zukunft regelmäßig zu verwenden. ▶ Ich setze den Thread auf gelöst.
|