Die dash basiert auf der ash, diese wird auch bei Busybox auf Embedded Systemen verwendet, da sie sehr klein. Sehr klein -> schneller -> aber auch weniger Funktionen, deshalb auch die (vielen) Fehler bei der Umstellung von sh auf dash.
Ich spreche von der Shell für Skripte, welche vorher die bash war. Sonst hätte es auch keine Probleme geben können, da die dash POSIX-konform ist. Es wurden also vermutlich proprietäre GNU-Erweiterungen in den Skripten eingesetzt.
Wusstest du nicht? Tut mir leid, es dir nicht früher gesagt zu haben, aber ich habe mir beim Eisessen die Zunge verbrannt und war temporär sprechunfähig.
Die GNU bash verfügt über zusätzliche Features, die im POSIX-Standard nicht vorgesehen sind, sondern nur von der bash unterstützt werden. Mangels Standardisierung handelt es sich damit um proprietäre Erweiterungen. Sie sorgen dafür, dass andere Shells solche Skripte nicht ausführen können.
Hallo. Gibt es irgendwo ne Liste mit den Unterschieden? Ich muss ein paar /bin/bash-Scripte soweit anpassen das sie Posix-Konform sind (mir der dash laufen).
dash ist sowas wie bash und bash ist sowas wie zsh ^^ nur halt anders wenn ich das richtig verstanden hab... achso und alles ist wieder so ähnlihc wie sh xD
Das gnome hab ich hier schon aus testing installiert. Sowohl 2.22.0 als auch erste Pakete von 2.22.1 sind schon in testing, 2.22.0 schon seit ca. einer Woche nach dem Release.
Hm, komisch, bei mir in debian/sid sind ja noch nicht einmal alle gnome-Pakete auf 2.22, sondern noch auf 2.20, wenn ich mich nicht vertue. (dpkg -l | grep 2.20 | grep gnome)
OK, ich benutze Debian seit Sarge und glaube, dass es sogar noch im stable vorkommt dass bestimmte Komponenten einfach aus einer aelteren Version uebernommen werden weil sie stabiler sind. Also, keine Sorge, das meisste ist bestimmt 2.22 wenn Lenny erscheint...
Aber KDE 4.1 *SCHAUDER!* Ich muss wohl mal "man growisofs" lesen, weil wenn k3b auf den libs laueft dann brenn ich von jetzt an nur noch aus der Konsole...
Schön wäre es, wenn die Pakete, die den Einzug in Lenny nicht direkt schaffen, im nachhinein trotzdem noch hinzugefügt würden. (Ohne Backports oder ähnliches)
Ja klar, aber da Software ständig weiterentwickelt wird wird es immer Pakete geben die es nicht schaffen. Für besonders interessante Pakete wird ja oft eine Ausnahme gemacht, aber halt nicht bei allen. Nutze einfach Debian testing oder unstable bzw. kompiliere dir die allerneusten Etnwicklungsversionen, wenn Du denn unbedingt auf den allerneusten Stand sein willst.
Nö, benutze weiterhin Stable. Sagte nur, daß es schön wäre. Z.B. Für Standardsoftware wie Webbrowser oder andere schnellebige Software. Mal abgesehen von der letzten Zeit lagen die Versionen früher zeitlich stark auseinander. Jeder der schonmal einen 2 Jahre alten Browser verwendet hat weiß was ich meine. Deshalb muß ich nicht gleich mein gesamtes System aus dem unstable-Zweig installieren!
Gibt es nicht genau dafür die Backports? Um wichtige oder vielbenutzte Programme in einer erträglich aktuellen Version anzubieten? Man muss halt irgendwann den Schlussstrich ziehen welche Software noch mitkommt. Und die einmal stabile Basis im nachhinein zu verändern halte ich für problematisch. Bei einem aktuellen Debian gibt es nur sehr wenige Programme die arg veraltet sind. OpenOffice habe ich in der neusten Version installiert. Das wars schon. Jeder hat halt ein oder zwei Programme die immer topaktuell sein sollen. Aber darauf kann man bei einer Massendistri keine Rücksicht nehmen.
Ich gebe Dir ja soweit recht. Z.Z benutze ich ja auch die Backports, jedoch habe ich häufiger das Gefühl, daß die dortigen Programme nicht wirklich auf einem reinen stable-System erstellt worden sind. Ich hatte schon häufiger unnötige Abhängigkeiten ins testing-System. Ich bin echt kein Versionsfetischist um das mal klar zu stellen
Iceweasel ist 2.0.13 in Etch/Security. Nicht mal Backports braucht man. Das Browser-Argument ist also weg, für andere Anwendungen hat es aber seine Berechtigung.
Wenn man blind Update für Update fährt kann man so ziemlich jedes OS killen. Testing ist da keine Ausnahme, man sollte es auch mit Hirn tun. Viele Probleme in Windows sind ebenso nur User-basiert.
Du weißt aber schon, wo der Unterschied zwischen 'stable' und 'testing' ist? Bzw. das es überhaupt etwas unterschiedliches ist? Oder hast Du nicht genau genug gelesen?
"Du weißt aber schon, wo der Unterschied zwischen 'stable' und 'testing' ist? Bzw. das es überhaupt etwas unterschiedliches ist? Oder hast Du nicht genau genug gelesen?"
Weshalb versteht niemand meinen Humor? Na ja, ... egal.
Ja, ich meine den Kernel. Etch 1/2 sollte ja zusammen mit r4 herauskommen, inklusive dem 24er Kernel der schon während der Installation benutzt wird. Du schreibst, dass ein neuer Kernel sowieso mit r4 herauskommen soll. Wird dieser dann auch schon im Installer Verwendung finden?
Seit ungefähr einer Woche ist etwas los auf deren Mailingliste. Ein erster Kernel sowie ein paar andere Pakete sind anscheinend schon installierbar. Wird aber wohl noch eine weile dauern, bis die veröffentlicht werden.
Weiß jemand, wie es unter lenny mit der Unterstützung von efi auf amd64-systemen (-> apple macbook) aussieht? Bei etch ist dieses Problem als bug dargestellt (z.B. auf wiki.debian.com/Macbbok), wodurch es schwierig ist, debian mit amd64-architektur aufm macbook zum laufen zu bringen (habe es nicht geschafft).
Von Rene Engelhard am Mo, 14. April 2008 um 10:04 #
Das ist kein Problem. Brauchst auch das refit-Paket aus Debian nicht, genügt, wenn Du refit von sf.net in deiner Mac OS X/efi Partition einbindest (siehe dessen Doku)
(/me hat so ein Ding mit etch aufgesetzt und dann dist-upgraded auf sid)
Was ist "dash"? Oder ist das ein Tippfehler? =)
lg
Erik
(Die dash soll init-skripte schneller ausführen)
lg
Erik
Sonst hätte es auch keine Probleme geben können, da die dash POSIX-konform ist.
Es wurden also vermutlich proprietäre GNU-Erweiterungen in den Skripten eingesetzt.
Bitte was?
lg
Erik
Mangels Standardisierung handelt es sich damit um proprietäre Erweiterungen. Sie sorgen dafür, dass andere Shells solche Skripte nicht ausführen können.
Gibt es irgendwo ne Liste mit den Unterschieden? Ich muss ein paar /bin/bash-Scripte soweit anpassen das sie Posix-Konform sind (mir der dash laufen).
Thx
https://wiki.ubuntu.com/DashAsBinSh
Ansonsten gibt es noch im Debian-Paket "devscripts" das Programm "checkbashisms".
lg
Erik
Was bash, zsh, csh, sh, bsh usw usw ist weiß ich ja, nur dash war mir neu =)
http://www.roesch-swiss.ch/?id=1159&prod_id=33
http://de.wikipedia.org/wiki/Linux_(Waschmittel)
libgnome ist bei mir noch 2.22
Aber KDE 4.1 *SCHAUDER!* Ich muss wohl mal "man growisofs" lesen, weil wenn k3b auf den libs laueft dann brenn ich von jetzt an nur noch aus der Konsole...
(Ohne Backports oder ähnliches)
Für besonders interessante Pakete wird ja oft eine Ausnahme gemacht, aber halt nicht bei allen.
Nutze einfach Debian testing oder unstable bzw. kompiliere dir die allerneusten Etnwicklungsversionen, wenn Du denn unbedingt auf den allerneusten Stand sein willst.
Um wichtige oder vielbenutzte Programme in einer erträglich aktuellen Version anzubieten?
Man muss halt irgendwann den Schlussstrich ziehen welche Software noch mitkommt.
Und die einmal stabile Basis im nachhinein zu verändern halte ich für problematisch.
Bei einem aktuellen Debian gibt es nur sehr wenige Programme die arg veraltet sind.
OpenOffice habe ich in der neusten Version installiert. Das wars schon.
Jeder hat halt ein oder zwei Programme die immer topaktuell sein sollen. Aber darauf kann man bei einer Massendistri keine Rücksicht nehmen.
Echt? Das habe ich in den letzten Jahren auf mehreren PCs und Thinkpads mit Debian testing nicht gemerkt!
Weshalb versteht niemand meinen Humor? Na ja, ... egal.
Seit der Ankündigung hat sich nach außen hin ja nicht mehr viel getan.
Kommt das noch vor Lenny?
aber du gehst mit deinem Etch 1/2 eher auf den Kernel ein oder ?
der soll sich aber automatisch mit dem 4.0r4 ändern! (so ist mein letzter Stand)
Etch 1/2 sollte ja zusammen mit r4 herauskommen, inklusive dem 24er Kernel der schon während der Installation benutzt wird.
Du schreibst, dass ein neuer Kernel sowieso mit r4 herauskommen soll. Wird dieser dann auch schon im Installer Verwendung finden?
Weiß jemand, wie es unter lenny mit der Unterstützung von efi auf amd64-systemen (-> apple macbook) aussieht? Bei etch ist dieses Problem als bug dargestellt (z.B. auf wiki.debian.com/Macbbok), wodurch es schwierig ist, debian mit amd64-architektur aufm macbook zum laufen zu bringen (habe es nicht geschafft).
LG
(/me hat so ein Ding mit etch aufgesetzt und dann dist-upgraded auf sid)