ubuntuusers.de

Hallo,

dieser Artikel soll im Hauptartikel Skripte eingebunden werden.

bye TT

Hallo,

du solltest IMHO die Einleitung des Artikels noch um 1-2 Sätze erweitern. Im Moment fällt man da ziemlich mit der Tür ins Haus 😉

Gruß, noisefloor

besser?

bye TT

Hallo,

ja, so ist die Einleitung IMHO viel besser ☺

Gruß, noisefloor

Ich halte es für keine gute Idee sudo im Skript selber zu verwenden. Üblich ist eigentlich, dass man lediglich darauf hinweist, dass etwas mit root-Rechten ausgeführt werden muss.

mrkramps schrieb:

Ich halte es für keine gute Idee sudo im Skript selber zu verwenden.

Wieso?

Ohne Root-Rechte laesst sich Oracle Java nun mal nicht installieren. Mich stoert eher etwas anderes: die Installation von Oracle Java ist kein einmaliger Vorgang, sondern wer sich darauf einlaesst, muss diese Installation fortlaufend pflegen. Wo im Skript wird beruecksichtigt, alte Versionen sauber (inkl. der Eintraege im Alternativen-System) zu entfernen?

user unknown schrieb:

mrkramps schrieb:

Ich halte es für keine gute Idee sudo im Skript selber zu verwenden.

Wieso?

Meine Meinung, der darf gerne jeder widersprechen.

Es mag vielleicht - insbesondere in Bezug auf den Timeout - Gründe geben, dass man sudo im Skript nur für die einzelnen Befehle ausführt. Ich empfinde das aber als transparenter und in Anbetracht der üblichen, vom Benutzer explizit initierten Verwendung von sudo auch konsistenter, wenn man das nicht einfach im Skript einbettet und den Anwender dann mit einer undokumentierten Passwortabfrage beim Ausführen des Skriptes abspeist.

aasche schrieb:

[...] Mich stoert eher etwas anderes: die Installation von Oracle Java ist kein einmaliger Vorgang, sondern wer sich darauf einlaesst, muss diese Installation fortlaufend pflegen. Wo im Skript wird beruecksichtigt, alte Versionen sauber (inkl. der Eintraege im Alternativen-System) zu entfernen?

bisher gar nicht.

Alle Alternativen zu entfernen schießt wohl über das Ziel hinaus.

Mal sehen, ob ich wenigsten die früheren Bugfix-releases der aktuellen Oracle-Java-version identifizieren kann...

bye TT

mrkramps schrieb:

user unknown schrieb:

mrkramps schrieb:

Ich halte es für keine gute Idee sudo im Skript selber zu verwenden.

Wieso?

Meine Meinung, der darf gerne jeder widersprechen.

Ich empfinde das aber als transparenter und in Anbetracht der üblichen, vom Benutzer explizit initierten Verwendung von sudo auch konsistenter, wenn man das nicht einfach im Skript einbettet und den Anwender dann mit einer undokumentierten Passwortabfrage beim Ausführen des Skriptes abspeist.

Die Passwortabfrage ist genauso undokumentiert, ob das ganze Script per sudo gestartet werden muss oder im Skript sudo aufgerufen wird. Wenn man es für den einen Fall ändert kann man es auch für den anderen Fall ändern.

user unknown schrieb:

[…]

Die Passwortabfrage ist genauso undokumentiert, ob das ganze Script per sudo gestartet werden muss oder im Skript sudo aufgerufen wird. Wenn man es für den einen Fall ändert kann man es auch für den anderen Fall ändern.

Ich erlaube mir das Zitat zu kürzen.

Für mich ist die Sache damit erledigt. Ich wollte meine Bedenken zumindest geäußert haben.

Da es keine schwerwiegenden Kritiken zu meinem Entwurf gab bitte ich um Veröffentlichung.

bye TT

Timothy_Truckle schrieb:

Da es keine schwerwiegenden Kritiken zu meinem Entwurf gab

Aha... dann etwas deutlicher: was soll dieser stuempferhafte Quatsch im Wiki? Als ob man Oracle Java nur einmal installieren muesste und dann pflegt es sich von selbst? Mit anderen Worten: Das Skript in der derzeitigen Form ermoeglicht zwar eine mehr oder weniger bequeme Erstinstallation. Aber sobald das erste Update ansteht, steht ein potentieller Nutzer voellig im Regen, weil er a) keine Ahnung hat, was dieses Skript ueberhaupt treibt und b) sich haufenweise Dateileichen im Oracle-Ordner ansammeln. Darueber hinaus ist voellig unklar, welche der zahlreichen unterschiedlichen Java-Versionen von Oracle sich damit ueberhaupt installieren lassen soll.

Als Minimum erwarte ich daher das Bereinigen des Ordners /opt/Oracle_Java/, bevor die naechste Version druebergebuegelt wird. Und mindestens eine weitere unabhaengige Bestaetigung, das dieses Skript tatsaechlich wie erwartet funktioniert.

Was der ganze Quatsch mit dem Alternativen-System soll, erschliesst sich mir auch nicht. Wuerde man die Versionsangabe aus der heruntergeladenen Archivdatei weglassen, braeuchte man diese Befehle exakt ein einziges Mal.

aasche schrieb:

Was der ganze Quatsch mit dem Alternativen-System soll, erschliesst sich mir auch nicht. Wuerde man die Versionsangabe aus der heruntergeladenen Archivdatei weglassen, braeuchte man diese Befehle exakt ein einziges Mal.

Anwender haben meist nur eine Programm, das neueste, installiert. Entwickler müssen oft für die Pflege alter Software alte SDKs weiter vorhalten. Und zum Test ob es mit diesem und jenem funktioniert hat man Oracle-Java und Open-Java parallel installiert und alte Versionen löscht man auch nicht automatisch.

Mit dem alternatives-System kann man java, javac, jar, jarsigner und ca. 20 andere Programme auf einen Rutsch umschalten von 1.8 auf 1.7 und von Ora nach Open.

Hallo,

zum Artikel an sich:

• es sind noch direkte Anreden drin - die sind im Wiki ein no-go

• Stimmt der Satz zum Aufruf des Skripts, wie er im Artikel steht? Sofern mich meine spärliche Shellskript Kenntnisse nicht täuschen, sucht das Skript doch im ~/Downloads Ordner nach der Datei, wenn keine beim Befehlsaufruf vorgegeben wird.

• Entweder müsste aasches Vorschlag umgesetzt werden _oder_ es müsste der explizite Hinweis in den Artikel, das vorherige Java-Versionen eben _nicht_ entfernt werden. Konsequenterweise mit einem Link auf den Wikiartikel zur De-Installation von alten Java-Versionen.

• Es sollte noch ein Hinweis in der Artikel, dass das Skript nichts anderes macht, als unter Java/Oracle Java beschrieben, nur halt automatisch.

Gruß, noisefloor