Eigenes Befehl in Linux

S

Snycs

Gast
Hallo ich habe eine Frage. Gibt es eine Möglichkeit, ein Script mittels eines Konsolenbefehls auszuführen. Ich meine nicht per "./SCRIPT" sonder wie zum Beispiel "cp QUELLDATEI ZIELDATEI" oder "nano DATEINAME".

und wenn ja wo kann ich mein "Programm" dann hinlegen damit es funktioniert?

Mit freundlichen Grüßen

Snycs
 
Ja ganz einfach.
Du schreibst dir dein Programm per Bash-Script or in irgendeiner Programmiersprache.
Dann legst du das ganze einfach in Ordner, der in deiner PATH Variable ist, z.B. /usr/bin und machst es ggf. noch ausführbar.
Danach kannst du einfach mit dem "filename" dein Programm aufrufen.
 
Erstmal danke für die Antworten!

Wo kann ich Ordner zu dieser Variable hinzufügen?
 
Mit (wenn bash, sh oder ksh)

export PATH=$PATH:/mein/ordner:.

Erste $PATH nach dem = ist die bisherige Variable + der neue zusätzliche Kommandopfad, immer mit : getrennt. . heißt, führe das Programm aus dem aktuellen Pfad aus, wenn Du schon drin bist.

Mit

echo $PATH

kannst Du die Variable dann überprüfen. Für csh oder zsh mußt Du anstatt export dann set oder setenv verwenden.
 
Zuletzt bearbeitet: (, ksh))
Ich habe bei mir in der Datei ~/.bashrc z.B. folgendes:
Code:
# set PATH so it includes user's private bin if it exists
if [ -d ~/.bin ] ; then
    PATH=~/.bin:"${PATH}"
    export PATH
fi

Ein paar häufig genutzte Skripte für den persönlichen Gebrauch kann ich dann einfach unter dem Ordner ~/.bin ablegen.
 
Zuletzt bearbeitet:
Könnte es nicht Probleme geben, wenn man sein Script nach /usr/bin oder /usr/local/bin kopiert? Ich lese gerade ein Linux-Buch, und darin steht dass /usr/bin die Programme der Distribution enthält und /usr/local/bin für gewöhnlich kompilierte Programme. Wenn da nun Dateien denselben Namen haben (oder demnächst nach einer Installation oder einem Kompiliervorgang haben werden) wie das eigene Script, dann entstehen doch bestimmt Konflikte. Welches Verzeichnis wäre sicher und dennoch Teil gängiger Standards?
 
In ~/.baschrc kann man für sich als user mit

Code:
alias foo="bar"

wunderbar alles ablegen was man regelmäßig braucht. Beliebt sind da solche Sachen wie

Code:
alias ll="ls -alFh"

Es können mit entsprechender Pfadaufgabe auch beliebig Script aufgerufen werden.
 
computerfrust schrieb:
Welches Verzeichnis wäre sicher und dennoch Teil gängiger Standards?
Üblich sind /usr/local/bin für systemweit nutzbare Programme (nein, nicht nur compilierte Programme. Ob compiliert oder Skript ist sowieso vollkommen egal) und ~/bin für private Sachen. Man verwendet sinnvollerweise andere Namen als Unix-Standardprogramme haben. Man wird sein eigenes Progrämmchen also eher nicht als ~/bin/ls ablegen wollen, weil man ls ständig nutzt und damit /bin/ls aufrufen möchte.

Mach dir nicht so viele Sorgen um irgendwelche "Standards". Mach was funktioniert. Insbesondere ist alles in deinem Homeverzeichnis deine Sache. Nur füge bitte nicht "." (das aktuelle Verzeichnis) zur PATH-Variable hinzu, auch nicht am Ende.
 
Zuletzt bearbeitet:
mensch183 schrieb:
... was man nicht möchte.
Was Du nicht möchtest! Mach ich seit über 30 Jahren so. Wenn man als Admin nicht weiß, was man da tut, klar, dann sollte man es lassen. Mich nervt es immer, extra ./ angeben zu müssen.

@Troublegum

~/bin würde ich nicht als PATH nehmen, immer lieber einen absoluten Pfad, und ab besten über eine Variable.

Code:
# set PATH so it includes user's private bin if it exists
if [ -d $HOME/.bin ] ; then
    PATH=$HOME/.bin:"${PATH}":.
    export PATH
fi


Code:
MYBIN=$HOME/bin

# set PATH so it includes user's private bin if it exists
if [ -d $MYBIN ] ; then
    PATH=$MYBIN:"${PATH}":.
    export PATH
fi

Ist aber alles letztlich geschmacks- und stilfrage. Genau so wie mit dem . am Ende. Wenn Du viel tippst und viele Befehle verwendest, dann mache in rein. Wenn Du Schiß hast, wie die anderen hier, laß es. Vorteil mit dem Punkt wäre, daß der Befehl dann bei bash mit TAB ergänzt wird, ohne daß Du jedesmal extra ./ tippen mußt.

@all

Und wer ganz paranoid ist, und sich über den . im Pfad aufregt, er sollte von allen das executable-flag entfernen, und alles nur mit
Code:
bash/ksh/sh befehl
ausführen. :rolleyes:
mensch183 schrieb:
Mach dir nicht so viele Sorgen um irgendwelche "Standards". Mach was funktioniert. Insbesondere ist alles in deinem Homeverzeichnis deine Sache. Nur füge bitte nicht "." (das aktuelle Verzeichnis) zur PATH-Variable hinzu, auch nicht am Ende.
Und warum nicht? :freak: Es bringt kaum einen Sicherheitsnutzen, wenn man es wegläßt. Aber es bringt sehr viel Bequemlichkeit in das tägliche Arbeiten, wenn Du mit vielen verschiedenen Befehlspfaden arbeiten mußt (welche nicht im PATH sind). Wie gesagt, wer nicht weiß, was er da tut, sollte es dann lieber ganz lassen. Man kann auch viele Pfade im PATH unterbringen, daß ist dann genauso unsicher oder sicher wie :.
 
Zuletzt bearbeitet:
PHuV schrieb:
Was Du nicht möchtest! Mach ich seit über 30 Jahren so. Wenn man als Admin nicht weiß, was man da tut, klar, dann sollte man es lassen. Mich nervt es immer, extra ./ angeben zu müssen.
Mit Wissen ist es nicht getan. Es sei denn, man hat nie mit Files Fremder zu tun und kann sicherstellen, sich grundsätzlich nie zu vertippen. Bei Otto Normalmensch trifft dies nicht zu und er empfindet deshalb . in $PATH - auch am Ende - als Fahrlässigkeit.
 
Zuletzt bearbeitet:
  1. Normalerweise schaut man auch immer, wenn man den Pfad wechselt, vorher, was da für Dateien drin sind und welche executable sind. ;)
  2. Und man schaut sich durch die Ersetzung vorher den Befehl nochmal an, bevor man ihn mit Return/Enter absetzt.
  3. Ist der aktuelle Pfad unter Windows auch immer ein Kommandopfad
Das ist überhaupt nicht fahrlässiger, als einen beliebigen Pfad in PATH mit aufzunehmen. Aber wie ich bereits sagte, alles eine Frage des eigenen Geschmacks und Stils.

Troublegum schrieb:
Spielt überhaupt keine Rolle. Bash expandiert das zu nem absolutem Pfad. Macht für $PATH keinen Unterschied, da dort ein absoluter Pfad steht.
Du hast damit nur ein Problem, wenn Du mit verschieden Usern unterwegs bist, und entsprechende Befehle absetzen mußt. ;) Da ist dann sicherlich $HOME auch die falsche Wahl, und deshalb sage ich ja, besser ist es den absoluten Pfad zu verwenden.
 
Zuletzt bearbeitet:
Zurück
Oben