|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
Warum schickst Du ein Signal 15 an die Shell bei jedem Prompt? Ich dachte, es sollte ein Winch sein.
2. Warum diese Mühen? Ok, ist interessant. Aber irgendwie klappt das doch auf modernen Unix-Systemen so schon gut. Jedenfalls ein vi in einem dtterm paßt sich der Größe an und die Shell danach auch.
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Warum schickst Du ein Signal 15
Weil ich mich am Ende des Textes vertippt habe. :)
Das ultimative PROMPT_COMMAND ist natürlich "kill -WINCH $$", nicht "kill $$".
2. Warum diese Mühen?
Ja sicher, das Programm im Vordergrund bekommt die Änderung immer wunderbar mit, wo's aber happert ist die Shell, mit der Du den vi gestartet hast: Der Terminal-Emulator schickt ein ioctl den Terminal-Treiber. Der Kernel schickt daraufhin ein Signal an den aktuellen PTY-Besitzer (in Deinem Fall vi). Der PTY-Besitzer sollte das Signal jetzt wahrscheinlich weiterleiten an das startende Programm (oder so), nur macht dies kaum eines. Resultat: Die Shell bricht beim Befehlseditieren sonstwo um, nur nicht am Zeilenende.
Das explizite WINCH-an-die-Shell-Schicken wurstelt um dieses Problem herum.
--
Addicted by code poetry...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 04. February 2005, 10:20 MEW (#9)
|
|
|
|
|
Hm, also ich hab hier die KDE-Konsole auf:
"less test.txt" lässt sich wunderbar resizen, genauso "vi test.txt". Alle Zeilen werden länger oder kürzer in "Realtime". Vielleicht steige ich immer noch nicht durch.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 04. February 2005, 11:22 MEW (#16)
|
|
|
|
|
Hast halt wohl nicht Debian Stable steinzeit installiert :-)
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 06. February 2005, 00:40 MEW (#30)
|
|
|
|
|
mach folgendes: gebe eine sehr lange komando ein , die über mehrere zeielen geht.
fuerh es aus.
Dann resize das fesnter und gehe in der history(pfeil auf) zurueck. Da bekomme ich schon problemme, da die zeiele nicht komplett zu sehen ist.
|
|
|
|
|
|
|
|
|
|
|
|
|
Hm, ich muß zuegeben, ich ändere die Fenstergröße sowieso kaum bis nie und wenn doch, dann immer nur im Prompt, fast niemals, wenn ein Programm darin läuft. Vermutlich, weil ich genau die geschilderten Erfahrungen gemacht habe.
Da ich mir das aber genau so angewöhnt habe, merke ich dieses Problem nie (zumal manche Programme gar nicht begeistert über das WINCH-Signal zu sein scheinen und dann alles andere, nur nichts sinnvolles machen).
Wandert dieses Signal auch zu einem fernen pty über Telnet bzw. SSH?
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
|
|
|
|
Ok, jetzt ist es ein WINCH (oder war es das wirklich von Anfang an? Dann muß ich mir für nächste Woche einen Termin beim Augenarzt geben lassen.).
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 04. February 2005, 09:40 MEW (#2)
|
|
|
|
|
Ich glaub ich kapier das Problem nicht, dass du da mit viel Aufwand gelöst hast. Welche Shell kann denn bei dir von zu Hause aus nicht mehr als 80 Zeichen pro Zeile schlucken? Bei mir geht das sowohl auf den virtuellen Konsolen (Ctrl+Alt+F1..F6) wie auch unter den "GUI-Shells" von KDE und Gnome.
Erleuchtung gesucht! (Aber interessanter Artikel, möchte ich noch angefügt haben.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Das ist so gedacht:
- shell öffnen
- arbeiten
- shell-window resizen
- weiter arbeiten *peng* - hier merkt die shell nicht* dass mehr platz da wäre
*) naja so aus dem Gefühl behauptet geht das in der Konsole von KDE mit bash schon lange...
|
|
|
|
|
|
|
|
|
|
|
|
|
Wenn Du die Grösse änderst, während die Shell auf Input wartet, ja dann klappt das. Wenn Du die Grösse änderst, während ein von der Shell gestartetes Programm an STDIN lauscht, geht's in die Hose.
--
Addicted by code poetry...
|
|
|
|
|
|
|
|
|
|
|
|
|
Gibt es kein "execute after command" in der Shell? Mich stört irgendwie der Kill-Befehl im Prompt (dabei ist der Ort schon passend).
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
|
|
|
|
aah *plig* *erleuchtung*
- In dem Fall wird das Lob um Faktor 1.7777779 erhöht!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sie oben: Das Signal landet immer nur beim Prozess, der gerade Input verabeitet. Wenn beim Resizen also irgendein anderes Programm im Vordergrund hängt, sei es vim, sei es top, sei es was uninteraktives wie make, geht die Shell leer aus und produziert beim Befehlszeile editieren Murks. Auf jedem Linux, auf jedem Unix, dass ich ausprobiert habe.
--
Addicted by code poetry...
|
|
|
|
|
|
|
|
|
|
|
|
|
Ein echtes Lob - so einen praktischen Artikel gabs bei Symlink schon lange nicht!
Hab leider das Know-how nicht um selbst sowas zu verfassen..
|
|
|
|
|
|
|
|
|
|
|
|
|
So, nachdem ich jetzt den Sinn und die Notwendigkeit verstanden habe:
Warum ist das nicht schon Standardmäßig drin? Daß ein WINCH wohl nicht von Programmen an die Shell weitergereicht wird, ist wohl schon länger bekannt. Und wenn die Lösung so einfach ist, warum nicht schon immer so....
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hm... Das Problem scheint auf debian testing nur bei ssh-Verbindungen aufzutreten (ssh localhost).
|
|
|
|
|
|
|
|
|
|
|
|
|
Oder man kann es sich auch einfach machen und nach terminalgroessenaenderungen einfach ^L druecken.
Schickt ein SIGWINCH an das entsprechende Programm und die Sache ist erledigt.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ok, ich bin auch erst durch den Tip auf die Idee gekommen; das Problem hat mich jahrelang genervt, allerdings zu wenig um mich dahinter zu setzen. Seit dem letzten Bash-Update geht's jedoch problemlos. Also mal
# vi /etc/bash/bashrc
/WINCH
eingegeben und voila:
# Bash won't get SIGWINCH if another process is in the foreground.
# Enable checkwinsize so that bash will check the terminal size when
# it regains control. #65623
# http://cnswww.cns.cwru.edu/~chet/bash/FAQ (E11)
shopt -s checkwinsize
Cool. Ich weiss jetzt leider nicht, ob das auch mit älteren Bashen geht, oder ob andere Shells ähnliche Befehle haben. Aber für die Basher ist das hier wohl fast die edelste Lösung. IMHO.
tL
--
... I don't like it, but I guess things happen that way ... (J. Cash)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
> shopt -s checkwinsize
Aha! Das ist per default eingeschaltet. Allerdings nicht, wenn ich via ssh komme:
martin@bazaar:~$ shopt | grep checkwinsize
checkwinsize on
martin@bazaar:~$ ssh localhost
(...blah...)
martin@bazaar:~$ shopt | grep checkwinsize
checkwinsize off
Hat jemand eine Erklärung dafür? (debian testing; wenn es im .bashrc gesetzt wird geht's natürlich)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Möglicherweise, weil Login- und normale Shells verschieden initialisiert werden. Siehe die FILES-Section von "man bash".
Bei mir werden folgende Scripts ausgeführt:
Login-Shell:
/etc/profile
/etc/bash/bashrc
"Normale" Shell:
/etc/bash/bashrc
~/.bashrc
tL
--
... I don't like it, but I guess things happen that way ... (J. Cash)
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 04. February 2005, 12:22 MEW (#20)
|
|
|
|
|
...wenn es doch GNOME gibt?
ich habe die Shell schon seit Jahren nicht mehr gebraucht. Auf underen Servern läuft Webmin und GNOME. Hallo wir leben im 2005, wir leben in der Grafik!
Shell ist vom letzten Jahrtausend
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
das rad glaub vom vorletzten oder so ;)
|
|
|
|
|
|
|
|
|
|
|
|
|
Warum schwarz und weiss? Statt sich auf ein Paradigma ($SHELL vs. Klickibund), sollte man doch einfach immer das Paradigma nutzen, welches gerade am brauchbarsten erscheint. Wenn's stark testlastig ist, was man gerade erledigen will, ist die $SHELL unschlagbar. Am System herumbasteln, fremden Code erforschen, Dateien suchen, geht wunderbar in der $SHELL, ist kennt man seinen Werkzeugkasten extrem effizent und macht mangels Frustmomenten sogar spass. Zum Bilderverwalten hingegen sind Nautilus und gphoto grandious. Musik spielt sich super mit Goobox und Muine. Compilieren von eigenem Code geht wesentlich komfortabler aus der IDE heraus (gVim, $whatever, ...).
--
Addicted by code poetry...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 04. February 2005, 14:30 MEW (#26)
|
|
|
|
|
Please do not feed the trolls...
|
|
|
|
|
|
|
|
|
|
|
|
|
Was immer am besten geht, geht am besten, auch wenn man sich auf ein neues Paradigma einstellen muss. Und es ist nun mal nicht so dass sich Terminal und GUI beissen.
Man ist ganz einfach am schnellsten wenn man für die Aufgabe das richtige Tool benutzt. bei mir teilweise GUI, teilweise Kommandozeile, und teilweise den Speed-King "midnight commander" (jep, viele Aufgaben gehen mit dem locker Faktoren schneller wie nur mit der Kommandozeile), ebenfalls im Terminal.
Die Shell ist ein mächtiges Werkzeug, und wer das Gefühl hat die sei nun nutzlos weil man gewisse Dinge per Mausclick lösen kann ist einfach nur dumm. "Ich hab nun eine Motorsäge, da brauch ich kein Taschenmesser mehr"
"The more prohibitions there are, The poorer the people will be"
-- Lao Tse
|
|
|
|
|
|
|
|
|
|
|
|
|
Schonmal Solaris Jumpstart benutzt?
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
|
|
|
|
ich habe mich schon laenger mit dem Problem rumgeschlagen. Habe aber mir nicht die Zeit genommen das Problem zu loesen. Uhrsache war mir klar aber nicht die Loesung.
Ich hoffe es kommen mehr solche Tipps bei Symlink!
|
|
|
|
|
