ich hab folgendes Problem:
Mein Linuxrechern erkennt in der Konsole keine Standartbefehle mehr, wie
z.B. dir, ls, rcnetwork und änhliches.
Ich habe nur eine Profile.local angelget und den Classpath und path für den
J2SDK gesetzt, seit dem gibt es das Problem. Ich hab die datei Bereits
wieder gelösch und die datei Profile wieder in den Urzustand zurück
versetzt. Wenn ich etwas über die grafische Oberfläche löschen will
funktioniert alles.
Über Hilfe wäre ich sehr dankbar, da ich eine Neuinstallation von Linux
umgehen möchte, weil der Rechener mit den Anderern diensten Perfekt läuft.
Ich hab schon die Suse Support-Datenbank durchsucht und google befragt, hab
aber keine sinnvollen lösungen gefunden. Ich benutz SUsE linux 7.2. kernle
2.2.4.
Über Antworten wäre ich euch im Vorraus schon sehr dankbar.
MFG
Sven Kolbe
Wie immer: Wie lautet die Fehlermeldung?
Was sagt »echo $PATH«?
> Ich habe nur eine Profile.local angelget und den Classpath und
> path für den J2SDK gesetzt, seit dem gibt es das Problem.
Du meinst, Du hast die Variable PATH in der Datei
/etc/profile.local verändert? Wahrscheinlich rührt da der Fehler
her.
> Ich hab die datei Bereits wieder gelösch und die datei Profile
> wieder in den Urzustand zurück versetzt.
Es sind schon Leute für weniger erschossen worden als die Aussage:
"Ich habe alles wieder zurückgestellt!"
Sorge bitte dafür, daß Deine Umlaute kodiert sind!
> Mein Linuxrechern erkennt in der Konsole keine Standartbefehle mehr, wie
> z.B. dir, ls, rcnetwork und änhliches.
> Ich habe nur eine Profile.local angelget und den Classpath und path für den
> J2SDK gesetzt, seit dem gibt es das Problem. Ich hab die datei Bereits
> wieder gelösch und die datei Profile wieder in den Urzustand zurück
> versetzt.
Die Datei heißt nicht "Profile" sondern "profile" (in /etc).
Groß-/Kleinschreibung spielt bei unixoiden Systemen eine wichtige Rolle.
Hast Du Dich aus- und wieder eingeloggt? Nach dem erneuten Anmelden
sollte wieder alles funktionieren (vorausgesetzt, daß die Datei wirklich
wieder mit der Ursprungsversion identisch ist).
Gruss,
Marcus
> Sven Kolbe <kolb...@web.de> wrote:
>
> Sorge bitte dafür, daß Deine Umlaute kodiert sind!
Was meinst du damit???
> Die Datei heißt nicht "Profile" sondern "profile" (in /etc).
> Groß-/Kleinschreibung spielt bei unixoiden Systemen eine wichtige Rolle.
Ich hab die alte Datei als Sicherung gespeicher gehabt und die neue damit
überschreiben, also muss sie indentisch sein.
> Hast Du Dich aus- und wieder eingeloggt? Nach dem erneuten Anmelden
> sollte wieder alles funktionieren (vorausgesetzt, daß die Datei wirklich
> wieder mit der Ursprungsversion identisch ist).
Ich hatte mich aus und eingelockt, es ging trozdem nicht.
Die Fehlermeldung heissen:
Bei Java:
Can't find runtime evoriment
Cant't find ios....
Danke nochmal für euere Hilfe
Gruss
Sven
> Ich hatte mich aus und eingelockt, es ging trozdem nicht.
> Die Fehlermeldung heissen:
> Bei Java:
> Can't find runtime evoriment
> Cant't find ios....
Vielleicht fangen wir mit etwas einfacherem an als java.
Was passiert nach der Eingabe von 'ls'?
Was sagt 'which ls'?
Ich kann diese Befehle nicht mehr eigeben, da sie die Bash nicht mehr
versteht. Wenn ich dir oder ls eingebebe oder irgeneinen anderern
Standartbefehel sagt die bash command not found
echo $PATH
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David....@t-online.de
> > Ich kann diese Befehle nicht mehr eigeben, da sie die Bash nicht mehr
> > versteht. Wenn ich dir oder ls eingebebe oder irgeneinen anderern
> > Standartbefehel sagt die bash command not found
>
> Was passiert nach der Eingabe von
>
> echo $PATH
Nicht vielleicht doch eher ``/bin/echo $PATH''?
> # David Kastrup wrote:
>> Was passiert nach der Eingabe von
>> echo $PATH
> Nicht vielleicht doch eher ``/bin/echo $PATH''?
Könnte auch gehen.
Bin überrascht, das /bin/echo existiert. Zumindest ist es
ein Bash-Kommando.
Gruss
Michael
> "Marcus Frings" <mf-u...@gmx.net> schrieb im Newsbeitrag
> news:<slrnap88b8.1...@gothgoose.net>...
Die Message-ID hier anzugeben ist überflüssig. Schau Dir bitte mal den
Link weiter unten an.
>> Sorge bitte dafür, daß Deine Umlaute kodiert sind!
> Was meinst du damit???
Die Angabe von
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
oder etwas ähnlichem in den Headern Deiner Postings.
Besuche bitte mal in Kürze http://www.oe-faq.de.vu!
Zu Deinem Problem hast Du ja schon von anderen Leuten entsprechende
Hilfe bekommen, darum spare ich mir jetzt weiteren Text dazu.
Gruss,
Marcus
'dir' ist kein Standard-Befehl.
Wie schon oefter erwaehnt: Was passiert, wenn du 'echo $PATH'
eingiebst? Was passiert, wenn du ein Programm mit vollem Pfad
eingiebst (z.B. '/bin/ls -l')?
Gruesse,
awiese
--
--- \|/ ______ \|/
Andreas Wiese "@' / , . \ `@"
awiese....@t-online.de /__| \____/ |__\
http://www.root-for-everybody.de.vu \___U__/
Nein.
$ help echo
echo: echo [-neE] [arg ...]
[und so einiges]
$ type echo
echo is a shell builtin
> > > Was passiert nach der Eingabe von echo $PATH
> > Nicht vielleicht doch eher ``/bin/echo $PATH''?
>
> Könnte auch gehen. Bin überrascht, das /bin/echo existiert. Zumindest
> ist es ein Bash-Kommando.
arne@lysander$ which echo
/bin/echo
arne@lysander$ type echo
echo is a shell builtin
Tatsache. War mir nicht bewusst. Dann war mein Senf ja unnötig.
Du (m.brandtner) meintest am 27.09.02:
>> Nicht vielleicht doch eher ``/bin/echo $PATH''?
> Könnte auch gehen.
> Bin überrascht, das /bin/echo existiert. Zumindest ist es
> ein Bash-Kommando.
Auch.
Probier mal aus:
/bin/echo --version
echo --version
Viele Gruesse!
Helmut
Sven Kolbe <kolb...@web.de> wrote:
> "Michael Brandtner" <m.bra...@gmx.de> schrieb im Newsbeitrag
> news:an1mus$3kp$01$1...@news.t-online.com...
Oh bitte, keine mehrzeiligen Einleitungen ...
>> Sven Kolbe wrote:
>> Vielleicht fangen wir mit etwas einfacherem an als java.
>> Was passiert nach der Eingabe von 'ls'?
>> Was sagt 'which ls'?
>> Was sagt 'echo $PATH'?
> Ich kann diese Befehle nicht mehr eigeben,
Falsch. Du kannst diese Befehle noch eingeben, erhaeltst aber eine
Fehlermeldung (vermutlich "bash: ls: No such file or directory").
Das vollstaendige zitieren von Fehlermeldungen ist bei Fragen *wichtig*,
ein "funzt net" traegt zum finden einer Antwort so ziemlich *gar nichts*
bei (und deine aussage "ich kann die Befehle nicht eingeben" ist ebenfalls
falsch, denn das kannst du sehr wohl, auch wenn das nicht die erwartete
Wirkung hat sondern nur zu Fehlermeldungen fuehrt).
> da sie die Bash nicht mehr versteht.
Wenn du deinen Fehler ausfuehrlicher beschrieben haettest, waeren vielleicht
auch weniger erfahrene Benutzer auf die Idee gekommen, dass du schlicht und
ergreifend mit deinen Aenderungen die Datei /etc/profile so geaendert hast,
dass das Environment nicht mehr gesetzt wird (insbesondere die Variable
PATH) und daher die shell die Programme nicht mehr findet.
> Wenn ich dir oder ls eingebebe oder irgeneinen anderern
> Standartbefehel sagt die bash command not found
^^^
"Standart" ist (wenn es ueberhaupt eine Bedeutung hat) bestenfalls die
Art zu stehen (und das hat mit dem Thema der Gruppe eher weniger zu tun).
Du meinst vermutlich "Standard" ...
Auch hier hast du nicht die vollstaendige Fehlermeodung woertlich
zitiert. Bedenke, dass die Antworten meistens maximal so gut sein
koennen wie du deine Frage gestellt hast (und dazu gehoert genaues
zitieren von Fehlermeldungen, genaue Beschreibung der Probleme,
eine Beschreibung dessen, was du versucht hast um das Problem zu
loesen und eine genaue Beschreibung dessen, was du gemacht hast
unmittelbar bevor das Problem aufgetreten ist).
Du hast unmittelbar bevor das Problem aufgetreten ist die Datei
/etc/profile veraendert. Da nach einem anschliessenden "ausloggen
und wieder einloggen" das Problem auftrat, ist es sehr wahrscheinlich,
dass deine Aenderung der Datei /etc/profile die Ursache fuer dein
Problem ist. Du musst also (um dein System "wie gewohnt lauffaehig"
zu bekommen den alten Status wieder herstellen).
Das Problem ist nun, dass Befehle von der shell nicht gefunden werden.
Das liegt daran, dass der suchpfad fuer Programme nicht richtig gesetzt
ist. Das einloggen als "root" (das du hoffentlich nicht fuer taegliche
Arbeiten verwendest) mit anschliessender Eingabe der Kommandozeile
PATH=/bin:/usr/bin:/sbin:/usr/sbin
sollte der erste Schritt zur Loesung der Probleme sein (denn dann sollten
die "Standard-Befehle" wie ls, sp, mv, ... wieder gefunden werden.
Dann solltest du (mit "cp") die vorher angelegte Sicherung der Datei
/etc/profile wieder nach /etc/profile kopieren. Anschliessend ausloggen
und wieder einloggen und alles sollte in Ordnung sein.
Achte bitte in Zukunft *sorgfaeltig* darauf, was du wo hinzufuegst oder
aenderst. Es ist z.B. keine gute Idee, eine unix-Testdatei auf einem
DOS oder Windows System zu editieren und dann einfach zurueckzukopieren,
da das Format von Textdateien unter diesen Systemen und unter DOS unter-
schiedlich ist. Es ist keine gute Idee einfach mal so an wichtigen System-
dateien herumzuaendern ohne anschliessend *alle* durchgefuehrten Aenderungen
noch einmal *gruendlich* zu ueberpruefen (*vor* dem zurueckschreiben der
Aenderungen). Es ist i.a. eine gute Idee, fuer tests auf eine andere
Konsole zu wechseln und sich dort einzuloggen (damit auf der ersten Konsole
die bisherige Umgebung erhalten bleibt, das erleichtert die Korrektur von
Fehlern und haette dir auch in diesem Fall geholfen).
Tschuess,
Juergen Ilse (il...@usenet-verwaltung.org)
--
Das Netz ist Freude. Es ist Ekstase, die jeden einzelnen Nerv erglühen
läßt. Es ist Duft, den man fühlt. Es ist ein Bild, das man riecht.
Es ist Erfüllung - ein Geschmack, neben dem alles andere schal ist.
("Netzreiter-Preisung" aus dem Buch "Der Netzparasit" von Andreas Brandhorst)
Michael Brandtner <m.bra...@gmx.de> wrote:
> Arne Hoffmann wrote:
>> # David Kastrup wrote:
>>> Was passiert nach der Eingabe von
>>> echo $PATH
>> Nicht vielleicht doch eher ``/bin/echo $PATH''?
Nein, da der Fragesteller vermutlich eine bash vor sich hat und dort
"echo" ein shell-interner Befehl ist ...
> Könnte auch gehen. Bin überrascht, das /bin/echo existiert.
"man echo" und der Vergleich mit der Beschreibung von "echo" in "man bash"
sollte dir die (vorhandenen) Unterschiede erklaeren koennen ...
Es gibt auch unix-shells, bei denen "echo" kein shell-interner Befehl ist
(z.B. die alte original Bourne-shell). Bei der ksh ist "echo" ein alias ...
> Zumindest ist es ein Bash-Kommando.
Auch wenn es bei den meisten Linux-Distributionen so aussehen mag: nicht
jede unix-shell ist eine bash ...
Lasse Kliemann <stu3...@mail.uni-kiel.de> wrote:
> *** Sven Kolbe:
>> Ich habe nur eine Profile.local angelget und den Classpath und
>> path für den J2SDK gesetzt, seit dem gibt es das Problem.
> Du meinst, Du hast die Variable PATH in der Datei
> /etc/profile.local verändert? Wahrscheinlich rührt da der Fehler
> her.
Richtig, und *ganz allmaehlich* kommt Licht ins Dunkel ...
Auf welchen Wert wurde denn PATH in /etc/profile.local gesetzt?
Ich vermute mal, dass die Verzeichnisse, die vorher in $PATH standen
nicht im neu gesetzten Wert enthalten waren (und das ist ein Fehler:
Wenn du etwas an den bisherigen Wert von $PATH anhaengen willst, lautet
die dazu notwendige Kommando-Zeile:
PATH=${PATH}:/opt/j2sdk/bin
oder so aehnlich, je nachdem, welches Verzeichnis du in den PATH aufnehmen
willst).
>> Ich hab die datei Bereits wieder gelösch
Wenn die Datei vorher existiert hat, solltest du sie mit dem vorherigen
Inhalt wieder anlegen, nicht einfach loeschen ...
>> und die datei Profile wieder in den Urzustand zurück versetzt.
Wiederum (ich erwaehnte es glaube ich schon mal): GENAUE ANGABEN, WAS
DU GEMACHT HAST.
Wie hast du welche Dateien vorher gesichert, was hast du veraendert,
was hast du getan, um die Aenderungen wieder rueckgaengig zu machen.
Ist das wirklich so schwer, eine *genaue* Beschreibung zu liefern?
ich möchte mich im bei allen bedanken , geht alles wieder.
Lag eigetnlich nur an einem kleinen Problem, nämlich dass es mein Linux
irgendwie nicht vertragen hat wenn man zwisch path und = ein leerzeichen
einfügt.
Java hat nicht funktioniert wiel in der rc.config ein eintrage stand der die
Varaibelen für Java automatisch auf den SDK 1.3 setzt.
Nochmals Danke.
Mfg
Sven Kolbe
Das trifft nur für Bourne shells vor SVR2 ('84) zu
(heute recht selten, da sogar ohne Shell-Funktionen).