Bash-Script funktioniert nicht?

  • hyle

    Ich möchte wirklich nicht als bockig rüberkommen - aber wenn ich mir den von Dir verlinkten Wiki-Eintrag ansehe und nach unten scrolle, dann lese ist unter /usr das hier:

    /usr/bin : Anwenderprogramme; Hier liegen die Desktopumgebungen und die dazu gehörigen Programme, aber auch im Nachhinein über die Paketverwaltung installierte Programme, wie Audacity.

    Weiter unten steht dann:

    /usr/local : Das Verzeichnis /usr/local enthält noch einmal die gleiche Verzeichnisstruktur wie /usr und ist für Programme gedacht, die man an der Paketverwaltung vorbei installieren möchte, z.B. selbst kompilierte Programme. Bei einem neu installierten Ubuntu enthält es höchstens leere Ordner.

    Also: Wie soll man da auf die Idee kommen, dass man dorthin seine Shell-Skripte ablegt, wenn immer nur von "Programmen" die Rede ist? Genau deswegen habe ich permanent Probleme mit den Beschreibungen rund um Linux. Das ergibt alles kein eindeutiges Bild für mich als Anfänger und ist dementsprechend schwer in den Kopf zu bekommen. Für mich ist ein Programm etwas komplett anderes als ein Skript. Und ich möchte jetzt nicht überprüfen, was sonst noch für mich widersprüchlich ist auf dieser einen Seite.

    ist nicht böse gemeint. Ich wäre ja froh, wenn es irgendwo eine Seite gäbe, die mir das wirklich verständlich beibringen würde. Gefunden habe ich bislang noch keine. Die meisten sind in dieser Qualität.

    Am Rande noch eine Bitte: Ich bin schon länger auf der Suche nach einem verständlichen Tutorial, um zu lernen, wie man Shell Skripte erstellt. Kann mir da irgendwer entsprechende Seiten empfehlen?

  • Wie soll man da auf die Idee kommen, dass man dorthin seine Shell-Skripte ablegt, wenn immer nur von "Programmen" die Rede ist?

    Ein Skript ist auch nur ein Programm, das zwar nicht direkt in Maschinensprache kompiliert/übersetzt wurde, aber einen Interpreter (hier Bash) verwendet, der den Inhalt des Skripts übersetzt.

    ist nicht böse gemeint.

    Alles gut! ;)

    Ich bin schon länger auf der Suche nach einem verständlichen Tutorial, um zu lernen, wie man Shell Skripte erstellt. Kann mir da irgendwer entsprechende Seiten empfehlen?

    Gerne! https://wiki.ubuntuusers.de/Shell/Bash-Skr…_Anf%C3%A4nger/

  • Ich wäre ja froh, wenn es irgendwo eine Seite gäbe, die mir das wirklich verständlich beibringen würde. Gefunden habe ich bislang noch keine.

    Die "Filesystem Hierachy" ist lediglich eine Empfehlung für Multiuser Systeme und hat sich innerhalb der letzten 50 Jahre durch Ergänzungen auch verändert. Mit < man hier > kannst Du Dir die Man-Page auf Deinem System ansehen.

    Mit "linux bash" in der Suchmaschineneingabe bekommst Du haufenweise Tutorials, vom Noobs bis zum Expert, u.A. auch https://tldp.org/LDP/Bash-Begin…ners-Guide.html

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Eine Frage hätte ich noch - weil das mehrmals erwähnt wurde. Könnt Ihr ein plausibles Beispiel nennen, wo das mit dem Erweiteren des PATH zum Problem werden könnte. Das Beispiel von KKoPi überzeugt mich nicht, denn einerseits werde ich ganz sicher meine Skripte "ls" nennen - und fremde Personen haben keinen Zugriff auf meine Rechner.

    RTFM

    Ich vergesse es leider immer wieder, dass meine Amtssprache deutsch ist - mit dem Englischen stehe ich oft genug auf Kriegsfuß. Und noch mehr, wenn sich im Text jede Menge Fachbegriffe tummeln, die meist nach einer Übersetzung den Text komplett unverständlich machen.

    Diese Seite hat mir gestern die Suchmaschine meines geringsten Misstrauens ausgespuckt: http://ernstlx.com/linux90script.html - da gibt es auch noch einen zweiten Teil. Schien mir mal vernünftig zu sein.

    hyle

    Danke für den Link - den werde ich auch durcharbeiten - ist jedenfalls als Nachschlagewerk gut nutzbar, was ich so beim überfliegen gesehen habe.

  • Könnt Ihr ein plausibles Beispiel nennen, wo das mit dem Erweiteren des PATH zum Problem werden könnte.

    Z.B. bei einem Cronjob und das in verschiedenen Crontabs. Eimal dürfte das die User-Crontab (crontab -e) betreffen und ziemlich sicher auch die systemweite Crontab (sudo nano /etc/crontab).

    Davon abgesehen ist sind oben genannten PATH-Einträge nur temporär und nur für diesen User und/oder auch nur in der Bash.

  • Irgendwie habe ich das Gefühl, dass hier in der Diskussion das systemweite /usr/local/bin und das benutzerspezifische $HOME/bin bunt vermischt werden, was ralfi1988 vermutlich zusätzlich irritiert hat...

    Also ergänzend zu #17 von __blackjack__ vielleicht:

    Benutzerspezifische Skripts/Programme - wenn sie nicht regelrecht installiert werden (müssen) - in das Verzeichnis $HOME/bin stecken.

    Falls das Verzeichnis noch nicht existiert, einfach anlegen und nach einem neuen Login (oder dem Starten einer neuen Shell, oder, oder...) ist das Verzeichnis dann automatisch im PATH enthalten.

    Einmal editiert, zuletzt von simonz (20. April 2023 um 22:26) aus folgendem Grund: Link zu Beitrag #17 ergänzt

  • Die "Filesystem Hierachy" ist lediglich eine Empfehlung für Multiuser Systeme und hat sich innerhalb der letzten 50 Jahre durch Ergänzungen auch verändert. Mit < man hier > kannst Du Dir die Man-Page auf Deinem System ansehen.

    Ich vergesse es leider immer wieder, dass meine Amtssprache deutsch ist - mit dem Englischen stehe ich oft genug auf Kriegsfuß. Und noch mehr, wenn sich im Text jede Menge Fachbegriffe tummeln, die meist nach einer Übersetzung den Text komplett unverständlich machen.

    Die Manpages gibt es auch auf Deutsch:

    Falls es bei dir nicht auf Deutsch ist, dann stimmen entweder die Spracheinstellungen nicht oder dir fehlt das Paket manpages-de.

    Code
    sudo apt-get install manpages-de


    Irgendwie habe ich das Gefühl, dass hier in der Diskussion das systemweite /usr/local/bin und das benutzerspezifische $HOME/bin bunt vermischt werden, was ralfi1988 vermutlich zusätzlich irritiert hat...

    • /usr/bin: Programme des Betriebssystems, systemweit verfügbar. Sollte nicht verändert werden. Der Paketmanager kopiert die Dateien dort hin, wenn man z.B. ein Programm über den Paketmanager installiert.
    • /usr/local/bin: Zusätzlich installierte Programme, die z.B. nicht über den Paketmanager ausgeliefert werden (manuellle systemweite Installation)
    • /home/BENUTZER/.local: Entspricht dem vorherigen Punkt, mit der Ausnahme, dass es nicht systemweit verfügbar ist und nur den einen Benutzer betrifft. Es erfordert auch keine root-Rechte.

    Verständlicher erklärt ist es in ...

    Wenn Du mehrere Benutzer hast und für jeden Nutzer das Programm/Script zur Verfügung stellen willst, dann nach /usr/local/bin kopieren.

    Falls Du nur einen Nutzer hast und ohnehin mit dem Benutzer immer angemeldet bist, brauchst Du die Systemweite Installation nicht und kannst es für den Benutzer einrichten. Also in /home/BENUTZER/.local/bin/

    Übrigens ist das unter Windows ähnlich. Dort kann man auch Programme ohne Administratorrechte installieren.

    Dateien und Verzeichnisse, die mit einem Punkt anfangen, werden standardmäßig durch den Befehl ls nicht aufgelistet. Sie gelten in der Unix-Welt als versteckte Dateien. Das ist eher eine Konvention, an der man sich hält. Webserver zeigen z.B. bei der Auflistung eines Verzeichnisses versteckte Dateien nicht an.

  • /home/BENUTZER/.local: Entspricht dem vorherigen Punkt, mit der Ausnahme, dass es nicht systemweit verfügbar ist und nur den einen Benutzer betrifft. Es erfordert auch keine root-Rechte.

    1. $HOME/.local/bin ist die mit systemd dazu gekommene Variante
    2. $HOME/bin ist die historisch gewachsene

    Beide können verwendet werden (siehe $HOME/.profile).

    "2." dürfte für ralfi1988 einfacher sein, da er so das Verzeichnis mit seinen Skripten immer sieht.

  • Ja, das kann sein. Bei Buster gibt es das dann jedenfalls.

  • In meiner .profile Datei wird nur $HOME/bin für PATH hinzugefügt, wenn /bin vorhanden ist. Kann es sein, dass $HOME/.local/bin erst nach Stretch dazugekommen ist?

    ~/.local/ musste ich bisher immer anlegen und auch zum Pfad hinzufügen. Das Verzeichnis ~/bin ist mir bisher bei keiner Distribution, die ich verwendet habe, aufgefallen.

    Dateien und Verzeichnisse, die beim Erstellen eines neuen Benutzers kopiert werden, befinden sich im Verzeichnis /etc/skel.

    Code
    deadeye@rpi0w2:~ $ ls -la /etc/skel/
    total 24
    drwxr-xr-x   2 root root 4096 Aug 15  2022 .
    drwxr-xr-x 102 root root 4096 Apr 15 21:50 ..
    -rw-r--r--   1 root root  220 Aug  4  2021 .bash_logout
    -rw-r--r--   1 root root 3523 Apr  4  2022 .bashrc
    -rw-r--r--   1 root root 1670 Jul 10  2021 .mkshrc
    -rw-r--r--   1 root root  807 Aug  4  2021 .profile

    Kein bin Verzeichnis. Wenn also ein Verzeichnis existiert, hat irgendeine Anwendung das Verzeichnis erstellt.

  • Wenn also ein Verzeichnis existiert, hat irgendeine Anwendung das Verzeichnis erstellt.

    Nein, das Verzeichnis bin muss man auch selber anlegen, ABER in der Datei ~/.profile ist das schon eingetragen, falls das vom User erstellt werden sollte. Siehe den Inhalt der Datei im Beitrag #32!

  • Wenn ralfi1988 unbedingt etwas anklicken möchte, wo ShellSkripte drauf steht, dann kann er das Verzeichnis ~/bin erzeugen und auf dem Desktop eine shellskripte.desktop Datei mit folgendem Inhalt

    Code: shellskripte.desktop
    [Desktop Entry]
     Name=ShellSkripte
     Comment=ShellSkripte
     Exec=pcmanfm bin
     Type=Application
     Terminal=false
     Icon=/usr/share/icons/hicolor/128x128/emblems/emblem-debian.png

    erstellen. Danach ggf. kurz vom Desktop ab- und wieder anmelden.

    Färtsch! ;)

    //Edit

    Oder / und einen Softlink

    Code
    ln -sr /home/pi/bin /home/pi/ShellSkripte

    erstellen.

    Aber nu ist wirklich färtsch!

  • Nein, das Verzeichnis bin muss man auch selber anlegen, ABER in der Datei ~/.profile ist das schon eingetragen, falls das vom User erstellt werden sollte. Siehe den Inhalt der Datei im Beitrag #32!

    Gelesen, verstanden und dann darauf hingewiesen, woher die Dateien/Verzeichnisse kommen oder wusstest du das die Dateien von /etc/skel kommen?

  • wusstest du das die Dateien von /etc/skel kommen?

    Nö, wusste ich nicht, ist aber auch egal, denn darauf hatte ich nicht geantwortet, sondern darauf, dass nicht irgendeine Anwendung das Verzeichnis erstellt hat, sondern wenn, das der User erledigen muss.

    Btw. cat /etc/skel/.profile bringt die selbe ausgabe wie oben.

  • Btw. cat /etc/skel/.profile bringt die selbe ausgabe wie oben.


    Das ist schon sehr eigenartig, dass unveränderte Kopien identisch sind.

  • Schon klar, nur war die eine oben von einem System mit Buster und die andere von Bullseye.

    Spoiler anzeigen

    Mit Python + nbdkit + nbd-client habe ich mir mal aus den heruntergeladenen Images die Datei /etc/skel/.profile geholt und nach Downloads/ geschrieben. Hier die md5sum:

    Code
    f4e81ade7d6f9fb342541152d08e7a97  2023-02-21-raspios-bullseye-arm64.img.xz-profile.skel
    f4e81ade7d6f9fb342541152d08e7a97  2023-02-21-raspios-bullseye-arm64-lite.img.xz-profile.skel
    f4e81ade7d6f9fb342541152d08e7a97  2023-02-21-raspios-bullseye-armhf-full.img.xz-profile.skel
    f4e81ade7d6f9fb342541152d08e7a97  2023-02-21-raspios-bullseye-armhf.img.xz-profile.skel
    f4e81ade7d6f9fb342541152d08e7a97  2023-02-21-raspios-bullseye-armhf-lite.img.xz-profile.skel
    f4e81ade7d6f9fb342541152d08e7a97  2023-02-21-raspios-buster-armhf.img.xz-profile.skel
    f4e81ade7d6f9fb342541152d08e7a97  2023-02-21-raspios-buster-armhf-lite.img.xz-profile.skel

    Zur Kontrolle habe ich mal meine .profile beim RPi0W2 gehasht:

    Code
    deadeye@rpi0w2:~ $ md5sum .profile 
    f4e81ade7d6f9fb342541152d08e7a97  .profile
    • "$HOME/.bashrc" ausführen
    • PATH="$HOME/bin:$PATH", wenn vorhanden
    • PATH="$HOME/.local/bin:$PATH", wenn vorhanden
    Spoiler anzeigen

    Meine PATH Variable. Bis auf .pyenv ist nichts verändert worden. Spielt auch keine Rolle, welche Installation, da wir ja jetzt gelernt haben, dass Bullseye und Buster identisch sind. Bei Arch-Linux auf dem Desktop habe ich gar keine /etc/skel/.profile.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!