starten von Script über init.d
-
Hallo,
ich möchte einige Scripte ins Verzeichnis init.d kopieren. Jetzt habe ich gesehen das hier nur shell oder bash Scripte vorhanden sind. Leider habe ich meine Sachen schon mir Perl geschrieben, diese möchte ich wenn möglich beibehalten.
Kann ich diese Perlscripte dann später über den Runlevel-Editor starten lassen, wenn ja, wie muss ich den Kopf des Perlscriptes verändern ?Danke
worst_case
-
Ich befürchte ich verstehe Dein Problem nicht ganz, was genau möchtest Du denn machen?
-
du kannst doch theoretisch Perl benutzen, du musst eben nur sicher stellen, dass Perl schon zur Verfügung steht wenn dein Script ausgeführt wird.
-
Hallo,
wie muß den der Kopf aussehen damit ich das Script auch im Runlevel-Editor sehe und die Beschreibung bekomme ?
Hat jemand sowas schon mal gemacht ?worst_case
-
Beschreibung im Runlevel-Editor?
Sowas hab ich nicht, aber schau Dir doch einfach mal die anderen Skripte in /etc/init.d an!
-
ich denke du musst halt in der ersten zeile '#!/pfad_zu_perl_bin' einsetzen und es muss als parameter 'start' bzw. 'stop' akzeptieren. ausserdem muss die datei das executable bit gesetzt haben - 'chmod 0755 scriptname' o.ä..
was du mit 'im runlevel-editor sehen' meinst verstehe ich auch nicht ganz.
[ Dieser Beitrag wurde am 10.03.2003 um 23:30 Uhr von murdock editiert. ]
-
er hat wahrscheinlich SuSE-Linux da gibt's 'nen RunLevel-editor ( yast ).
man kann doch auch sein kommando in /etc/init.d/boot.local eintragen, oder nicht?!
ciao
-
Ich glaub er meint folgendes Problem:
In der ersten zeile eines scripts steht, welchen interpreter er verwenden soll ...
#!/usr/bin/sh
zum Beispiel.
Ich hab kein Perl installiert, und finde Perl pfui :-))) (Ansichtssache)
kann dir also nicht sagen, wo normalerweise Perl liegt und wie das executable heist (aber ich tip auf "perl")Ciao ...
-
/usr/bin/sh
/bin/sh eher 
das sollte eben funktionieren, solange sicher gestellt ist, dass Perl bereits vorhanden ist (also nicht auf einer Partition liegt, die später gemountet wird oä.)
-
wenn es ein perl scrip ist muss schon der pfad zum per-interpreter als sog. sha-bang benutzt werden:
#!/pfad_zu_perl_interpreter
auch wenn's eigentlich um's bash scripting geht - diebzgl. ist's identisch: http://www.tldp.org/LDP/abs/html/sha-bang.html http://www.tldp.org/LDP/abs/html/invoking.html
man muss das script mit '/etc/init.d/scriptname start' bzw. 'stop' ausführen können.
-
/usr/bin/sh /bin/sh eher
Mist, sie bekommen aber auch alles mit :p
"Ich wollte ja nur eure Aufmerksamkeit testen!"
ist doch die Standard-Ausrede ???Ciao ...
-
(naja, bin einfach nur pingelig ;))
-
Hallo,
weil wir gerade bei shell und bash sind. Ich will mich da ein bißchen einarbeiten. Was würdet ihr empfehlen neue bash oder alte shell.
Für mich ist es egal da ich mich weder mit dem noch mit dem anderen auskenne.Ein how-to wenn möglich deutsch wäre nicht schlecht, sowie eine Adresse zu einem Forum.... gibt's doch bestimmt.
Danke
worst_case
-
Bash, einfach weil sie sehr verbreitet und sehr bequem ist. (Die meisten Leute haben die alte sh nur mehr um Skripts ressourcenschonend laufen lassen zu können oder gar nicht.)
-
Ich würde erst einmal lernen mit der POSIX SH (POSIX 1003.2) umzugehen, da man sich damit das Basis Wissen gut aneignen kann und portable Shell Scripte schreiben kann, die Zusatz Features der ZSH, KSH oder BASH (oder CSH ;)) kann man dann später erlernen, falls man diese unbedingt braucht.
ein paar Links zum Thema SHell Programmierung
Portable Shellscripte (aus dem autoconf Manual)
Advanced BASH-Scripting Guide
BASH Referenz Manual
-
Mit den Shell-Funktionalitäten einer sh kann man nicht so viel machen und darum greift man auch ständig auf andere Programme zu (find, grep, cut, echo, cat, expr, bc, awk, whatever). Unter Linux sind >95% dieser Programme traditionell GNU-Tools, die nicht wirklich für ihre Konformitäten gegenüber POSIX bekannt sind (oder sie zumindest so verstecken, dass 'man' die GNU-Möglichkeiten bevorzugt). Darum ist es IMHO nicht sinnvoll, den Anfängern POSIX-sh + proprietäre GNU-Tools zu lernen, sondern dann gleich richtig zB alle Features der Bash. Das macht die Scripte nicht mal so viel unportabler (ob ich mir eine Bash installieren muss, oder ein GNU-find ist recht egal) aber es spart Arbeit. Mal abgesehen davon, dass ich eben genau dann Shellscripte nehme, wenn ich weiß, dass die Programme ausschließlich lokalen Nutzen haben.
»It's easier to port a shell than a shell script.« [Larry Wall]
btw: Ich hätte die zsh empfohlen. Die programmierbare Vervollständigung ist, wie ich finde, ein wirklich gelungenes Feature.