Nettes template Hier noch eine kleine Funktion als Erweiterung, die ich regelmaessig benutze, um sicherzustellen, dass alle noetigen exectuables auf dem System vorhanden sind:
# subroutine to check for some required executables # argument: (list of) programs to test for # will exit with rc=1 if any program was not found # function checkfor() { for i in $*; do PROG=`which $i` if [ $? != 0 ] ; then echo "'$i' command not found, exiting." exit 1 fi done }
... das Ganze wird dann aufgerufen z.B. als 'checkfor scanimage convert mv'
Von Jochen Gruse am Mo, 31. Oktober 2005 um 10:08 #
Nette Idee!
Aber darf ich dazu ein wenig klugscheissern? ;-) Meine Fassung sähe so aus:
function checkfor { typeset I
for I; do if ! type $I >&- 2>&- ; then echo "'$I' command not found, exiting." exit 1 fi done return 0 }
Am Schlüsselwort "function" kann man erkennen, dass es eine bash-Funktion ist. Daher sollte man dann auch die bash-Features nutzen:
- typeset, um I funktionslokal zu machen. Sonst könnte man ein I im Hauptprogramm verändern. - for-Schleife über alle Funktionsparameter ohne "in $*" - unnötig. - PROG wird außer in der Zuweisung nicht genutzt - weg damit. - type statt which, da type eine Shellfunktion und kein externes Kommando ist - schneller. - Exitcode von type direkt im if auswerten, da man die Auswertung mittels "!" umkehren kann.
Von Besserwisser (das Original) am Mo, 31. Oktober 2005 um 08:50 #
Sehr gut und sehr nützlich, nur ist dieses Template nach einem chmod 700 ein Programm. Unter welcher Lizenz steht dann dieses Programm, vermutlich nicht unter der Creative Commons ShareAlike License, oder?
Von Jochen Gruse am Mo, 31. Oktober 2005 um 09:33 #
Oh je, würdest Du auch für ein "Hello, World!"-Skript eine Lizenz verlangen? Wenn Du darauf bestehst: Ich gebe das Copyright an dem Template auf und setze es hiermit ins Public Domain.
Von Jochen Gruse am Mo, 31. Oktober 2005 um 09:51 #
Vielleicht nicht de jure, aber de facto. Denn wenn es mich einfach nicht interessiert, was andere damit machen und ich mich nicht weiter darum kümmere, ist der Endeffekt derselbe. Wem das zu "unsicher" ist - ich könnte mich ja im hinterdrein als patent-, trademark- und copyrightschwingendes SCO-Monster erweisen! - der muss eben auf das Template verzichten. Ich nehme an, die Überlebenschancen eines Skriptprogrammierers liegen trotz des Verlustes bei 85%... :-)
Da der Author das ganze soeben als 'Public Domain' deklariert hat darfst du damit tun und lassen was du willst. Sogar auf ne Klopapierrolle drucken und...
Prinzipiell finde ich Templates für Shell Skripte nicht schlecht, allerdings sollte ein Template nicht Shell spezifisch sein sondern möglichst Shell unabhängig. Gerade wenn man in grossen Firmen arbeitet hat man es oft mit vielen unterschiedlichen UNIX Dialekten samt unterschiedlicher Shell zu tun. Daher bevorzuge ich Templates die man von AIX über HP-UX bis Linux und BSD nutzen kann. Dies lässte sich schon mit recht einfachen Mitteln erreichen, z.B.:
if [ "x${VAR}" = "xVALUE" ]; then echo "Do it!" fi
Das funktioniert auf jeder Shell wenn [ als Link auf test existiert. Zwar sind Konstrukte die externe Programme statt interner Shell Funktionen nutzten nicht so performant, die Zeit die man sich aber bei der Migartion auf neue Zielsysteme spart wiegt das (IMHO) locker wieder auf.
Von Jochen Gruse am Mo, 31. Oktober 2005 um 13:50 #
Da hast Du sicherlich nicht unrecht. Da die moderneren Shells aber durchgängig sowohl performanter als auch lesbarer(!) zu programmieren sind, neige ich zu einer anderen Lösung: - Skripte auf die Schnittmenge der Features von ksh und bash begrenzen; die Portierung erledigt sich dann zwischen Linux und AIX/HP-UX durch das Ändern der #!-Zeile. - Eine der moderneren Shells (vorzugsweise bash) im Hause als Skripting-Shell festlegen und dafür sorgen, dass jeder Rechner die Shell installiert hat. Gerade die bash ist mittlerweile für alle Unices als vorgefertigtes Binary zu erhalten.
Warum als Shebang nicht #! /bin/sh? Das zeigt aus HP-UX, AIX, Solaris und Linux auf BASH oder KSH, einzig bei BSD müsste man dann tricksen (zeigt dort IMHO auf die originale Bourne Shell).
Das geht insofern nicht, als dass sich die bash anders verhaelt, wenn sie als sh aufgerufen wird. Sozusagem in "sh Kompatibilitaetsmodus". bash kennt dann - zum Beispiel - kein Process Substitution mehr.
Von Jochen Gruse am Mo, 31. Oktober 2005 um 14:17 #
/bin/sh soll auch bei Solaris ein Link auf /bin/ksh sein? Das muss ich mal checken. Mein letzter Stand der Dinge sagt da was anderes.
Ansonsten würde ich's persönlich für schlechten Stil halten. Entweder man schreibt ein Skript für die Bourne-Shell, dann heisst die Shebang-Zeile "#!/bin/sh", oder man will auch fortgeschrittene Möglichkeiten haben, dann verwendet man eine andere Shell und der Shebang heißt dementsprechend "#!/bin/bash".
Nu je, es soll ein jeder nach seiner Facon selig werden.
Zweiterer Vorschlag ist bei uns nicht möglich, wir haben über 8.500 Server, bevor man dort einen Standard festgelegt bekommt vergehen mindestens drei Jahre ;-).
KornShell ist offizieller POSIX-Standard. Daher schreib ich Shell-Skripte in KornShell. ash, bash, ksh, pdksh und zsh kommen alle damit klar. Und mindestens eine von ihnen ist mit Sicherheit für das jeweilige "UNIX" verfügbar.
BTW. Die bash sollte [ eigentlich als internen Befehl auswerten, weshalb man ruhig ohne Performanceverluste [ verwenden kann.
No offense, aber shell-skripte sind einfach furchtbar zu lesen. klar ist es ganz nett, dass man andere programme so bequem in shell-skripten aufrufen kann, aber sobald man mal etwas text verarbeiten muss, oder schleifen und verzweigungen, wird es schnell unübersichtlich und hässlich.
# subroutine to check for some required executables
# argument: (list of) programs to test for
# will exit with rc=1 if any program was not found
#
function checkfor()
{
for i in $*; do
PROG=`which $i`
if [ $? != 0 ] ; then
echo "'$i' command not found, exiting."
exit 1
fi
done
}
... das Ganze wird dann aufgerufen z.B. als 'checkfor scanimage convert mv'
Gruss,
- Joerg
Aber darf ich dazu ein wenig klugscheissern? ;-)
Meine Fassung sähe so aus:
function checkfor {
typeset I
for I; do
if ! type $I >&- 2>&- ; then
echo "'$I' command not found, exiting."
exit 1
fi
done
return 0
}
Am Schlüsselwort "function" kann man erkennen, dass es eine bash-Funktion ist. Daher sollte man dann auch die bash-Features nutzen:
- typeset, um I funktionslokal zu machen. Sonst könnte man ein I im Hauptprogramm verändern.
- for-Schleife über alle Funktionsparameter ohne "in $*" - unnötig.
- PROG wird außer in der Zuweisung nicht genutzt - weg damit.
- type statt which, da type eine Shellfunktion und kein externes Kommando ist - schneller.
- Exitcode von type direkt im if auswerten, da man die Auswertung mittels "!" umkehren kann.
Also etwas schneller und vor allem sicherer.
Grüße,
Jochen
echo "'$I' command not found, exiting." >&2
Jochen
Jochen
Jochen
Irgendwas dagegen, wenn ich das Skript ins Englische uebersetze und auf shellscript.org hochlade?
Freundliche Gruesse,
Benjamin
Jochen
Jochen
Gruesse,
Benjamin
if [ "x${VAR}" = "xVALUE" ]; then
echo "Do it!"
fi
Das funktioniert auf jeder Shell wenn [ als Link auf test existiert. Zwar sind Konstrukte die externe Programme statt interner Shell Funktionen nutzten nicht so performant, die Zeit die man sich aber bei der Migartion auf neue Zielsysteme spart wiegt das (IMHO) locker wieder auf.
MfG =HAL9000=
- Skripte auf die Schnittmenge der Features von ksh und bash begrenzen; die Portierung erledigt sich dann zwischen Linux und AIX/HP-UX durch das Ändern der #!-Zeile.
- Eine der moderneren Shells (vorzugsweise bash) im Hause als Skripting-Shell festlegen und dafür sorgen, dass jeder Rechner die Shell installiert hat. Gerade die bash ist mittlerweile für alle Unices als vorgefertigtes Binary zu erhalten.
Jochen
Gruss HAL9000
bash kennt dann - zum Beispiel - kein Process Substitution mehr.
Gruesse,
Benjamin
Ansonsten würde ich's persönlich für schlechten Stil halten. Entweder man schreibt ein Skript für die Bourne-Shell, dann heisst die Shebang-Zeile "#!/bin/sh", oder man will auch fortgeschrittene Möglichkeiten haben, dann verwendet man eine andere Shell und der Shebang heißt dementsprechend "#!/bin/bash".
Nu je, es soll ein jeder nach seiner Facon selig werden.
Jochen
Gruss HAL9000
ash, bash, ksh, pdksh und zsh kommen alle damit klar. Und mindestens eine von ihnen ist mit Sicherheit für das jeweilige "UNIX" verfügbar.
BTW. Die bash sollte [ eigentlich als internen Befehl auswerten, weshalb man ruhig ohne Performanceverluste [ verwenden kann.