Auf der Suche nach einer vernünftigen Unix-Shell
Unix-shells sind bei mir ein ewig-leidiges Thema.
Ich hab mich bis jetzt schon mit bash, zsh und auch kurz der rc-shell auseinander gesetzt.
Aber es gibt mindestens eine Anforderung, die auch sicher öfter auftritt, die noch keine erfüllt:
Angenommen ich hab ein Verzeichnis mit mehreren Dateien, welche alle Leerzeichen im Namen enthalten. Wenn ich jetzt ein Programm mit allen Dateinamen als parameter aufrufen will, muss ich schon anfangen, for-schleifen oder andere Umwege zu basteln, da diese shells nicht quoten
Gibt es eine Shell, die damit vernünftig umgeht?
Wenn nein, wäre das hiermit ein Projektvorschlag. Bei der Gelegenheit könnte man mal wirklich leicht durschaubares Verhalten von " und ' einführen...
Ich hab mich bis jetzt schon mit bash, zsh und auch kurz der rc-shell auseinander gesetzt.
Aber es gibt mindestens eine Anforderung, die auch sicher öfter auftritt, die noch keine erfüllt:
Angenommen ich hab ein Verzeichnis mit mehreren Dateien, welche alle Leerzeichen im Namen enthalten. Wenn ich jetzt ein Programm mit allen Dateinamen als parameter aufrufen will, muss ich schon anfangen, for-schleifen oder andere Umwege zu basteln, da diese shells nicht quoten
Gibt es eine Shell, die damit vernünftig umgeht?
Wenn nein, wäre das hiermit ein Projektvorschlag. Bei der Gelegenheit könnte man mal wirklich leicht durschaubares Verhalten von " und ' einführen...
Ich glaube ich verstehe Dein Problem nicht ganz. Die Bash kann ganz wunderbar Programme mit Dateinamen mit Leerzeichen als Argumente starten. Bei der Vervollständigung via TAB werden Leerzeichen mit einem Backslash entwertet. Ansonsten kann man natürlich auch ' oder " benutzen. Und die zsh sollte das genauso machen.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Gibt's doch schon. IPythons pyshhenning hat geschrieben:Wenn nein, wäre das hiermit ein Projektvorschlag. Bei der Gelegenheit könnte man mal wirklich leicht durschaubares Verhalten von " und ' einführen...
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- Rebecca
- User
- Beiträge: 1662
- Registriert: Freitag 3. Februar 2006, 12:28
- Wohnort: DN, Heimat: HB
- Kontaktdaten:
Funktioniert doch wunderbar (zumindest mit der bash unter Linux):
Tut genau das, was ich will.
Code: Alles auswählen
~/zeugs/test> mkdir "hallo welt"
~/zeugs/test> ls
hallo welt
~/zeugs/test> emacs "hallo welt"/
~/zeugs/test> emacs hallo\ welt/
Rebecca: Ich glaube du hast mein Problem nicht verstanden, es geht darum mehrere Dateien mit Leerzeichen im Namen einfach als Parameter mit * zu erzeugen, aber so, dass auch andere Programme als emacs das verstehen ,-)
Leonidas: IPython kenn ich, was ist pysh, wie komme ich da ran?
Leonidas: IPython kenn ich, was ist pysh, wie komme ich da ran?
- Rebecca
- User
- Beiträge: 1662
- Registriert: Freitag 3. Februar 2006, 12:28
- Wohnort: DN, Heimat: HB
- Kontaktdaten:
Vielleicht bin ich heute schwer von Begriff, aber du meinst sowas?:
Jetzt mal davon abgesehen, dass Emacs gut ist , die Sternchen-Ersetzung macht doch die Shell und ist somit unabhaengig vom Programm? Also wo ist das Problem? *verwirrt ist*
Code: Alles auswählen
~/zeugs/test> mkdir "hallo welt" "hallo_welt"
~/zeugs/test> ls
hallo welt hallo_welt
~/zeugs/test> ls -ad hallo*welt
hallo welt hallo_welt
~/zeugs/test> ls -ad hallo[" "]welt
hallo welt
~/zeugs/test> ls -ad hallo[" "_]welt
hallo welt hallo_welt
Okay, ich hab mich vielleicht echt undeutlich ausgedrückt, aaalso:
Das sind drei Dateien mit Leerzeichen im Namen.
Hier sieht man das Problem: Die Dateinamen werden ungequoted übergeben! Wenn ich jetzt z.B. ein python-programm habe, dass üder sys.argv Dateinamen erwartet, kriegt das schon Probleme die auseinanderzufummeln, und so gehts den meisten anderen Programmen auch.
Ich will halt, dass dieses Sternchen ein bisschen weniger dumm ist ,-)
Bei vielen Programmen gibt es schon Lösungen, Dateinameslisten anzugeben oder man kann mit print0 und xargs was machen etc...
Also das Problem ist natürlich lösbar. Aber ich finde das umständlich und unintuitiv, ich will eine Shell, bei der ich mich drauf verlassen kann das * als Parameter bedeutet, dass bei dem Programm alle Datein aus dem aktuellen Verzeichnis ankommen.
Kann doch nicht so schwer sein?
Code: Alles auswählen
$ ls
Ein langer Dateiname.txt Noch ein langer Name.foo Und noch einer.bar
Code: Alles auswählen
$ echo *
Ein langer Dateiname.txt Noch ein langer Name.foo Und noch einer.bar
Ich will halt, dass dieses Sternchen ein bisschen weniger dumm ist ,-)
Bei vielen Programmen gibt es schon Lösungen, Dateinameslisten anzugeben oder man kann mit print0 und xargs was machen etc...
Also das Problem ist natürlich lösbar. Aber ich finde das umständlich und unintuitiv, ich will eine Shell, bei der ich mich drauf verlassen kann das * als Parameter bedeutet, dass bei dem Programm alle Datein aus dem aktuellen Verzeichnis ankommen.
Kann doch nicht so schwer sein?
Tjo... hab jetzt auch die pysh gefunden http://ipython.scipy.org/doc/manual/node12.html, die scheint das Problem aber auch nicht zu lösen und hat ausserdem kein job-control etc... da es ja im Grunde nur ein syntaxverbogener Python-Interpreter ist...
-
- User
- Beiträge: 424
- Registriert: Montag 28. Juli 2003, 16:19
- Wohnort: /dev/reality
Danke, scheint ein sehr nützliches Tool zu sein, aber mir will noch nicht so ganz in den Kopf, dass man für so eine einfache Sache wie "alle Dateien aus diesem Verzeichnis" in keiner shell eine wirklich einfache Lösung zur Hand hat.
-
- User
- Beiträge: 670
- Registriert: Sonntag 15. Januar 2006, 18:42
- Wohnort: Celle
- Kontaktdaten:
Möp?! Das ist keine Shell-Aufgabe, das ist eine Aufgabe für andere Tools wie zum Beispiel find.... "alle Dateien aus diesem Verzeichnis" in keiner shell eine wirklich einfache Lösung zur Hand hat.
Code: Alles auswählen
for i in `find -maxdepth 0 -type f`
do
echo "Ich würde $i bearbeiten"
done
--- Heiko.
Also mit der zsh hab ich da kein Problem:
Code: Alles auswählen
thomas@chaos /tmp % mkdir "foo sup"
thomas@chaos /tmp % mkdir "foo sp"
thomas@chaos /tmp % ls *
apr5RYJZv barr foo foo bar foo bat
foo sp:
foo sup:
kde-thomas:
[...]
Slackware will never die.
Passender find Befehl:modelnine hat geschrieben:Code: Alles auswählen
for i in `find -maxdepth 0 -type f`
Code: Alles auswählen
for i in `find . -maxdepth 1 -type f `
Slackware will never die.
-
- User
- Beiträge: 670
- Registriert: Sonntag 15. Januar 2006, 18:42
- Wohnort: Celle
- Kontaktdaten:
GNU-find nimmt standardmäßig das aktuelle Verzeichnis, wenn keins angegeben ist (sprich ohne den Punkt)... Aber maxdepth muss eins sein, damit er im aktuellen Verzeichnis sucht, ja.
Wenn man dann möchte dass er Dateien mit Leerzeichen im Namen (wer hat sowas, außer Windows-Usern?!) nicht trennt, muß man vorher zumindest in der Bash noch das Verhalten der Backticks anpassen:
Damit wird nur noch auf Leerzeilen getrennt.
Wenn man dann möchte dass er Dateien mit Leerzeichen im Namen (wer hat sowas, außer Windows-Usern?!) nicht trennt, muß man vorher zumindest in der Bash noch das Verhalten der Backticks anpassen:
Code: Alles auswählen
IFS="
"
--- Heiko.
Hmm... in der Tat, wenn ich es jetzt mit nem eigenen Progrämmchen ausprobiere, funktionierts sowohl mit zsh als auch mit bash, dann lag das Problem vielleicht ehr in dem progrämmchen, das ich benutzen wollte (weiß schon nicht mehr welches das derzeit war).
modelnine: Ich kenne sie Unix-Philosophie sehr wohl. Und wenn es keine Shellaufgabe ist, alle Dateien im Verzeichnis als Parameter übergeben zu können, warum gibt es dann "*" in dem meisten shells?
Ausserdem ist ja die Frage, wie eng man diese Philosophie auslegt.
Natürlich will ich gar kein Tool das alles kann. Ich verstehe diese Philosophie so, dass man kleine Progrämmchen hat, die eine bestimme Aufgabe erledigen. Diese kann man sich dann so zusammenbauen, wie man sie braucht.
z.B. ist es sinnvoll, dass date nur das Datum ausgibt und nicht gleich noch ne GUI und ne Terminverwaltung mit eingebaut hat
Aber ich finde es z.B. auch nützlich, dass man date ein Format-String übergeben kann, denn wenn das Datum in einem festgelegten Format und vielleicht auch nur auf englisch erscheinen würde, müsste man schon wieder recht viel fummeln um ein Datum mit deutschem Wochentag in seinem Lieblingsformat zu haben.
(Klar kann man das mit nem script hinkriegen, aber es ist halt ne häufig verlangte Aufgabe!)
Es gibt einen Punkt ab dem es schlicht und ergreifend albern ist soundsoviele Prozesse aneinanderzuhängen und irgendwelche Ausgaben zu parsen.
Spätestens dann wenn mehr Ressourcen (sei es von Mensch oder CPU) benötigt werden um Programm-ausgaben auseinanderzufummeln als für das eigentliche Problem, überlege ich mir halt, obs nicht ein bisschen weniger modular geht
modelnine: Ich kenne sie Unix-Philosophie sehr wohl. Und wenn es keine Shellaufgabe ist, alle Dateien im Verzeichnis als Parameter übergeben zu können, warum gibt es dann "*" in dem meisten shells?
Ausserdem ist ja die Frage, wie eng man diese Philosophie auslegt.
Natürlich will ich gar kein Tool das alles kann. Ich verstehe diese Philosophie so, dass man kleine Progrämmchen hat, die eine bestimme Aufgabe erledigen. Diese kann man sich dann so zusammenbauen, wie man sie braucht.
z.B. ist es sinnvoll, dass date nur das Datum ausgibt und nicht gleich noch ne GUI und ne Terminverwaltung mit eingebaut hat
Aber ich finde es z.B. auch nützlich, dass man date ein Format-String übergeben kann, denn wenn das Datum in einem festgelegten Format und vielleicht auch nur auf englisch erscheinen würde, müsste man schon wieder recht viel fummeln um ein Datum mit deutschem Wochentag in seinem Lieblingsformat zu haben.
(Klar kann man das mit nem script hinkriegen, aber es ist halt ne häufig verlangte Aufgabe!)
Es gibt einen Punkt ab dem es schlicht und ergreifend albern ist soundsoviele Prozesse aneinanderzuhängen und irgendwelche Ausgaben zu parsen.
Spätestens dann wenn mehr Ressourcen (sei es von Mensch oder CPU) benötigt werden um Programm-ausgaben auseinanderzufummeln als für das eigentliche Problem, überlege ich mir halt, obs nicht ein bisschen weniger modular geht
Sie müssen auch nicht gequotet sein, da die argv auch Leerzeichen enthalten können:henning hat geschrieben:Hier sieht man das Problem: Die Dateinamen werden ungequoted übergeben!
Code: Alles auswählen
$ ll
insgesamt 4
-rwxr-x--- 1 x x 69 2006-03-27 14:33 aa.py
-rw-r----- 1 x x 0 2006-03-27 14:31 a b
-rw-r----- 1 x x 0 2006-03-27 14:31 c d
-rw-r----- 1 x x 0 2006-03-27 14:31 e f
-rw-r----- 1 x x 0 2006-03-27 14:31 g h
$ cat aa.py
#!/usr/bin/python
import sys
for n in sys.argv:
print "parameter",n
$ ./aa.py *
parameter ./aa.py
parameter aa.py
parameter a b
parameter c d
parameter e f
parameter g h
Natürlich werden die da "ungequotet" übergeben oder willst Du das die Programme Quotezeichen mitbekommen statt der richtigen Namen!? Ich verstehe immer noch Dein Problem nicht. Der `*` macht schon das richtige. Schaust Du hier:henning hat geschrieben:Okay, ich hab mich vielleicht echt undeutlich ausgedrückt, aaalso:Das sind drei Dateien mit Leerzeichen im Namen.Code: Alles auswählen
$ ls Ein langer Dateiname.txt Noch ein langer Name.foo Und noch einer.bar
Hier sieht man das Problem: Die Dateinamen werden ungequoted übergeben! Wenn ich jetzt z.B. ein python-programm habe, dass üder sys.argv Dateinamen erwartet, kriegt das schon Probleme die auseinanderzufummeln, und so gehts den meisten anderen Programmen auch.Code: Alles auswählen
$ echo * Ein langer Dateiname.txt Noch ein langer Name.foo Und noch einer.bar
Code: Alles auswählen
bj@s8n:~/tmp/test> ls
foo bar.txt spam eggs.txt test.py
bj@s8n:~/tmp/test> ./test.py *
['foo bar.txt', 'spam eggs.txt', 'test.py']
bj@s8n:~/tmp/test> cat test.py
#!/usr/bin/env python
import sys
print sys.argv[1:]
bj@s8n:~/tmp/test>
Kann es sein dass Du Probleme siehst, wo gar keine sind!?
Wenn du meine Postings aufmerksam gelesen hast, wird dir sicher aufgefallen sein, dass mein Problem schon gelöst ist und anscheinend auf der Seite eines Programms lag, welches wohl krampfhaft versucht hat, die übergebenen Argumente auch nochmal zu zerlegen (oder sie seinerseits ohne Quoting der shell übergeben hat oder was-weiß-ich. Jedenfalls weiß ich jetzt, dass das Sternchen sich doch vernünftig verhält