|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
 |
|
|
|
Von Anonymer Feigling am Wednesday 26. September 2007, 15:19 MEW (#5)
|
|
|
|
|
Jeder Admin mit ein paar Tassen im Schrank, hat unter Solaris sowieso GNU Tools installiert, weil die Solaris Varianten seit Jahrzehnten POSIX-ignorienderweise vor sich hinrotten. Wenn du schon mal ein Script mit Backticks oder anderen Krücken gesehen hast, darfst du dich im wesentlichen bei SUN für diese Erfahrung bedanken, da man heutzutage normalerweise nicht so einen unleserlichen Schrott schreiben will. Von anderem Schwachsinn in ihrer C-Bibliothek will ich gar nicht erst anfangen. Andere Systeme zeigen, dass man so etwas ohne Kompatibilitätsproblem lösen kann. Aber man will ja Solaris-Nutzer nicht diskriminieren. Das letzte was ich will, ist ein UNIX-Monopol egal ob von Linux oder sonstwem.
Außer Java und vielleicht noch ZFS kennen die wenigstens noch SUN, da kann ich bei der Treiber-Problematik auch nur lachen. Wenn SUN schnell, viele Treiber will, dann werden sie dafür schon zahlen bzw. gleich auf Linux oder Windows umsteigen müssen.
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 28. September 2007, 12:22 MEW (#12)
|
|
|
|
|
naja man kann kompatibel werden ohne die Kompatiblität zu sich selbst ;) zu verlieren,
siehe unter FreeBSD die Fähigkeit
mit der LinuxABI Linux Programme auszuführen,
und ganz nebenbei das funktioniert erstaunlich gut.
|
|
|
|
|
|
|
|
|
|
|
|
|
Zum Glück kommt da nicht die GNU bash rein,
sondern eine Korn Shell, zwar nicht mksh,
aber immerhin die AT&T ksh93 (das Original
also). Die ist zwar nicht ganz so schlank
wie mksh, aber hat dafür einen Haufen an
Funktionen, von denen andere nur träumen.
(Kamma sogar pacman spielen drin.)
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 26. September 2007, 14:19 MEW (#3)
|
|
|
|
|
Solangs kein CTRL-R kann kommts nicht an die Bash ran.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 26. September 2007, 16:35 MEW (#9)
|
|
|
|
|
Das hat mit Bash recht wenig zu tun. Das ist einfach readline und jede gepflegte ksh kann das. Eventuell ist die Tastenbelegung per Default eine andere.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 26. September 2007, 15:10 MEW (#4)
|
|
|
|
|
Es gibt schlimmeres als bash, eigentlich sogar fast nur. Ich habe vor längerer Zeit mal viele *sh-Varianten durchprobiert. Die meisten haben sich aber schon nach wenigen Minuten als interaktive Shell disqualifiziert, weil sie entweder keine vernünftige "history" oder "tab-completion" boten. In einem Terminal will auch das Verzeichnis im Titel und nicht Prompt sehen, was mit vielen Shells nicht machbar ist. Davon geht vielleicht die Welt nicht unter, aber ich sehe auch keinen Grund mich selbst zu geisseln, nur um ein bisschen Speicher zu sparen. Es gab auch noch andere Gründe, an die ich mich jetzt aber nicht erinnern kann. Die einzig brauchbare ksh-Variante, die ich finden konnte, war die von NetBSD, aber auch dessen tab-completion ist unbefriedigend, weil sie bei gewissen Zeichen hängen bleibt. Bei der Bash kann man sich auf tab-completion verlassen, vor allem auch dass sie das Shell-Escaping richtig macht. Viele andere Shells tun das nicht, was bei Anfängern besonders in einem Multi-User-Umfeld problematisch sein kann.
Bei langen Zeilen werden viele Shells auch schnell unbrauchbar, weil man nicht mehr sieht, was man eingibt. Zum Beispiel spuckt mir meine ksh auch mit [C oder [D ins Terminal, wenn ich nach "history-search" eine Cursor-Taste drücke. Also kurz gesagt, die Bash mag nicht perfekt sein, aber die meisten anderen Shells haben unzählige kleine Fehler oder Nervereien, dass Bash sicher nicht die schlechteste Wahl ist.
Was bei der Bash wirklich nervt ist, dass sie die Shell-Syntax unsinning erweitert, z.B. '==' erlaubt, obwohl '=' korrekte portable Shell-Syntax ist. Wenn man dann n00bs sagt, sie sollen wenigstens nicht "!/bin/sh" in den Header schreiben, führt das nur dazu, dass sie überall "! /bin/bash" reinschreiben, selbst wenn es sich um gewöhnliche und portable Shell-Scripts handelt.
|
|
|
|
|
|
|
|
|
|
|
|
|
Naja, was Du beschreibst ist eigentlich alles
in mksh gefixt (AT&T ksh93 weiß ich nicht),
außer die Sache mit den Cursortasten nach
der History-Search, das kann man nicht fixen,
da das ESC [ C ist, und das "ESC" darin die
History-Search beendet, sorry.
ksh93 sollte aber Ctrl-R können...
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 26. September 2007, 16:23 MEW (#7)
|
|
|
|
|
Mit "kann man nicht" kannst du nicht ernsthaft argumentieren. Bash kann es und es ist auch nicht sonderlich obskur, dass man etwas aus der History sucht und dann mit dem Cursor navigiert, weil man etwas ändern will.
Kannst du mit Sicherheit behaupten, dass die tab-completion der mksh nicht an '[' bzw. '\[' hängen bleibt? Beispiel:
mkdir 'yodel [eins]' 'yodel [zwei]'
cd yo
ergibt bei meiner ksh:
cd yodel\ \[
und dann kann ich tab schlagen, bis die Finger bluten, es passiert gar nichts mehr. Auch wenn ich dann e oder z eingebe, funktioniert tab-completion nicht mehr. Und noch was:
ls 'yodel [eins]'
cd .
ergibt bei meinr ksh:
cd [eins]'
erwartet wurde:
cd 'yodel [eins]'
Und noch was, wobei hier sicherlich auch das Terminal ein Wörtchen zu sagen hat:
Wenn ich UTF-8 ausserhalb des ASCII-Bereichs editiere, dann funktioniert Backspace und auch der Cursor nicht richtig, da diese offensichtlich byte-weise und nicht zeichenweise arbeiten. Abhilfe schafft hier nur 'fc' mit vim als Editor, da nur manche vi-Varianten mit UTF-8 klarkommen.
Ein workaround für diese Probleme ist natürlich copy&paste, aber das hat man ja nicht überall und es ist auch nicht sonderlich ergonomisch.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 26. September 2007, 16:30 MEW (#8)
|
|
|
|
|
<tab> und <esc> wurden jetzt gefressen, aber ich glaube man kann sich denken, wo sie platziert waren (Lösung siehe unten)
cd yo|tab|
cd |esc|.
|
|
|
|
|
|
|
|
|
|
|
|
|
> Mit "kann man nicht" kannst du nicht ernsthaft
> argumentieren. Bash kann es
Naja, readline (nicht bash) nutzt termcap/curses, und da kann
man wesentlich erweitertere Funktionen nutzen (zB sehen, daß
drei Zeichen auf einmal anstehen und die zusammen parsen, statt
einfach nur ein ESC zu lesen und es entweder als Abbruch der
Suche oder als Præfix für ne Tastenkombo zu nehmen.
Ab jetzt wirds mksh-spezifisch, die kann man auf OpenSolaris
zwar auch nutzen, aber ich weiß nicht, wie sich ksh93 verhält:
| tg@odem:~ $ mkdir 'yodel [eins]' 'yodel [zwei]'
| tg@odem:~ $ cd yo
<tab>
| tg@odem:~ $ cd yodel\ \[
<tab>
| yodel [eins]/ yodel [zwei]/
| tg@odem:~ $ cd yodel\ \[
e<tab>
| tg@odem:~ $ cd yodel\ \[eins]/
Zum zweiten Teil: was meinst Du mit "cd ."? Bei mir wechselt
das nur ins aktuelle Verzeichnis.
Zu UTF-8: auch das hab ich bei mksh gefixt, allerdings nur im
Emacs-Editiermodus (default); wird abhängig von $LC_CTYPE bzw.
mit set -o utf8-hack angeschaltet. (Ggf. eine aktuellere mksh
nehmen, vor R31b ist eh n übler Bug drin.)
Können wir den Rest im IRC besprechen? Hier wirds offtopic...
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
