"command not found" nach System upgrade

[empty_string]

Hallo,
nach einem Systemupgrade bekomme ich plötzlich bei mehreren Skripten Fehlermeldungen wenn ich diese starten möchte. Viele der verwendeten Befehle werden nicht verstanden, z.B.:

Code: Alles auswählen

 uname: command not found
 rm: command not found

Die Skripte sind korrekt aber lassen sich jetzt nicht mehr starten.
Ich vermute das es mit dem upgrade zusammenhängt. Kennt das jemand oder hat eine Lösung parat?

mfg,
empty

[Spasswolf]

Lassen sich diese Programme mit vollständiger Pfadangabe starten?

Code: Alles auswählen

/bin/uname
/bin/rm

[nil]

Beide Programme gehören zum Paket coreutils, vielleicht mal neu installieren:

Code: Alles auswählen

apt-get install coreutils

PS.: zu coreutils gehören jedoch insgesamt 98 Programme, wenn /usr/bin/wc (übrigens auch von coreutils) sich nicht verzählt hat.

[empty_string]

Danke für die Hilfe,
also per Pfadangabe lassen sich die Programme ohne weiteres benutzen und coreutils neuinstallieren hat leider auch nichts genutzt.

Ich habe festgestellt, dass es nur bei manchen Startskripten zu Schwierigkeiten kommt. Bei einem Einzeiler mit "rm test" kommt keine Fehlermeldung. Bei den größeren Sachen, die wie gesagt alle vor dem upgrad noch liefen, kommen auch andere Meldungen wie:

Code: Alles auswählen

 line 312: [: 1Usage:: integer expression expected
line 231: [: too many arguments
line 232: [: -ge: unary operator expected 

Habe es auch schon ein altes Skript gelöscht und eine unveränderte Version direkt aus dem Packet genommen, also an einen Skriptfehler glaub ich nicht.

Vielleicht ist eines der neuen Packet kaputt, wenn ich die upgrade Liste durchsehe fällt mir spontan "sed" ins Auge. Sonst hätt ich keine Idee mehr :-/.

[sed]
Description: The GNU sed stream editor
sed reads the specified files or the standard input if no
files are specified, makes editing changes according to a
list of commands, and writes the results to the standard
output.

[KBDCALLS]

Poste mal

Code: Alles auswählen

echo $PATH

[empty_string]

Als root:

Code: Alles auswählen

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

[debdog]

Stichwort
#!/bin/sh

Wenn Du 'sh' verwendest, auf was zeigt /bin/sh?

[armin]

Hast du eventuell dash als Standard-Shell eingerichtet und versuchst damit jetzt Sktipte mit bashspezifischen Erweiterungen auszuführen?

[empty_string]

Danke euch, also habe nochmal rumprobiert aber bin zu keiner Lösung gekommen. An der standard shell habe ich nichts geändert und sh sieht so aus:

Code: Alles auswählen

0 lrwxrwxrwx 1 root root 4 2006-12-17 17:50 /bin/sh -> bash

.

Ich hänge mal die liste des upgrades an: http://nopaste.debianforum.de/5852 vielleicht hat ja noch jemand eine Idee.

[KBDCALLS]

Wenn der Pfad stimmt, kanns nicht an den Upgrades liegen.


Was ergibt

Code: Alles auswählen

type rm

und

Code: Alles auswählen

dpkg -l coreutils

[debdog]

Poste mal

Code: Alles auswählen

echo $PATH

und was gibt das aus wenn man es in eines der Scripte einbaut?

Edit: Ok, doof, dann kommt wahrscheinlich echo: command not found

Nochmal Edit: nur um sicher zu gehen, sind in den betroffenen Scripten die Pfade mit angegeben?
z.B. 'uname' funktioniert von der Konsole aus auch ohne Pfadangabe. Im Script funtioniert es ohne Pfad nicht. Und mit Pfad?

[KBDCALLS]

Wie kommst du auf Scripte @debdog ?

Code: Alles auswählen

uname: command not found
rm: command not found 

[empty_string]

Ah ihr habt mich da auf ne Idee gebracht. Komischerweise scheint es daran zu liegen, dass nicht der vollständige Pfad im skript steht. Aber ich kann jetzt nicht alle Pfadangaben vervollständigen, also die Ursache wieso es plötzlich nicht geht, weiß ich leider noch nicht.
Im skript wird der Pfad auch exportiert:

Code: Alles auswählen

export LC_ALL=C
export PATH=$PATH'/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin'

Aber wieso wird dann der Pfad nicht gefunden?

Hier nochmal kurz die Angaben:

Code: Alles auswählen

type rm
rm is hashed (/bin/rm)

dpkg -l coreutils
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Säubern/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/Fehlgeschl. Konf./Halb install.
|/ Fehler?=(kein)/Halten/R=Neuinst notw/X=beide (Status, Fehler: GROSS=schlecht)
||/ Name                    Version                 Beschreibung
+++-=======================-=======================-==============================================================
hi  coreutils               5.97-5.3                The GNU core utilities

edit: Hm ich glaub ich bin dran. Irgendwie wurde durch die export Anweisung im script (die ja eigentlich korrekt ist) die PATH Variable verändert. Und bei jedem manuellen exportieren der Variable werden die Pfade nicht überschrieben sondern einfach hinten angehängt. So das letztendlich nicht nur die Befehle im skript nicht funktionieren, sondern auch in der Konsole nicht. Keine Ahnung wie das alles Zusammenhängt, aber wenn ich die export Anweisungen weglasse funktionierts.
Werde noch ein bisschen testen inwieweit sich das reproduzieren lässt.

[KBDCALLS]

Hier nochmal kurz die Angaben:

Code: Alles auswählen

type rm
rm is hashed (/bin/rm)

dpkg -l coreutils
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Säubern/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/Fehlgeschl. Konf./Halb install.
|/ Fehler?=(kein)/Halten/R=Neuinst notw/X=beide (Status, Fehler: GROSS=schlecht)
||/ Name                    Version                 Beschreibung
+++-=======================-=======================-==============================================================
hi  coreutils               5.97-5.3                The GNU core utilities

Irgendwas stimmt mit dem Paket nicht , ist nicht volständig installiert. Installier das mal neu.

[debdog]

Wie kommst du auf Scripte @debdog ?

Ich habe den Eröffnungspost so verstanden, daß die Befehle nur in den Scripten nicht gehen. Liege ich da falsch?

Wenn ich da richtig liege, war mein Verdacht, daß die/einige Umgebungsvariablen nicht an die Scripte übergeben werden. Ich hatte mal einen ähnlichen Fehler, war ziemlich in meiner Anfangszeit mit Linux. Ich kann mich aber beim besten Willen nicht mehr an die Lösung erinnern (wahrscheinlich habe ich neu installiert )

[KBDCALLS]

rm und uname sind aber keine Scripte sondern Binarys.[/color] Wenn das innerhalb von Scripten passiert. könnte es an der She-Bang Zeile liegen.

Die erste Zeile in einem Script (egal welches) lautet sieht so aus. Natürlich jeweils mit anderem Interpreter. Je nach Sprache.

Code: Alles auswählen

#! /bin/ksh

Ist jetzt die KSH nicht installiert, kommst zum Fehler Command not found.

[debdog]

Ähh... sorry, da hab' ich mich wohl nicht verständlich ausgedrückt...

Ich habe den Eröffnungspost so verstanden, daß die Befehle (ausführbare Binärdateien) nicht aus bestimmten/verschiedenen Scripten startbar sind, von der Konsole aus aber keine Mucken machen.

Da ich mir aber selbst nicht so sicher damit war, hab ich extra nochmal nachgefragt:

nur um sicher zu gehen, sind in den betroffenen Scripten die Pfade mit angegeben? z.B. 'uname' funktioniert von der Konsole aus auch ohne Pfadangabe. Im Script funtioniert es ohne Pfad nicht. Und mit Pfad?

Könnte uns empty_string bitte aufklären.

Griassla
debdog

[empty_string]

Hiho,
ja sorry hab mich nicht nochmal gemeldet.
Also debdog hat schon recht. Ursprünglich war es so, dass es nur in skripten nicht ging. Allerdings ist es mittlerweile so, dass wenn ich den PATH neu exportiere, die Befehle auch in der Konsole zum Teil nicht mehr gehen, erst nach reboot wieder.
In dem einen skript war gar keine She Bang Zeile, aber es ging ja trotzdem die ganze Zeit (firewall skript, also das wichtigste). Dann habe ich

Code: Alles auswählen

export LC_ALL=C
export PATH=$PATH'/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin' 

aus diesem entfernt und alles auf de_DE@euro umgestellt. Dannach ging wieder alles, außer wenn ich jetzt mal manuell Pfade exportiere.
(Wie gesagt, ich habe nichts am skript oder system geändert, einfach nur nach 2 Wochen Abwesenheit ein upgrade gemacht.)

Und das coreutils Packet sieht auch nach --reinstall noch genauso aus . Es läuft zwar im Moment alles, aber halt auf wackeligen Beinen.

Wünsche schöne Pfingsten .

[KBDCALLS]

H

Und das coreutils Packet sieht auch nach --reinstall noch genauso aus . Es läuft zwar im Moment alles, aber halt auf wackeligen Beinen.

Wünsche schöne Pfingsten .

Warum das so ist, dem würd ich dann doch mal auf den Grund gehen. Auch mal mal auf Fehlermeldungen bei der Installation von Paketen. Eventuell auch mal die Ganze Liste posten Aber bitte hier