Programm ausführen in Shell ( ACHTUNG: Anfängerfrage )



  • Ähhh, sorry Bill Gates, aber je mehr ich über Linux erfahre desto mehr gefällt es mir, ausserdem sieht der Pinguin viel süßer aus 🙂

    THX für die Erklärung!



  • Winuser schrieb:

    Ähhh, sorry Bill Gates, aber je mehr ich über Linux erfahre desto mehr gefällt es mir, ausserdem sieht der Pinguin viel süßer aus 🙂

    THX für die Erklärung!

    😃

    btw. sollte es interessant für dich sein, wenn du dich mal ein wenig um die Verzeichniss Strukturen von Unices einliest.

    Weil du Ausführbaredateien idr. in ein bin Verzeichniss legst (/usr/local/bin idr. aber je nach Anwendung/Situation auch /bin oder /usr/bin) etc. damit sparst du dir das ./ und die Anwendung ist von überall aus verfügbar



  • Also, das mit dem "./" kann man sich sparen, wenn man (als "normaler" User) das aktuelle Verzeichnis (also ".") mit in den Suchpfad aufnimmt:
    In ".bashrc"
    PATH=$PATH:.

    Übrigens: Für den Einstieg in die Linux-Programmierung kann ich dir mein Buch "C und Linux" empfehlen! 😃

    @TriPhoenix: Für den Benutzer root hast du natürlich Recht. Dieser sollte (auf einem Multi-User-System) das aktuelle Verzeichnis nicht im Suchpfad haben. Auf einem "Stand-alone-PC" spielt's keine Rolle.



  • Wenn der PC wirklich Stand Alone, d.h. ohne Verbindung ins's Internet ist haste Recht. Unschön ist es trotzdem, sollte man sich möglichst erst gar nicht angewöhnen.



  • Stoerte schrieb:

    Wenn der PC wirklich Stand Alone, d.h. ohne Verbindung ins's Internet ist haste Recht. Unschön ist es trotzdem, sollte man sich möglichst erst gar nicht angewöhnen.

    Verbindung zum Internet ist nicht so sehr das ausschlaggebende Kriterium, "Multiuser" ist das Stichwort!



  • Martin G schrieb:

    @TriPhoenix: Für den Benutzer root hast du natürlich Recht. Dieser sollte (auf einem Multi-User-System) das aktuelle Verzeichnis nicht im Suchpfad haben. Auf einem "Stand-alone-PC" spielt's keine Rolle.

    Nicht nur für root. In Multiuserumgebungen (wie z.B. Uni-Systemen) können andere User genauso bösartig sein und es auf diene Daten abgesehen haben. Root wäre natürlich absolut fatal.

    nman schrieb:

    Stoerte schrieb:

    Wenn der PC wirklich Stand Alone, d.h. ohne Verbindung ins's Internet ist haste Recht. Unschön ist es trotzdem, sollte man sich möglichst erst gar nicht angewöhnen.

    Verbindung zum Internet ist nicht so sehr das ausschlaggebende Kriterium, "Multiuser" ist das Stichwort!

    Mies konfiguriert hast du schneller multiuser als du denkst 😉



  • Stoerte schrieb:

    Mies konfiguriert hast du schneller multiuser als du denkst 😉

    *bg* Bei mir ist IMO alles _halbwegs_ abgesichert (die INPUT-Chain meiner iptables ist wirklich überschaubar 😉 und außer sshd - das aber nur für DMZ-Rechner - bietet mein Rechner keine Dienste an), aber Multiuser habe ich auch so, auf diesem Rechner gibt es circa 10-15 User-Accounts für Familie und Freunde...
    Ergo: Ich habe . auch nie im PATH, wenn ein Benutzer meines Systems das haben möchte dann kann er/ sie das selbstverständlich per .profile etc. regeln.



  • Irgendwann haste sicher auch mal 'nen Webserver, FTPd, Fielsharingtool laufen, oder der IRC Client o.ä. hat einen lustigen Bug usw..
    Wenn man das macht sollte man dann möglichst "su -" benutzen, damit man diesen Path mit working directory drin nicht übernimmt.



  • wobei man beachten sollte, wenn das . am Ende von $PATH steht, wird ja vorher eh das /bin /usr/bin /usr/local/bin etc. Verzeichniss durchsucht, dh. nur wenn man einen Tippfehler macht zufällig der böse Bub genau wusste, was dass man den Tippfehler macht, dann kann es einem passieren, dass man irgend ein Programm ausführt, was zB. dem Cracker Root Rechte besorgt oder so.

    (btw. hab trotzdem kein . im PATH :))



  • Stoerte schrieb:

    Irgendwann haste sicher auch mal 'nen Webserver, FTPd, Fielsharingtool laufen, oder der IRC Client o.ä. hat einen lustigen Bug usw..

    Ich sag ja auch nicht dass ich völlig abgesichert bin, nur so sicher wie es für ein privates Desktopsystem auch tatsächlich Sinn macht, das Verhältnis von Aufwand zu Nutzen ist halt ziemlich in Ordnung.
    Webserver und FTPd hab ich ab und zu LAN-intern laufen, das stimmt und Filesharingprogramme verwende ich nicht weil ich bis jetzt zu faul war welche zu suchen die auch wirklich halbwegs gut funktionieren... 🙂

    Stoerte schrieb:

    Wenn man das macht sollte man dann möglichst "su -" benutzen, damit man diesen Path mit working directory drin nicht übernimmt.

    Ich weiß ehrlich gesagt immer noch nicht so genau was der Unterschied zwischen su und "su -" ist, die Manpage ist dazu auch eher vage:

    The optional argument - may be used to provide an environment similiar to what the user would expect had the user logged in directly.



  • nman schrieb:

    Ich weiß ehrlich gesagt immer noch nicht so genau was der Unterschied zwischen su und "su -" ist, die Manpage ist dazu auch eher vage:

    The optional argument - may be used to provide an environment similiar to what the user would expect had the user logged in directly.

    Die meisten Enviroment Variablen sind mit dem "-" gelöscht, wie als würde er sich komplett neu einloggen, andernfalls werden sie von dem User, der den User wechselt übernommen.

    ~$ export FOO=batz
    ~$ su
    Password:
    # echo FOObatz#exitexit FOO batz \# exit exit ~ su -
    Password:
    # echo $FOO

    Das ist z.B. auch der Grund warum du nach "su -" oder "su - user" bei X Programmen immer eine Error Meldung bekommst bzw. DISPLAY und XAUTHORITY neu exportieren musst.
    Evt verständlicher, beim GNU su wird das in der info Page stehen.

    -l      Simulate a full login.  The environment is discarded except for
                 HOME, SHELL, PATH, TERM, and USER.  HOME and SHELL are modified
                 as above.  USER is set to the target login.  PATH is set to
                 ``/bin:/usr/bin''.  TERM is imported from your current environ-
                 ment.  Environment variables may be set or overridden from the
                 login class capabilities database according to the class of the
                 target login.  The invoked shell is the target login's, and su
                 will change directory to the target login's home directory.
                 Resource limits and session priority are modified to that for the
                 target account's login class.
    
         -       (no letter) The same as -l.
    


  • Danke sehr, das war weit hilfreicher als die doch etwas schwammige manpage, wenn dort auch einfach sowas gestanden wäre wie "Make shell a login shell" hätte mir das bereits weitergeholfen! 🙂 (Ich muss mir endlich angewöhnen bei GNU-Sachen Infopages statt manpages zu konsultieren! *g*)

    DISPLAY muss ich hier übrigens nach jedem su neu setzen, auch ganz ohne '-'. (Ich verwende das Standard-su von Gentoo Linux, aus dem meta-ebuild sys-apps/shadow, das ist aber glaube ich ein normales GNU su mit wheel-patch.)


Anmelden zum Antworten