Sie sind nicht angemeldet.

[erledigt] ./install.sh im Terminal klappt nicht: "Befehl nicht gefunden"

Lieber Besucher, herzlich willkommen bei: Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

  • 1
  • 2

nochamal

User

  • »nochamal« ist der Autor dieses Themas

Beiträge: 133

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

1

12.01.2018, 16:05

./install.sh im Terminal klappt nicht: "Befehl nicht gefunden"

Wie kannn das sein?
Auf dem einen PC klappts auf diese Art einwandfrei, auf dem anderen nicht:

Quellcode

 
1
2
3
4
5

$ sudo ./install.sh
sudo: ./install.sh: Befehl nicht gefunden

$ dir
i386  Installer-fr.htm	Installer.htm  install.sh  noarch

Dieses "install.sh" sollte normalerweise eine grafisch geführte Geräte-Installation starten
Danke für jeden Hinweis oder Tip

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »nochamal« (13.01.2018, 00:35)

Horsemanchip

User

Beiträge: 1 131

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian bullseye-testing / 5.10.0-10-amd64

  • Nachricht senden

2

12.01.2018, 17:28

Vielleicht ist die Partition, auf der der Installer liegt mit "noexec" gemounted. Wenn das so ist, kannst Du auf der Partition nichts "ausführen", aus Sicherheitsgründen.

Prüfe also die Mountoptionen deiner Partition. Dann halt entweder auf exec ändern, bzw. den Installer von einer anderen Partition aus aufrufen, wo das Ausführen erlaubt ist.
Heute ist keiner da! Komm morgen wieder. :-)

nochamal

User

  • »nochamal« ist der Autor dieses Themas

Beiträge: 133

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

3

12.01.2018, 17:58

Danke
"noexec" scheint allerdings nicht der Fall zu sein - jedenfalls liefert "mount" keinen entsprechenden Hinweis und zum anderen hats eh nur eine Partition auf diesem PC.

Systempflege bezüglich alter Kernel und Pakete habe ich - nach Wiki - ebenfalls bereits durchgeführt

Unerklärlich ist mir vor allem
"Befehl nicht gefunden",
weil die anzusprechende Datei ist ja offensichtlich vorhanden

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »nochamal« (12.01.2018, 20:37)

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

4

12.01.2018, 21:20

Wenn die Datei nicht ausführbar ist, ist es eben kein Befehl. Ergo wird dieser "Befehl" auch nicht gefunden. ;)

Zeig mal

Quellcode

 
1

ls -l install.sh
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

nochamal

User

  • »nochamal« ist der Autor dieses Themas

Beiträge: 133

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

5

12.01.2018, 22:36

Zitat von »Fredl«

Wenn die Datei nicht ausführbar ist, ist es eben kein Befehl. Ergo wird dieser "Befehl" auch nicht gefunden. ;)

Klingt irgendwie logo

Zitat von »Fredl«


Zeig mal

Quellcode

 
1

ls -l install.sh


liefert

Quellcode

 
1
2

$ ls -l install.sh
-rwxrwxr-x 1 XXX XXX 84 Nov 21  2012 install.sh



Muss dazusagen dass ich die Datei nochmal dorthin kopiert habe weil ich befürchtete dass sie beschädigt sei.
Die Datei ist laut "Eigenschaften" als ausführbar markiert und im Terminal erscheint nun - neuerdings - "permission denied"

Zudem scheint sie auf eine tiefer liegende (subsub directory) liegende Datei zu referenzieren.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »nochamal« (12.01.2018, 22:42)

nochamal

User

  • »nochamal« ist der Autor dieses Themas

Beiträge: 133

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

6

13.01.2018, 00:34

Hat sich erledigt
War offenbar ein Problem mit der Rechtevergabe in irgendwelchen Unterordnern auf welche zugegriffen wird.

Danke für die Hilfestellungen!

geobart

User

  • »geobart« ist männlich

Beiträge: 104

Registrierungsdatum: 10.05.2009

Derivat: anderes Ubuntu-Derivat

Architektur: 64-Bit PC

Desktop: Cinnamon

Andere Betriebssysteme: Mint 21.1 + LMDE5 + Win11 + PCGeos

  • Nachricht senden

7

13.01.2018, 19:01

Quellcode

 
1

sudo ./install.sh
startet doch ein grafisches Installationsprogramm?
Das hätte vermutlich mit

Quellcode

 
1

gksudo./install.sh
gestartet werden müssen. Möglich, dass es dir die Rechte im Home verbogen hat.
Gibt

Quellcode

 
1

find ~ -user root -ls
nichts aus, ist es i.O.
Veni, vidi, wiki. :thumbup:

nochamal

User

  • »nochamal« ist der Autor dieses Themas

Beiträge: 133

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

8

13.01.2018, 23:18

Zitat von »geobart«

Quellcode

 
1

sudo ./install.sh
startet doch ein grafisches Installationsprogramm?

Ja
Für die Installation einens Drucker/ Scannertreiber für Samsunggeräte


Zitat von »geobart«


Das hätte vermutlich mit

Quellcode

 
1

gksudo./install.sh
gestartet werden müssen.

Möglich wärs, keine Ahnung.
Hatte diese GeräteInstallation in einem eigenen Unterordner und diesen mit der grossen chmod Keule bearbeitet.
Dann gings auch mit

Quellcode

 
1

sudo./install.sh

Vielleicht nicht schön aber zumindest wars effektiv.


Zitat von »geobart«

Möglich, dass es dir die Rechte im Home verbogen hat.
Gibt

Quellcode

 
1

find ~ -user root -ls
nichts aus, ist es i.O.

naja
die Ausgabe ist ellenlang - nur sagt mir das alles nix.
Dafür bin ich offenbar zu doof

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

9

13.01.2018, 23:39

Zitat von »nochamal«

die Ausgabe ist ellenlang
Somit das Gegenteil dessen, was geobart als "i.O." bezeichnete. Da sollte idealerweise gar keine Ausgabe kommen. Die "große chmod-Keule" bringt nur scheinbar Verbesserung. Am Ende steht irgendwann eine Neuinstallation an.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

nochamal

User

  • »nochamal« ist der Autor dieses Themas

Beiträge: 133

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

10

13.01.2018, 23:58

Könnte diese ellenlange Liste nicht auch auf anderes zurückzuführen sein?

Mir schien, dass wenn ich einen einzigen Unterordner (in Downloads) - eben jener mit dieser Installationsroutiene - ändere, nicht auch völlig andere Unterordner (zB in Dokumente) betroffen werden sollten.
Diese auftauchenden Unterorder in "Dokumente" (nur genau zwei von sehr vielen dort) sind möglicherweise aus anderen PCs einmal herüberkopiert worden.

Ich bin hierin - also bezüglich der Rechte- und Besitzvergaben im allgemeinen - offen gestanden ziemlich blank bzw blick da trotz mehrfachen Anläufen einfach nicht durch.

Der von mir per chmod bearbeitete Unterordner in Downloads scheint übrigens nicht auf

geobart

User

  • »geobart« ist männlich

Beiträge: 104

Registrierungsdatum: 10.05.2009

Derivat: anderes Ubuntu-Derivat

Architektur: 64-Bit PC

Desktop: Cinnamon

Andere Betriebssysteme: Mint 21.1 + LMDE5 + Win11 + PCGeos

  • Nachricht senden

11

14.01.2018, 00:33

Schaden tut die Keule jedenfalls nicht:

Quellcode

 
1

sudo chown -R -v $USER:$USER /home/$USER/
(so wie es da steht, nichts anpassen)
und reboot

Würde ich auf alle deiner Rechner und Installationen anwenden. :rolleyes: Dann gehören die Dateien im Home wieder dem User.

Siehe dir das https://wiki.ubuntuusers.de/sudo/ genau an und beachte es, um nicht Fredl's Pessimismus zu befriedigen. ;) :D
Veni, vidi, wiki. :thumbup:

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »geobart« (14.01.2018, 00:39)

nochamal

User

  • »nochamal« ist der Autor dieses Themas

Beiträge: 133

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

12

14.01.2018, 00:39

sagenhaft!

Und was war das eben für ein Zauber?

edit:
Muss ich das nun jedesmal machen, wenn ich einen Ordner oder eine Datei von einem PC zum anderen kopiere???
Und wie verhält es sich mit rüberkopierten Daten von Windoof ?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »nochamal« (14.01.2018, 00:45)

geobart

User

  • »geobart« ist männlich

Beiträge: 104

Registrierungsdatum: 10.05.2009

Derivat: anderes Ubuntu-Derivat

Architektur: 64-Bit PC

Desktop: Cinnamon

Andere Betriebssysteme: Mint 21.1 + LMDE5 + Win11 + PCGeos

  • Nachricht senden

13

14.01.2018, 00:52

Kannst du durchaus machen. Oder eben die Dateirechte von User auf User ändern.

Kopierst du per Stick, sollte der Fat32 haben. Auf Fat16/32 gehen die Rechte verloren und die Probleme damit auch.
Veni, vidi, wiki. :thumbup:

nochamal

User

  • »nochamal« ist der Autor dieses Themas

Beiträge: 133

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

14

14.01.2018, 00:55

bedankt !
:)


Der Beitrag ist zu kurz. Der Beitrag muss mindestens 10 Zeichen lang sein und 5 Wörter enthalten

nochamal

User

  • »nochamal« ist der Autor dieses Themas

Beiträge: 133

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

15

14.01.2018, 13:07

Ich habe das jetzt - nach der Bereinigung mittels "chown" - nochmal durchgespielt

Sowohl

Quellcode

 
1

gksudo ./install.sh

als auch

Quellcode

 
1

sudo ./install.sh


klappen genau gleich.
Der einzige - für mich erkennbare - Unterschied ist, dass "gksudo" das Passwort ausserhalb des Terminal abfragt.

Was gäbe es noch für Unterschiede?



Und noch eine Frage zu "chown" bitte:
Könnte ich dies auch auf einen einzigen Ordner begrenzen?
Dieser Geräteinstallationsordner mit dem ich die Probleme hatte wurde ja ursprünglich aus einem .tar.gz entpackt und ich kann ja - falls ich dieses weitergebe - nicht wissen, ob das auf einem andern PC ohne den "chown Zauber" klappen wird

Horsemanchip

User

Beiträge: 1 131

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian bullseye-testing / 5.10.0-10-amd64

  • Nachricht senden

16

14.01.2018, 13:08

Zitat von »nochamal«

Und was war das eben für ein Zauber?



Das war kein Zauber. Du hast lediglich chown mit Root Rechten gestartet und deine gesamten Userdaten in /home/user rekursiv wieder an deinen User übergeben.
Das musstest Du machen, weil Du durch falsche Anwendung einige Dateien an root übergeben hast und das sollte innerhalb /home nicht sein.

Überprüfe in Zukunft genau, was für sudo Kommandos Du absetzt. Analysiere den Befehl genau was er macht, BEVOR Du auf Enter drückst.
Wenn Du etwas gewissenhafter mit sudo umgehst, sollte Dir dieser Fehler nicht mehr passieren.

Merke Dir: sudo ist kein Allheilmittel! Man wendet es nur an, wenn es zwingend erforderlich ist!


Nachtrag:

Zitat

Dieser Geräteinstallationsordner mit dem ich die Probleme hatte wurde ja ursprünglich aus einem .tar.gz entpackt


Vielleicht hast Du das tar.gz mit sudo entpackt, was dann ein Anwendungsfehler deinerseits wäre. Zum entpacken braucht man nämlich keine root Rechte.

Benutze root mit Sinn und Verstand und dann brauchst Du auch den "chown-Zauber" nicht.
Heute ist keiner da! Komm morgen wieder. :-)

nochamal

User

  • »nochamal« ist der Autor dieses Themas

Beiträge: 133

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

17

14.01.2018, 14:06

Zitat von »Horsemanchip«


Zitat

Dieser Geräteinstallationsordner mit dem ich die Probleme hatte wurde ja ursprünglich aus einem .tar.gz entpackt


Vielleicht hast Du das tar.gz mit sudo entpackt, was dann ein Anwendungsfehler deinerseits wäre. Zum entpacken braucht man nämlich keine root Rechte.

Benutze root mit Sinn und Verstand und dann brauchst Du auch den "chown-Zauber" nicht.


Nein, aber trotzdem danke für den Hinweis!

Ein .tar.gz entpacke ich "ganz normal" in Nautilus.
Bin keineswegs heiss auf Befehlszeilenakrobatik
;)


Meine Frage hat auch darauf abgezielt ob die entpackten Daten dann immer gleich schon dem "Richtigen" gehören? Beim entpacken auf einem fremden PC also demjenigen dort :?:

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »nochamal« (14.01.2018, 14:12)

Horsemanchip

User

Beiträge: 1 131

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian bullseye-testing / 5.10.0-10-amd64

  • Nachricht senden

18

14.01.2018, 14:22

Die Dateien gehören immer dem, der sie anlegt. In diesem Fall wird eine Datei heruntergeladen und gehört also dem User, unter dem die Browser-Session läuft.

Würdest Du zum Beispiel deinen Firefox mit sudo starten (mach das bloß nie), dann würden die Dateien mit root Eigentümer gespeichert, weil der ganze Browser mit root Rechten läuft.
Heute ist keiner da! Komm morgen wieder. :-)

nochamal

User

  • »nochamal« ist der Autor dieses Themas

Beiträge: 133

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

19

14.01.2018, 14:37

Zitat von »Horsemanchip«

Die Dateien gehören immer dem, der sie anlegt. In diesem Fall wird eine Datei heruntergeladen und gehört also dem User, unter dem die Browser-Session läuft.


Ok, soweit so klar
mercie!

Horsemanchip

User

Beiträge: 1 131

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian bullseye-testing / 5.10.0-10-amd64

  • Nachricht senden

20

14.01.2018, 14:57

Noch was zum Thema sudo VS gksudo.

Im Grunde genommen nimmt man sudo für das Terminal und gksudo für grafische Anwendungen, die mit root Rechten laufen sollen. In den meisten Fällen kann man auch grafische Anwendungen mit sudo starten, ohne Probleme zu bekommen.

Es gibt aber Ausnahmefälle, wo es bei falscher Anwendung zu Problemen mit dem Programm kommt oder Du Dir deine Rechte verbiegst. Es ist nämlich so, dass Du bei sudo Root Rechte bekommst, aber mit der Konfiguration des Users.
Mit gksudo erhälst Du auch Rechte von Root, aber auch mit der Konfiguration von root.

Wenn Du also mit sudo eine entsprechend kritische Anwendung startest, kann es sein, dass die Anwendung fehlerhaft läuft und Du Dir bei Speichervorgängen die Rechte deines Users verbiegst. Du kannst also wie in diesem aktuellen Fall nicht
auf deine Daten zugreifen oder noch schlimmer Du übergibst die Dateien .Xauthority und .ICEauthority an root und kannst Dich dann als User nicht mehr am Anmeldebildschirm einloggen und landest in einer Login-Schleife.

Letzteres mit der Login-Schleife sieht man hier im Forum einmal die Woche. Dieser Anwendungsfehler scheint also sehr beliebt zu sein, weil viel root ja oft viel hilft! *lach*
Heute ist keiner da! Komm morgen wieder. :-)
  • 1
  • 2

Ähnliche Themen