{solved} Kurz & knackig: PATH, symbolischer Link oder Alias

[PericoloGiallo]

Liebe Freunde,

bei der Nachinstallation von Programmen kommt es manchmal dazu, dass der Programmaufruf aus der Konsole nicht auf Anhieb gelingt.

Kurz-knackige Frage: wie löst ihr das Problem am liebsten: mittels Alias, Erweiterung von PATH oder symbolischer Links nach /bin o.ä.? Gibt es eine empfohlene Vorgagsweise?

Thx, PG

[Meillo]

Was meinst du mit ``Nachinstallation'' und was meinst du mit ``nicht auf Anhieb''?


Ins Blaue hinein geantwortet: Ich installiere von Hand meist nach /usr/local (/usr/local/bin ist in PATH) oder, falls es nur Einzelscripte sind, kopiere ich die oft nach ~/bin (was ebenfalls in PATH ist).

... jetzt musst du halt noch rausfinden, ob meine Antwort zu deiner Frage passt ... oder meine obigen Fragen beantworten, dann ich ich es dir sagen.

[chmod007]

Wenns einzelne Programme sind per Link, Path nur wenns sich richtig lohnt, also mehr als 20 executable in nem Verzeichnis rumlungern die ich ständig brauche

@meilo: ich denke mal es handelt sich um Programme, die ihre executable nicht in einem der Standardpfade abkippen

[PericoloGiallo]

Danke für die schnellen Antworten.
toilet und figlet z. B. werden per apt installiert und weisen diese Eigenheit auf. Ich hoffe, die Antwort passt zu deiner Frage

[Cae]

toilet und figlet z. B. werden per apt installiert und weisen diese Eigenheit auf.

Sicher?

Code: Alles auswählen

toilet: /usr/bin/figlet-toilet
toilet: /usr/bin/toilet
figlet: /usr/bin/chkfont
figlet: /usr/bin/figlet-figlet
figlet: /usr/bin/figlist
figlet: /usr/bin/showfigfonts

(aus apt-file show)

Gruss Cae

[PericoloGiallo]

Sorry, du hast völlig recht. Bei mir liegen figlet und toilet auch unter /usr/bin. Ich habe in letzter Zeit so viel ausprobiert... Die Scherzprogrämmchen sl und cowsay meine ich z. B., die auf meinem Raspi unter /usr/games liegen. Ausgangsfrage: a, l oder p?

Danke und gute Nacht,
PG

[Meillo]

Die Scherzprogrämmchen sl und cowsay meine ich z. B., die auf meinem Raspi unter /usr/games liegen. Ausgangsfrage: a, l oder p?

Fuer mich ein Fall von PATH.

Aliases mag ich nicht, sind mir zu obscur.

Wo wuerdest du einen Link denn hinsetzen? Nach ~/bin (okay, das ginge) oder /usr/local/bin (passt inhaltlich nicht) oder /usr/bin bzw. gar /bin (passt inhaltlich ueberhaupt nicht)?

@meilo: ich denke mal es handelt sich um Programme, die ihre executable nicht in einem der Standardpfade abkippen

Es war nicht klar, was in der Frage gemeint war. Ich bin dann von selbst-kompilierten bzw. selbstentwickelten Programmen ausgegangen. Was du hier nun wiederum als Standardpfad ansiehst, ist mir nicht klar. Fuer selbstkompilierte Programme ist fuer mich der Standardpfad /usr/local/bin. Dorthin installiere ich sie normalerweise. (/usr/bin gehoert dem System, also APT, da wird nicht rumgefummelt.) /usr/local/bin ist bei mir natuerlich in PATH.

Wenn es nur um kleine Scripte geht, dann oder Einzelprogramme ohne Manpage und Co., dann lege ich die oft nach ~/bin. Auf den meisten meiner Systeme bin ich sowieso Alleinnutzer, also macht's keinen Unterschied fuer das Programm, nur fuer evtl. vorhandene Manpages.

Ich gebe mir ueblicherweise Schreibrechte fuer /usr/local (Mitglied der Gruppe `staff'), das macht alles sehr viel angenehmer.

[uname]

Bei einem normalen System ist /usr/games/bin und somit sl im Pfad. Wenn dann muss man den Suchpfad um /usr/games/bin erweitern. Keinesfalls irgendwas in /usr/bin, /bin, /usr/sbin oder /sbin eintragen. Die Verzeichnisse gehören einzig und alleine der Paketverwaltung. Natürlich kann man auch dort rumfummeln. Aber das zeigt eher die Unkenntnis wie die Paketverwaltung funktioniert. Sind ja hier nicht bei Windows wo einfach alles zu einem Programm immer in einen Ordner reingemüllt wird und die Benutzer dann anfangen zu fummeln. Bei Linux gibt es feste Strukturen, die man einhalten sollte. Und Linux ist eigentlich ein System wo man sehr strukturiert arbeiten kann. Komisch, dass oft das Gegenteil behauptet wird.

[chmod007]

Mit Standardpfaden meinte ich die, die normalerweise im PATH drin sind, vornehmlich /bin /usr/bin und /usr/local/bin

Allerdings hab ich auch einige Programme, die unter /usr/local oder /opt ihre eigene Hierarchie aufmachen. Die linke ich dann meist in einen der anderen Pfade.

Genauso mit Scripten, die ich als root nutze oder als cronjob. Die lege ich in ein Verzeichnis unter /root ab ,linke sie aber nach /usr/local/sbin. Macht für mich die Pflege einfacher.

Dann hab ich auf manchen Maschinen eine ganze Batterie von executables fernab der bin- Verzeichnisse. Bestes Beispiel aus meinem Tagesgeschäft sind da die Checkplugins von Nagios/Icinga. Alles unter/usr/lib...
Da ich die oft auf der Konsole testen muss, wars da am einfachsten, den PATH zu erweitern.

Aliase dagegen nehm ich nur, um ganze Commandlines abzukürzen und meine Faulheit zu unterstützen

[Meillo]

Allerdings hab ich auch einige Programme, die unter /usr/local oder /opt ihre eigene Hierarchie aufmachen.

Stimmt, sowas hab ich auch: mmh. Dort fuege ich /usr/local/mmh/bin dem Pfad hinzu. Dafuer ist PATH schliesslich da ... und sonst muesste ich auch 50 Tools verlinken.

Genauso mit Scripten, die ich als root nutze oder als cronjob. Die lege ich in ein Verzeichnis unter /root ab ,linke sie aber nach /usr/local/sbin. Macht für mich die Pflege einfacher.

Das finde ich interessant. Meine User-Cronjob-Scripte liegen unter ~/bin. Root-Cronjob-Scripte liegen entweder unter /etc/cron.* oder direkt in /usr/local/sbin. Das mit den Links finde ich von der Pflege etwas schwierig, weil man dann immer an zwei Stellen denken muss. Bei Scripten versuche ich tendenziell den ``Installationsschritt'', also die Entkopplung von Sourcen und ausfuehrbarem Programm, wegzulassen. Aber du schreibst, dann es fuer dich die Pflege einfacher macht. Mich wuerde interessieren wieso.

[chmod007]

Janz einfach: unter /root/scripts sind thematisch benannte Verzeichnisse mit den Scripten und ein paar selbstgemachten perlmodulen.
Wenn ich auf einer Maschine so ein Script bearbeitet habe un das erfolgreich getestet habe, muss ich nur nen tarball machen und kann das auf den anderen Maschinen einfach Abkippen. Alles bleibt zentral im rootdir und über symlinks landet das im PATH, was nötig ist.
Demnächst will ich das noch über git abwickeln. Da wäre es nur hinderlich wenn die Scripten sonstwo verteilt sind.

Deine Variante ist natürlich auch ok. Soll jeder so machen wie es für gut hält. Was wäre denn ein freies Betriebssystem, wenn man keine Freiheiten hat? Solange es wartbar und dokumentiert ist (und funktioniert), spricht m.M.n. nix dagegen.

Oder um meinen Flugsicherheitsaspekte frei zu zitieren: Wenn man weiß was man tut, kann man tun was man will

[uname]

Da wäre es nur hinderlich wenn die Scripten sonstwo verteilt sind.

Bei git wäre es eher kein Problem und wer mal selbst ein deb-Paket erstellt hat weiß auch, dass eigentlich jedes Programm mehr als einen Ordner nutzt. Es ist einfach ein anderer Ansatz. Du verfolgst die Windows-Idee, wo einfach alles in einem Verzeichnis abgeladen wird. Der Linux-Gedanke ist aber ein ganz anderer. Suchst du z.B. den ausführbaren Teil von "iceweasel" so brauchst du nicht suchen. Der ausführbare Teil befindet sich natürlich in /usr/bin und nicht in irgendeinem Iceweasel-Ordner. Wäre auch dumm, da man sonst PATH erweitern, einen symbolischen Link oder einen Alias nutzen müsste. Also genau das um was es hier in diesem Thread geht. Eine vollkommen unnötige Aktion, da alles vorbereitet ist. Und für eigene Anwendungen gibt es immer noch /root/bin, ~/bin, /usr/local/bin oder auch /usr/local/sbin. Da gehören deine ausführbaren Programme drin.

[PericoloGiallo]

Also werde ich das via PATH lösen. Danke für die Beteiligung!