bat-Datei unter Linux

[MaSch]

Seit ein paar Tagen habe ich mir SuSe 10 zugelegt und auch schon vorsichtige Schrittchen gemacht, wie z.B. Java 1.5 und Netbeans 5/2 installiert.Um auch mal ein Java-Programm ohne viel Tipparbeit aufzurufen, würde ich mir gern eine "bat-Datei" :
cd /home/michael/jwork/alpha
java -classpath ./bin/hsqldb.jar:./bin/alpha.jar alpha.Alpha
schreiben und auf dem Desktop als Icon ablegen.
Ich habe mir das Buch "Linux von Michael Kofler gekauft und lese auch fleissig. Aber es sind über 1000 Seiten. Für eine Hilfe (bis ich es selber kann) wäre ich sehr dankbar.
M.S.

 

[admine]

Schreib die Kommandos in eine Textdatei und
mach diese mit chmod ausführbar.

vi MyScript.sh

#!/bin/bash
cd /home/michael/jwork/alpha
java -classpath ./bin/hsqldb.jar:./bin/alpha.jar alpha.Alpha

chmod 755 MyScript.sh
./MyScript.sh

Weitere Infos bringt dir die ForenSuche

 

[gameboy]

Hallo MaSch,

noch ein Tip: Falls Dir vi als Editor nicht so liegt (ist für Normalsterbliche wie mich eher unintuitiv zu bedienen), dann kannst Du z.B. auch mcedit verwenden, das ist der Editor des Midnight Commanders (mc). Weitere Alternativen, die aber i.d.R. erst installiert werden müssen: joe, pico, nano...

Sollte Dir eine grafische Oberlläche wie KDE zur Verfügung stehen, kannst Du Textdateien auch mit kwrite oder mit kate editieren.

Viele Grüße,
gameboy.

 

[MaSch]

Recht herzlichen Dank für die Codezeilen. Hat ohne Probleme auf Anhieb geklappt. Daß der vi nichts für "Weicheier" ist, hatte ich schon mal gehört. In der Steinzeit gab es auch einmal einen ähnlichen Editor für DOS. Ich habe gedit genommen -> Weichei
Nochmals Danke M.S.

 

[basman]

Daß der vi nichts für "Weicheier" ist, hatte ich schon mal gehört. In der Steinzeit gab es auch einmal einen ähnlichen Editor für DOS.

Da muss ich als vi-Fan natürlich meinen Senf abgeben. Jenes Urtier unter DOS war ein Zeilen-Orientierter Editor. Nicht zu vergleichen mit vi, dem Monster. Vor allem vim (wird heutzutage meist anstelle von vi aber unter dessen Bezeichnung in die Distros aufgenommen) kann einiges, wovon andere Konsole-Editoren nur träumen: Maussteuerung, mehrere Dateien gleichzeitig auf den Schirm... Ok. Genug jetzt.

Viel Spass weiterhin beim Tuxboxen!

 

[abgdf]

Hallo MaSch,

auf meiner Seite

http://www.angelfire.com/linux/tux25/

beschreibe ich allerhand Sachen, z.B "Eigene Skripte verwenden" (gerade überarbeitet) und "Editor vi", alles so kurz wie möglich, aber so, daß man es ohne weitere Kenntnisse verstehen können soll.
Im Grunde das für die Praxis, was ich in dem - ansonsten sehr guten - Kofler nicht gleich gefunden habe.
Vielleicht findest Du das ja nützlich. Deine Fragen hatte ich mir beim Windows-Umstieg ja auch gestellt.

Linux-Skripte sind übrigens viel gebräuchlicher und mächtiger als Windows bat-Dateien. Sie sind der Einstieg zur Programmierung, und das System steht einem dabei offen.

Viele Grüße

 

[MaSch]

Hallo abgdf,
herzlichen Dank für den Hinweis auf deine Seite. Ist recht viel zu lesen und sicherlich nicht an einem Abend zu erledigen. Also alles schön der Reihe nach.
Mein Hauptinteresse liegt in der Programmierung mit Java. Mit Linux kann ich auch nur arbeiten, weil Java-Programme eben auch unter Windows laufen. Den ersten, etwas tieferen "Linux-Durchblick" brauche ich bei der Installation von Programmen. Ich möchte z.B. eine neue Java-Version installieren, die alte soll aber noch erhalten bleiben. Über ein rpm Packet wird aber z.B. die alte Version überschrieben. (Habe ich schon probiert -> Java 1.4.nach 1.5) In Windows geht das über das Setzen von Systemvariablen JAVA_HOME und PATH. Einen ähnlichen Mechanismus gibt es wohl in Linux auch - irgendwie über export. Wie aber schalte ich zwischen den Versionen hin und her? Was ist mit der über rpm installierten update Version 1.5. Wie kann ich das rückgängig machen? Ist dann der Eintrag in PATH für alle Programme die Java benutzen ausreichend? In welches Verzeichnis installiere ich sinnvollerweise *.tar Pakete. Nach usr/und dann?
Leider läßt sich "Kofler" darüber auch nicht aus. Da gibt es nur einen Satz: Vermeide andere als rpm-Installationen. Nicht sehr hilfreich. Vielleicht gibt es ja irgendwo ein "HowTo"? Für ein paar Tips wäre ich recht dankbar.
Guten Rutsch ins Neue Jahr
Gruß M.S.

 

[basman]

Ich möchte z.B. eine neue Java-Version installieren, die alte soll aber noch erhalten bleiben. [...] In Windows geht das über das Setzen von Systemvariablen JAVA_HOME und PATH. Einen ähnlichen Mechanismus gibt es wohl in Linux auch - irgendwie über export. Wie aber schalte ich zwischen den Versionen hin und her?

Wenn Du mit Eclipse entwickelst, kannst Du für jedes Projekt die zu verwendende Java-Umgebung anhand des Verzeichnisses festlegen. Für selbständig laufende Anwendungen kannst Du ein Startscript bauen, welches PATH und JAVA_HOME entsprechend setzt, bevor java gestartet wird. Beispiel:

export PATH=/opt/jdk1.4.2_06/jre/bin
export JAVA_HOME=/opt/jdk1.4.2_06

Am besten bei SuSE abgucken, auf welche Unterverzeichnisse das Zeug genau zeugen muss.

Was ist mit der über rpm installierten update Version 1.5. Wie kann ich das rückgängig machen?

Einfach das RPM wieder deinstallieren (wenn per Befehlszeile installiert, mit rpm -e paketName) und von der ursprünglichen Quelle die alte Version installieren.

Ist dann der Eintrag in PATH für alle Programme die Java benutzen ausreichend?

Schwer zu sagen. Eclipse unter Windows war von JAVA_HOME abhängig.

In welches Verzeichnis installiere ich sinnvollerweise *.tar Pakete. Nach usr/und dann?

Für Deine Zwecke ist es sicher gut, tar.gz-Archive zu installieren. Bei Java liegen alle Dateien ohnehin unter einem einzigen Verzeichnis, so dass das Deinstallieren von Hand kein Problem ist. Üblicherweise installiert man solche tar.gz-dinger nach /usr/local oder nach /opt. Unter /opt ist es übersichtlicher, weil sich dann Dein Java-SDK-Verzeichnis nicht unter /usr/local/{etc,bin,lib,man,..} mischt und für die Funktionalität macht es nichts aus.

 

[taki]

Vorsicht. *.tar heist erst einmal nur, dass hier ein Archiv vorliegt. Was dort wie zu installieren ist, kann variieren.

Sehr verbreitet sind unter Linux (eigentlich überall im Open Source-Bereich) die sogenannten Tarballs. Das sind komprimierte Tar-Archive (*.tar.gz, *.tgz, *.tar.bz2), die Quellcode enthalten. Dieser ist i.d.R. so aufbereitet, dass man eine Installation nach Entpacken und Wechsel in das entstandene Source-Verzeichnis mit dem folgenden Dreisatz installieren kann:

./configure
make
make install

Seltener, aber auch verbreitet sind komprimierte Archive mit Binärdateien. Diese sollen meistens auf der obersten Verzeichnisebene entpackt werden. Die Binärdateien landen dann automatisch in den (hoffentlich) richtigen Verzeichnissen.

In jedem Fall sollte man bei einer Installation von einem Archiv erst hineinschauen, ob dort Hinweise über die Installation enthalten sind. Ein solches Archiv sollte eigentlich immer eine Textdatei mit dem Namen README enthalten.

Noch ein ganz wichtiger Satz: Wer Tarballs (welcher Art auch immer) installiert, muss wissen was er tut. Er umgeht damit die Paketverwaltung seines Systems.

Diese Paketverwaltung mag für einem Umsteiger, der von einem anderen System kommt, komplex scheinen, aber er hat einen wichtigen Vorteil. Die Aufgabe der Paketmanager wie RPM ist es, die Konsistenz der installierten Programme sicherzustellen. RPM erkennt Abhängigkeiten und warnt, ehe man sich möglicherweise sein System zerschießt.

Zwei Versionen von Java gleichzeitig zu installieren ist nicht gerade eine Einsteiger-Aufgabe. Möglich ist es aber. Es sollte auch mit RPM gehen.

Möchte man zwei RPM-Versionen installieren und RPM lässt das nicht zu, kann man zur Not eine der beiden aus der Datenbank von RPM entfernen. Installieren erst die alternative Version und lösche sie dann mit folgendem Befehl aus der RPM-Datenbank:

rpm -e --justdb xyz

Anschließend installierst Du die andere Version.

Das funktioniert, wenn die Dateien aus den beiden Paketen sich nicht gegenseitig überschreiben. Welche Dateien installiert werden kannst Du Dir von RPM mit folgendem Befehl anzeigen lassen:

rpm -qf xyz

[edit] Schreibfehler korrigiert und Paketmanager gegen Paketverwaltung ausgetauscht. RPM ist kein Paketmanager. Sehr schön passt dazu die Wikipedia-Definition (http://de.wikipedia.org/wiki/Paketmanager).

 

[basman]

Wenn man ein installiertes Paket per --just-db aus der RPM-Datenbank lädt, kann man insbesondere im Falle eines Java-SDK gleich auf RPM verzichten (Ich finde den Tip dennoch toll). Das von java.sun.com verfügbare SDK für Linux ist ein selbstextrahierendes Binary (eingepackt in ein tar.gz), welches bei der Installation nach dem Zielpfad fragt. Dort gibst Du einfach /opt/jdk1.4.2 oder so an und schon hat sich die Sache ein für alle mal. Dieses Paket hängt nicht von anderen ab (sobald man eine einigermassen zeitgemässe Version einer gängigen Linux-Distribution verwendet ist das erforderliche auf jeden Fall in den basis-Paketen enthalten), wodurch man sich das "Abhängigkeitsbewusstsein" von RPM schenken kann.

Selbst für eine Anfänger funktioniert diese Lösung am besten. Hier kann man wirklich mal die ganze Wissenschaft ums Paketverwalten sein lassen und sich ums wesentliche kümmern: es zum Laufen zu bringen.

Diese Behauptungen gelten aber nur für den Fall von Java-Umgebungen. Andere Programme, da gebe ich taki völlig Recht: Finger weg von Basteleien.

 

[MaSch]

Erst einmal recht herzlichen Dank an alle. Ich finde es ganz toll, wie ihr euch hier um die newcomer kümmert.
Mein erster Eindruck von Linux: So kompliziert ist das ja alles gar nicht. In Verbindung mit Java wird es wohl recht einfach und übersichtlich. Es ist zwar noch viel zu früh, aber so ein paar Gedanken nehmen schon Gestalt an. Ich habe da einen Kunden der eine kleine Geschäftsanwendung (Windows - geschrieben in C++ mit Borland C++ Builder) im Zuge einer Erweiterung von mir auf Java-Swing umgestellt bekommt.
Auf seinem Rechner läuft noch Online-Banking und ein Zeiterfassungs-System. Diese Programme machen immer wieder Schwierigkeiten und der Rechner stürzt ab. Zum Teil bin ich da auch betroffen , wenn z.B. mein C++ Programm nicht vorher beendet wurde. Da hat es dann auch schonmal eine Index-Datei zerschossen.

Da könnte man doch für das neue Java-Programm eine Linux-Partition einrichten. Irgendetwas Schlankes - evtl. Ubuntu?
Da kann der unter Windows laufende Kram gerade machen was er will. Ist aber zukunftsmusik. Erst mal muß ich in Linux fitt werden.

Guten Rutsch und nochmals danke M.S

 

[abgdf]

Hallo MaSch,

da hast Du ja einiges vor .
Mehrere Java-Versionen zu betreiben, sollte eigentlich möglich sein.
Zumindest mehrere JREs hatte ich schonmal drauf (Sun, IBM, Blackdown).
Bezüglich rpm-Paketen empfehle ich zunächst den Abschnitt "Verwaltung der Linux-Softwarepakete / rpm" von meiner Seite (die ist ja nur 135 K groß und läuft einem von der Festplatte auch nicht so schnell weg ).
Sollte der Befehl rpm nicht das tun, was man will, kann man auch einzelne Dateien aus rpm-Paketen mit dem Midnight Commander herauskopieren, dazu Abschnitt "Midnight Commander" auf meiner Seite. (Linux-Gurus benutzen für sowas auch cpio (man cpio).)
Oder installier doch erst das ältere SDK, guck, wo was hininstalliert wurde (rpm -qli ...), kopier die Verzeichnisse woanders hin, z.B. nach /home/Benutzer und installier dann die neure Version mit rpm -i drüber.

Ein "schlankes Linux" neben Windows zu installieren, dürfte auch nicht ganz leicht werden. Neue Linux-Distros sind im allgemeinen recht groß, da auf neue Hardware mit viel Speicher ausgerichtet, ältere sind kleiner, kommen mit neuer Hardware oder neuen Features wie Blootooth/Firewire/USB aber oft nicht zurecht. Ich würde also eine neue Distribution wie SuSE 10 verwenden und alles deinstallieren, was nicht unbedingt gebraucht wird. Als Windowmanager würde ich dann z.B. nur WindowMaker verwenden (Abschnitt "Meine WindowMaker-Anpassungen" auf meiner Seite), nicht KDE oder so.
Der Schreibzugriff von Linux auf Fat32 (Win98) läuft, auf NTFS (Win2000, XP) galt er jedoch bisher als lediglich "experimentell". Ich weiß nicht, ob das schon besser geworden ist. Der unmittelbare Datenaustausch mit Windows könnte dann am Ende also auch ein Problem werden.

Viele Grüße

 

[TeXpert]

Mehrere Java-Versionen zu betreiben, sollte eigentlich möglich sein.
Zumindest mehrere JREs hatte ich schonmal drauf (Sun, IBM, Blackdown).

das geht im Prinzip genauso problemlos wie unter jedem anderen Systen. man muss nur die passenden Pfade konfigurieren Hier könnten die _nicht_ RPM-Versionen dann ein deutlicher Vorteil sein, die also brav nach /usr/local/foo1 bis fooN installieren und die Pfade setzen.

 

[abgdf]

@ TeXpert: Ja, das sehe ich auch so.

Noch zu NTFS-Schreibzugriff:
Bisher hat man dann auf solchen Systemen noch eine zusätzliche Fat32-Partition eingerichtet, auf die man dann sowohl von Windows XP, als auch von Linux aus zugreifen kann.

Beste Grüße