PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Programme installieren (.tar.gz) unter Linux


illCP
17. March 2005, 00:21
Hi und schonmal sorry für die Frage...;)

Ich weiß das die Frage des "Installierens" von Programmen schon auf diversen Pages und Foren beantwortet wurde - aber ich kapier's nicht...

Erstmal hab' ich mit meinem Suse 9.2 ein paar RPM's ausprobiert (z.B. Skype), das ist ja simpel und prinzipiell wie in Windows. Einfach "mit Yast öffnen", "Paket installieren" und gut.
Jetzt bin ich aber den Konqueror leid und hätte gerne den Firefox. Gesagt - getan und mir den Spaß gezogen.

Jetzt habe ich eine Datei namens "firefox-1.0.1.installer.tar.gz" in /home/cpw/Documents. Nach ein wenig googlen hab' ich immerhin schonmal herausgefunden, dass das wohl ein GZ-komprimiertes TAR-Archiv ist und man die Konsole mit Alt+F2 und "Konsole" öffnet... :redface:

Dann hab' ich auch noch irgendwo eine Info gefunden, wie man diese tar.gz-Archive entpackt:
Erstmal ins passende Verzeichnis wechseln:
cd /home/cpw/Documents
dir
(fast wie damals in DOS...;))
Da seh' ich jetzt mein Archiv wieder. Irgendwo hab' ich gelesen, dass man tar.gz-Archive so entpackt:
tar -xvfz firefox-1.0.1.installer.tar.gz
Da passiert leider folgendes:
tar: z: Kann open nicht ausführen.: Datei oder Verzeichnis nicht gefunden
tar: Nicht behebbarer Fehler: Programmabbruch.
Dann hab' ich mal per tar --help versucht zu begreifen, was die Optionen -xvfz bedeuten könnten, habe herzlich wenig verstanden und es einfach mal nur mit -xf versucht:
tar: Das sieht nicht wie ein ?tar?-Archiv aus.
tar: Springe zum nächsten Kopfteil.
tar: Archiv enthält veraltete Base64-Kopfteile
tar: Read 2805 bytes from firefox-1.0.1.installer.tar.gz
tar: Fehler beim Beenden, verursacht durch vorhergehende Fehler.
Benutze ich nur -x verabschiedet sich die Konsole irgendwie... das "cpw@cpwlinux:~/Documents>" ist verschwunden, ich kann eingeben was ich will, nichts passiert und beim Drücken der Pfeiltasten erscheinen ^[[A, ^[[B, ^[[C oder ^[[D, je nach Taste... ?!

Das schlimme ist ja, dass ich's vorhin irgendwie geschafft habe, ein anderes tar.gz-Archiv in einen eigenen Ordner, der dann angelegt wurde, zu entpacken - ich weiß nur nicht mehr wie...

Frei nach Radio PSR Sinnlos Telefon: "ISCH WERD' NOCH 'EMA BLEEDE MIT DEM SCHAEISDING !" :D

Hat mal jemand einen Tip ? Ein schönes, einfaches Firefox-RPM habe ich leider nicht gefunden.

ElkOne
17. March 2005, 00:57
Hi illCP,

schon versucht, das Archiv mit Ark zu entpacken? Dazu im Konqueror mit Rechtsklick auf das Archiv, die passende Option wirst du dann schon selbst finden...

seeigel
17. March 2005, 06:46
den habe ich auch installiert -aber unter Suse 9.1
danach bin ich vorgegangen http://forum.gleitz.info/showthread.php?t=18734
also :
Erstellt erst mal ein Verzeichnis, wo eure Tarballs rein kommen.
# mkdir -p /usr/src/tarballs
# cd /usr/src/tarballs
in dieses verzeichniss den installer kopieren
# cd ..
# tar xvfz tarballs/firefox-1.0.1.installer.tar.gz
# cd firefox-1.0.1 (glaube du musst nachsehen ob der Name stimmt)
den Rest weis ich nicht mehr auswendig
den Firefox musst du mit Console starten - es sei denn du legst eine Verknüpfung auf den Bildschirm

Selur
17. March 2005, 07:27
<kbd>zu Bedeutung von:
tar -xvfz ist abgekürzt für tar -x -v -f -z
</kbd>




-x
--extract
--get Extract files from an archive. The owner, modification
time, and file permissions are restored, if possible. If
no file arguments are given, extract all the files in the archive.
-v
--verbose Lists files written to archive with --create or
extracted with --extract; lists file protection
information along with file names with --list.

-f [hostname:]file
--file [hostname:]file Read or write the specified file (default is
/dev/sa0). If a hostname is specified, gnutar
will use rmt(8) (http://www.hmug.org/man/8/rmt.html) to read or write the specified
file on a remote machine. ``-'' may be used as a
filename, for reading or writing to/from stdin/stdout.
archive. If a filename argument matches the name of a
directory on the tape, that directory and its contents are
extracted (as well as all directories under that direc-
tory). If the archive contains multiple entries corre-
sponding to the same file (see the --append command
above), the last one extracted will overwrite all earlier
versions.
-z
--gzip
--ungzip
--gunzip Filter the archive through gzip(1) (http://www.hmug.org/man/1/gzip.html).
--use-compress-program program
Filter the archive through program (which must
accept -d to mean ``decompress'').
Quelle: liefert ein "man tar"; man für manual ;)

Cu Selur

Henrik
17. March 2005, 09:33
@illCP
Firefox RPM
evt.deutsche Sprachdatei nachladen.
ftp://ftp.suse.com/pub/projects/mozilla/

ac-chan
17. March 2005, 10:03
Du hast ganz einfach das z und f verwechselt. es muss "tar -xvzf firefox-1.0.1.installer.tar.gz" heissen. hinter dem f MUSS die Datei angegeben werden. da du aber die nächste option angibst, kommt der standard Optionsparser von Linux durcheinander.

zisoft
17. March 2005, 10:26
@ac-chan: Nope, das funktioniert auch so.

Alternativ kann man das gezippte tar-Archiv auch erst mal unzippen:

gzip -d firefox-1.0.1.installer.tar.gz

oder

gunzip firefox-1.0.1.installer.tar.gz


Übrig bleibt dann das reine tar-Archiv unter dem Namen firefox-1.0.1.installer.tar, was dann mit

tar xvf firefox-1.0.1.installer.tar

ausgepackt werden kann. Normalerweise schafft der tar das aber in einem Rutsch.

ac-chan
17. March 2005, 11:02
Was heißt hier nope? Hinter f muss der Dateiname kommen. Ausserdem warum vergißt die halbe Welt imer das "-"?

Trekkie2
17. March 2005, 11:17
Also getestet hab ichs nicht, aber es ist doch eine einfach Faustregel:
Als Letztes vor dem F(!)ilenamen das f - und alles geht gut!
Außerdem deutet diese Fehlermeldung
tar: z: Kann open nicht ausführen.: Datei oder Verzeichnis nicht gefunden
schon irgendwie darauf hin :D

ac-chan
17. March 2005, 11:20
Genau das habe ich geschrieben. er hatte z und f vertauscht, weshalb das z als dateiname genutzt wurde. Da er aber anscheinent keine Datei mit dem namen z hat die Fehlermeldung.
Nochmal die Frage, warum bin ich deshalb ein nope?

Trekkie2
17. March 2005, 11:25
Nochmal die Frage, warum bin ich deshalb ein nope?
Das hätte mich auch interessiert, daher wollte ich Dir zur Seite stehen :D

ac-chan
17. March 2005, 11:28
Sorry habe das durcheinander gebracht. :hm:

zisoft
17. March 2005, 11:37
Nope heisst "nein" und yep heisst "ja" ;)

Und meine gezippten tar-Archive packe ich immer mit

tar xvfz <dateiname> aus, funktioniert auf allen Maschinen, auf denen ich mich herumtreibe.

ac-chan
17. March 2005, 11:47
Auf allen wo ich mal mit tar gearbeitet habe und in den man pages steht immer das ein "-" davor gehört und das zwischen f und Dateinamen nichts sein darf.
Auf was per Plattformen arbeitest du denn?

zisoft
17. March 2005, 11:48
Zuhause: Gentoo Linux

Auf der Arbeit: RedHat Linux, Solaris 7, Solaris 8, HP-UX, AIX

ac-chan
17. March 2005, 11:55
Und dakann man einfach das "-" weg lassen? Ich bekomme dann immer nur Fehlermeldungen. Und wenn ich zwischen f und Dateinamen was packe, entweder fehlermeldung oder (beim packen) wird es falsch benannt .

illCP
17. March 2005, 11:57
Vielen Dank, die Reihenfolge war's scheinbar. Mit -xvzf funktioniert's ! :)

Jetzt hab' ich unter /home/cpw/Documents einen Ordner namens /firefox-installer.

Darin sind:
config.ini
firefox-installer
firefox-installer-bin
header.png
install.ini
license.txt
watermark.png
xpi

Mit der Konsole hab' ich's nicht hinbekommen, wie würde ich das denn dann von da aus installieren ?

Ich hab jetzt einfach mal die "firefox-installer" mit den Konqueror per Doppelklick ausgeführt, das funktioniert. :)

Vielen Dank euch schonmal !

/EDIT:

So, eine Verknüpfung auf dem Desktop hab' ich auch hingekriegt. :)

@Selur: ich hatte mir die Infos über tar per "tar --help" anzeigen lassen, da steht ja so ziemlich das Gleiche drin. Aber so wirklich kapieren tu ich's trotzdem nicht...;)

ac-chan
17. March 2005, 12:07
In der Konsole(also dem Terminal Emulator von :kotz: KDE :kotz: ) ist es wie mit allen anderen Terminals einfach "./firefox-installer-bin".

illCP
17. March 2005, 12:10
"./firefox-installer-bin".
Aaah ! Danke, ich hatte es (wie damals bei DOS) nur mit "firefox-installer-bin" probiert und das "./" davor weggelassen. So funktionierts ! :)

LigH
17. March 2005, 13:54
Das "./" vor dem Dateinamen des Install-Skriptes scheint notwendig zu sein, damit die Shell (der Kommandointerpreter) diese Datei noch mal analysiert und nachschaut, ob es sich evtl. um ein Skript handelt, und welcher Interpreter es auszuführen hat. Was in diesem Fall ja auch so ist. Leider hab ich nie ganz begriffen, was genau da im Hintergrund abläuft - aber mir genügt schon, dass es damit normalerweise klappt.

Trekkie2
17. March 2005, 14:00
Nee, bei den meisten Distris ist aus Sicherheitsgründen ~ nicht im Pfad von root:
Wenn Du nen Scherzkeks hast, der ne Batch-Datei mit dem Namen ls anlegt und rm -rf / reinschreibt, hast Du sonst schlechte Karten...

[edit:]
...wenn Du als root mal in dessen Verzeichnis reinschauen mußt.

[edit2:] . nicht ~ :wall:

zisoft
17. March 2005, 14:04
Ich denke, das liegt eher daran, dass das aktuelle Verzeichnis "." nicht in $PATH enthalten ist, zumindest nicht standardmässig beim root-User.

[EDIT]: Trekkie war schneller ;)

Trekkie2
17. March 2005, 14:05
Sorry, meinte natürlich . nicht ~

Bei SuSE übrigens (mit Voreinstellung) nur für root, normale User ham . im Pfad.

[edit:]
Hoffentlich liest das niemand, der von Computern keine Ahnung hat - liest sich schon strange!

zisoft
17. March 2005, 14:09
Geht doch noch, solange wir nicht mit regulären Ausdrücken anfangen... ;)

LigH
17. March 2005, 14:11
Stimmt ja - DOS/Windows sucht erst im aktuellen Verzeichnis, dann weiter im Pfad; bei Linux war das irgendwie anders. Muss wohl noch mal meine SuSE-Enterprise-Lehrgangs-Hefter rausholen. Irgendwo da drin steht so was.

ac-chan
17. March 2005, 17:15
Bei allen Debian basierten distros ist per default kein "." im path. und das ist auch gut so. Schliesslich besteht die gefahr ja nicht nur für root, sondern dort nur besonders.

Das ./zwingt die schell(nicht Linux, denn das ist nur so ein komisches ding im hintergrund, manchmal auch Kernel genannt) im aktuellen Verzeichnis zu suchen.

@LigH:Hast du nicht mal gesagt du hättest von Linux einweig Ahnung. Schon die wichtigsten sachen vergessen? Willst du ein shell account bei mir zum üben?

LigH
17. March 2005, 17:32
@ ac-chan:

Ich habe SuSE und noch ein anderes Linux (wechselt manchmal) parallel laufen, brauche nur umzubooten. Nutze es nur nicht gerade oft (wenn man nicht muss, oder nicht gerade Vorteile davon hat).

zisoft
17. March 2005, 21:50
Jetzt habe ich mal etwas Licht in die tar-Parameterliste gebracht:

tar tvfz datei.tgz
tar xvfz datei.tgz
tar cvfz datei.tgz

liefern alle ein korrektes Ergebnis, so arbeite ich seit Jahren.

tar -tvfz datei.tgz
...

liefern

tar: z: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now

Wenn man also das Minuszeichen verwendet, muss der Dateiname auf den f-Parameter folgen.

LigH
17. March 2005, 21:52
Und das wäre einfach der nach dem Manual korrekte Weg. Die anderen werden möglicherweise als "Umsteiger-Hilfe" zusätzlich unterstützt?! -- Verlassen würde ich mich nicht darauf; besser gleich richtig, und gewusst warum.

Monk
10. April 2005, 17:47
Ich habe mit ZSNES ein ähnliches Problem.

Ständig bekomme ich Error-Meldungen. Kann mir jemand sagen, was ich falsch mache oder welche Bibliothek mir noch fehlt.



linux:/home/der_steiger/tarballs/zsnes/zsnes/src # sh ./autogen.sh && gmake && g
make install
Generating build information using aclocal and autoconf...
acinclude.m4:10: warning: underquoted definition of AM_PATH_ZLIB
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
acinclude.m4:121: warning: underquoted definition of AM_PATH_LIBPNG
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for nasm... nasm
checking for a BSD-compatible install... /usr/bin/install -c
checking for sdl-config... /usr/bin/sdl-config
checking for SDL - version >= 1.2.0... yes
checking for zlib - version >= 1.1.0... yes
checking for libpng - version >= 1.2.0... yes
checking how to run the C preprocessor... gcc -E
checking for X... no
checking for glGetError in -lGL... yes
checking for OpenGL... yes
checking if you want gdb friendly executable... no
checking which processor class to optimize for... 686
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether sys/types.h defines makedev... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: config.h is unchanged


ZSNES v1.42

SDL support Version 1.2.7
NASM support NASM version 0.98.38 compiled on Oct 2 2004
ZLib support Version 1.2.1
PNG support (png screenshots) Yes, version 1.2.6
OpenGL support Yes

The binary will be installed in /usr/local/bin

Configure complete, now type 'make' and pray.

gcc -pipe -I. -Wall -I/usr/local/include -I/usr/include -D__LINUX__ -I/usr/include/SDL -D_REENTRANT -D__OPENGL__ -O3 -ffast-math -fomit-frame-pointer -fexpensive-optimizations -s -march=pentiumpro -I. -o chips/dsp1emu.o -c chips/dsp1emu.c
In file included from chips/dsp1emu.c:27:
gblhdr.h:85:27: GL/gl.h: Datei oder Verzeichnis nicht gefunden
gmake: *** [chips/dsp1emu.o] Fehler 1
linux:/home/der_steiger/tarballs/zsnes/zsnes/src #

ac-chan
10. April 2005, 18:10
Was ist daran nicht zu verstehen?

"
gblhdr.h:85:27: GL/gl.h: Datei oder Verzeichnis nicht gefunden
gmake: *** [chips/dsp1emu.o] Fehler 1
"

Ausserdem, warum nutzt du gmake? Steht das in der INSTALL so drinnen? Wenn nicht, dann nutz lieber nur make.

PS: was hat das eigentlich mit dem vorigen Problem zu tun?
@Admin:
Abtrennen und neues Thema erstellen. Das ist ein Complier Problem und kein Problem mit Archiven(tar, gz, ..) oder den Komandozeilenoptionen.

Monk
10. April 2005, 18:38
@ac-chan

Danke für die Hilfe, aber warum haust Du die Leute gleich so an?

1.) Ich bin kein Programmierer und habe generell von Programmierung null Ahnung.
2.) Ich bin Linux-Neuling (jeder fängt mal an)
3.) ja, die Anleitung spricht von gmake, sonst käme ich garantiert nicht auf solche Ideen.

edit:

Übrigens die Fehlermeldung ist mir auch klar, aber warum erscheint dieser Fehler? Liegt es also nur an gmake? Oder fehlt noch etwas?

ac-chan
10. April 2005, 19:02
Es fehlt eine Datei sagt dir die Fehlermelung, also fehlt eine Datei. Schaudoch mal unter /usr/include/GL ob es dort eine gl.h gibt. Ich nehme an nein. Du must also noch die Bibliothek OpenGL nachinstallieren. Du du ja anscheinen die INSTALL gelesen hast, müsstest du eigenlich wissen, das sie anscheinent Vorrausgesetz wird. Es könnte sein das du nochmehr Fehlermeldungen bekommst. Bitte installiere erst alle Bibliotheken die benötig werden.

Und das ist kein anhauen, sondern ich kann es nicht verstehen was an dieser Fehlermeldung nicht zu verstehen ist. Auch ich bin kein Linux Guru und habe bei den meisten compilierungen meine Probleme, trotzdem sollte man solche Meldung verstehen.

Monk
10. April 2005, 19:21
JA, ich habe die Installationsbeschreibung oder denkst Du, ich haue als Neuling mal so einfach in die Tasten und gut ist? (Ich weiß garnicht, was die Anspielung zu bedeuten hat?) Trotzdem Danke.


edit: Es gibt eine Datei gle.h

ac-chan
10. April 2005, 20:16
Dir ist schon klar, das gl.h und gle.h zwei verschiedene Dateinamen sind? Solangsam bin ich geneigt, supportgebüren zu erheben. ;)

Monk
10. April 2005, 21:36
Ja natürlich ist mir das klar. Ich habe mir nur gedacht, daß es Dir eventuell helfen könnte (hätte ja sein können) :D . Aber Open-GL-Anwendungen sind doch in der Regel für 3D da, warum sollte ein SNES-Emulatur, der absolut Null mit 3D zu tun hat, Open GL nutzen?

ac-chan
10. April 2005, 21:51
OpenGL ist eine Schnitstelle/Abstraktion für Grafikkarten. Für weitere frage die Leute die das Ding Programiert haben.

LigH
10. April 2005, 22:00
Man kann OpenGL auch problemlos für die Beschleunigung (oder hardwareunabhängige Verwendung) von 2D-Ausgaben verwenden. Beispielsweise das "Texturieren" von geometrischen "Primitiven" (z.B. rechteckigen Flächen) ist eine der leichtesten Übungen für ein OpenGL-Treiber-Set, das emuliert zur Not sogar die CPU mit den einfachsten Grafiktreibern.

Monk
10. April 2005, 22:10
Ich habe genau wie mein Bruder eine ATI Radeon Karte. Irgendwann im Sommer letzten Jahres habe ich mich schon einmal ein paar Wochen lang mit Linux beschäftigt und ich weiß, daß ich zsnes einmal kompiliert hatte auf meinem damaligen Suse-System. Da Suse von Haus aus mit Radeon Karten nur 2D kann und ich dies nicht durch einen Treiber geändert habe (was zwar mühselig, aber möglich ist), frage ich mich nun, wie ich dies dann gemacht habe. Die Open-GL-Treiber sind angeblich in dem Paket fglrx von ATI enthalten, dies hatte ich nie installiert. Eine andere Möglichkeit wäre natürlich, daß das update des zsnes neuerdings open-gl einbezieht, was vielleicht früher nicht der Fall war.

ac-chan
10. April 2005, 22:14
Bist du sicher, das damals kein OpenGL installiert war? Vielleicht hatte irgent ein anderes Programm ja OpenGL benötig und es war darum schon installiert.

LigH
10. April 2005, 22:18
Funktionierende Grafikausgabe in einem OpenGL-Fenster oder Vollbild setzt noch nicht mal eine 3D-Beschleuniger-Karte voraus. Für vorteilhaft hohe Bildraten wäre sie aber zumindest nützlich...

Monk
10. April 2005, 22:36
Irre ich mich denn jetzt, daß open gl nur in diesem ATI-rpm-Paket drin war oder gibt es open-gl als eigentständiges Suse-rpm-Paket?

LigH
10. April 2005, 22:47
OpenGL besteht aus zwei Teilen:

1) Die hardware-unabhängigen grundlegenden Funktionen

2) Die hardware-optimierten Treiber für die Beschleunigerfunktionen

Der Teil 1 ist notwendig, damit grundsätzlich überhaupt OpenGL-Funktionen benutzt werden können; (frei nach Loriot) "es sollte in keiner Distribution fehlen".

Teil 2 ist nicht überlebensnotwendig - zur Not wird per Software emuliert; aber wenn man Teil 2 installieren will, dann meist als "Kernel-Modul" (reicht tief ins Betriebssystem hinein - um überhaupt direkt auf die 3D-Karten-Funktionen zugreifen zu dürfen!).

Monk
18. July 2005, 14:12
Das Paket, das die Open-GL-Treiber enthält, nennt sich xorg-mesa devel. Jetzt habe ich zsnes kompiliert und es ruckelt auf grausame Art und Weise. :D