sh4711
Anmeldungsdatum: 13. Februar 2011
Beiträge: 912
|
Hallo alle miteinander, ich würde gerne eine Funktion in einem echo Ausdruck aufrufen und somit den Rückgabewert ausgeben.
Ganz grob so:
f(){
return $1
}
echo $(f 100000) Der Rückgabewert scheint mir aber nur ein int16 oder so zu sein und beim Funktionsaufruf im echo weiß ich nicht wie ich es anstellen soll. Danke schon mal für eure Hilfe. Gruß
SH
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
Du musst zwischen dem Rückgabewert und der Ausgabe auf stdout unterscheiden. $(BEFEHL) ist eine Command Substitution, d.h. der Ausdruck wird durch die Ausgabe des ausgeführten Befehls auf stdout ersetzt und der Exit-Status darf nur einen Wert zwischen 0 und 255 annehmen: https://www.gnu.org/software/bash/manual/html_node/Exit-Status.html:
| function foo () {
echo "bar"
return 250
}
output=$(foo)
return_value=$?
echo "command foo exited with exit status $return_value and output '$output'"
|
Der obige code sollte command foo exited with exit status 250 and output 'bar'
ausgegeben. Da der Exit-Status nicht so hohe Werte annehmen kann, musst du das Argument auf stdout ausgeben und mit der Command Substitution fangen (was in dem Beispiel relativ sinnfrei ist):
| f(){
echo $1
}
echo $(f 100000)
|
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
Der Rückgabewert ist ein Byte und als Fehlercode gedacht - alles ungleich 0 bedeutet einen Fehler, und gemeint ist die binäre 0, nicht das Zeichen, das man auf der Shell lesen kann. Du kannst, anders als man es von den meisten Programmiersprachen gewohnt ist, keine Strings oder anderen Ergebnisse zurückgeben, nur ausgeben: | f(){
echo $1
}
echo $(f 100000)
|
In dieser Form ist das natürlich reichlich sinnlos, aber wenn f etwas elaborierter ist ... . Den Rückgabewert (=Fehlercode) machst Du mit $? sichtbar: | f(){
echo $1
}
echo $(f 100000)
echo $?
|
|
sh4711
(Themenstarter)
Anmeldungsdatum: 13. Februar 2011
Beiträge: 912
|
@seahawk1986,user_unknown Vielen Dank für eure ausführlichen Antworten. seahawk1986 schrieb: ... (was in dem Beispiel relativ sinnfrei ist):
...
Ok, es war kein Code, eher eine Code-Skizze 😉 user_unknown schrieb: ..., aber wenn f etwas elaborierter ist ... .
...
Ja, danke. Für mein Verständnis: D.h. in Bash-Skripten wird die Funktion in erster Linie als Prozedur verstanden, welche den Luxus eines ein Byte großen "Rückgabewertes" hat, richtig? Und Probleme werden in der Regel iterativ gelöst und eher selten rekursiv aufgrund der Einschränkung beim Rückgabewert, richtig?
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
sh4711 schrieb:
Für mein Verständnis: D.h. in Bash-Skripten wird die Funktion in erster Linie als Prozedur verstanden, welche den Luxus eines ein Byte großen "Rückgabewertes" hat, richtig?
Sie hat den Luxus, 255 unterschiedliche Fehler zu signalisieren. Man kann es für Rückgabewerte misbrauchen, was den Nachteil hat, dass man dann keine Fehler mehr signalisieren kann. Wenn man natürlich eine Monatszahl von 1-12 zurückgeben will, kann man mit 0 einen Fehler signalisieren oder mit 13. Allerdings werden alle Leser des Codes über die Stelle stolpern.
Und Probleme werden in der Regel iterativ gelöst und eher selten rekursiv aufgrund der Einschränkung beim Rückgabewert, richtig?
Kann man so nicht sagen. Ob man rekursiv weder Strings noch Dezimalzahlen noch große Werte zurückgeben kann, oder iterativ - was macht den Unterschied?
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
sh4711 schrieb: Und Probleme werden in der Regel iterativ gelöst und eher selten rekursiv aufgrund der Einschränkung beim Rückgabewert, richtig?
Die Rekursionstiefe in der Bash ist begrenzt (vgl. z.B. https://rosettacode.org/wiki/Find_limit_of_recursion#UNIX_Shell, wenn du das selber ausprobieren willst) - wenn man eine große Rekursionstiefe braucht, würde ich mir eine andere Programmiersprache aussuchen, die weniger Overhead hat.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8554
Wohnort: Münster
|
sh4711 schrieb: […] in Bash-Skripten wird die Funktion in erster Linie als Prozedur verstanden, welche den Luxus eines ein Byte großen "Rückgabewertes" hat, richtig? Und Probleme werden in der Regel iterativ gelöst und eher selten rekursiv aufgrund der Einschränkung beim Rückgabewert, richtig?
Beides ist nicht ganz richtig. Bash verhält sich bzgl. der Kommunikation mit Programmen genau so wie jedes Programm unter einem unixoiden Betriebssystem: Ein solches Programm oder auch eine Funktion einer Shell oder sogar jeder einzelne Shell-Befehl bekommt im Normalfall Eingaben über die Standard-Eingabe stdin und schreibt seine Ergebnisse auf die Standard-Ausgabe stdout, jedenfalls solange man das nicht selbst ändert. Es gibt in allen genannten Fällen keine Rückgabe-Variablen, es sei denn, man definiert selbst solche toten Briefkästen. Das Verhalten bei Programmiersprachen ist der Sonderfall, indem diese die Definition solcher Rückgabe-Variablen leicht machen. Man kann im Prinzip in der Bash uneingeschränkt rekursiv programmieren. Das erlaubt elegante Funktionen, ist aber prinzipbedingt speicherintensiv. Wenn man es mit der Rekursionstiefe übertreibt, muss man bei der Bash genau wie bei jeder anderen Programmiersprache mit Abstürzen wegen Speichermangel rechnen. Man kann bei der Bash die Aufruftiefe und damit die Rekursionstiefe bei Funktionsaufrufen begrenzen über die Variable FUNCNEST, welche normalerweise nicht gesetzt ist. Außerdem sind natürlich auf „normaler“ Hardware rekursive Programme langsamer als iterative Programme, was bei interpretierten Sprachen (Skript!) sehr schnell schmerzt. Das sind aber alles keine Probleme der Bash, sondern der Methode.
|
lipkowski.be
Anmeldungsdatum: 15. Dezember 2019
Beiträge: 16
|
Hallo, ich handle das immer so: 1. Ich erstelle eine function die, Infos und Kommentare nach stderr piped
function _msg
{
echo "$*" 1>&2
} 2. In der richtigen function verwenden ich diese dann für normale Ausgaben und das Normale echo bzw. stdout für die Rückgabe. return ist meines Wissens nach für Status Codes. 0 = alles OK, 1 bis X = Fehler
Beispiel:
function lbe_testsub
{
local v_mystr='' #variable deklarieren
local v_mydate=''
v_mystr='Dies ist ein'
v_mystr="${v_mystr}"' Test um'
_msg 'Datum und Uhrzeit wird bestimmt'
v_mydate="$(date)"
v_mystr="${v_mystr}""${v_mydate}"
_msg 'Gebe mystr zurueck'
echo "${v_mystr}"
return 0
}
echo 'Die Rückgabe war:'
echo "$(lbe_testsub)"
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
kB schrieb: sh4711 schrieb: […] in Bash-Skripten wird die Funktion in erster Linie als Prozedur verstanden, welche den Luxus eines ein Byte großen "Rückgabewertes" hat, richtig? Und Probleme werden in der Regel iterativ gelöst und eher selten rekursiv aufgrund der Einschränkung beim Rückgabewert, richtig?
Beides ist nicht ganz richtig.
...
Man kann im Prinzip in der Bash uneingeschränkt rekursiv programmieren. Das erlaubt elegante Funktionen, ist aber prinzipbedingt speicherintensiv. Wenn man es mit der Rekursionstiefe übertreibt, muss man bei der Bash genau wie bei jeder anderen Programmiersprache mit Abstürzen wegen Speichermangel rechnen.
Das ist auch nicht ganz richtig. In Scala (und anderen funktionalen Programmiersprachen) kann man rekursive Funktionen so programmieren, dass sie nicht speicherintensiver sind, als Schleifen.
Man kann bei der Bash die Aufruftiefe und damit die Rekursionstiefe bei Funktionsaufrufen begrenzen über die Variable FUNCNEST, welche normalerweise nicht gesetzt ist. Außerdem sind natürlich auf „normaler“ Hardware rekursive Programme langsamer als iterative Programme,
Das trifft auch für Scala nicht zu.
was bei interpretierten Sprachen (Skript!) sehr schnell schmerzt.
Und auch das stimmt vielleicht für einige Sprachen, aber für Scala beispielsweise nicht, welches man, wenn man will, durch einen Interpreter laufen lassen kann, aber bei Bedarf und im Normalfall zu JVM-Bytecode kompiliert.
Das sind aber alles keine Probleme der Bash, sondern der Methode.
Insofern sind das durchaus Probleme beim rekursiven Programmieren mit der Bash und nicht solche der Methode.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
lipkowski.be schrieb: Darf ich ein wenig Codereview üben?
function lbe_testsub
Was immer "lbe" bedeuten soll. Weder Datum, noch Uhrzeit wecken Assoziationen.
{ local v_mystr= #variable deklarieren
local v_mydate= v_mystr='Dies ist ein'
}}}
Nicht sinnvoll: Deklaration und Initialisierung zu trennen. Nicht sinnvoll: Das Offensichtliche, Variablendeklartion, zu kommentieren. Nicht sinnvoll: Ein v_-Präfix für Variablen. Das ist unergonomisch, weil gerade der Namensbeginn beim Erfassen von geschriebenem Text eine große Rolle spielt. Nicht sinnvoll: Ein Subpräfix "my". Wessen sonst? Man kann dann jede Variable und Funktion mit "my" dekorieren oder es wirft Fragen auf, wenn es unterbleibt. Der interessierende Part, wie die Variable denn nun heißt, wandert weiter und weiter nach hinten mit jedem Präfix. Beim Überfliegen ist es manchmal uninteressant, ob ein Aufruf eine Variable oder einen Wert oder eine Prozedur benutzt. Änderst Du den Code hin zu einer Konstanten musst Du alle Vorkommen anpassen. Wieso nicht _mymsg, bzw. f_mymsg oder richtig skurill, _f_mymsg? Was soll der Unterstrich ausdrücken? Geschützte Systemvfunktion?
v_mystr="${v_mystr}"' Test um'
_msg 'Datum und Uhrzeit wird bestimmt'
v_mydate="$(date)"
v_mystr="${v_mystr}""${v_mydate}"
_msg 'Gebe mystr zurueck'
echo "${v_mystr}"
Schließlich:
return 0
}
Wozu ist "return 0" am Ende einer Funktion gut? Und wieso rufst Du
echo 'Die Rückgabe war:'
echo "$(lbe_testsub)"
auf, statt
echo 'Die Rückgabe war:'
lbe_testsub Die Fehlerausgabe für unnötig geschwätzige Ausgaben zu missbrauchen konterkariert auch die Trennung von STDERR und STDOUT. Was, wenn jemand jetzt die wirklichen Fehler in eine Datei umlenken will? Sinnvoller wäre dann schon, wenn man dem User die Entscheidung über eine straffe oder ausladende Ausgabe überlassen will, dann baut man einen Schalter -v ein, und reagiert entsprechend.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8554
Wohnort: Münster
|
user_unknown schrieb: […] Das ist auch nicht ganz richtig. In Scala […] Das trifft auch für Scala nicht zu.
Du hast offenbar überlesen, dass es in diesem Thread nicht um Scala geht, sondern um Bash. Ich habe auch nur etwas über die Bash geschrieben. Deine Kritik geht also am Thema und am Gesagten vorbei. Sie ist auch inhaltlich falsch. Scala mag eine gute Programmiersprache sein, aber in Bezug auf rekursive Funktionen ist sie natürlich nicht grundsätzlich besser als andere. Sie hat lediglich im Compiler eine Erkennung einer bestimmten Teilklasse von rekursiven Programmen, namentlich der endrekursiven Programme eingebaut und der Compiler optimiert solche Programme, genauer ersetzt er die Endrekursion durch eine Schleife. Das dies dann schneller ausgeführt wird, liegt in der Natur der Sache. Wenn man diese Compileroptimierung abschaltet oder allgemeinere Rekursionen benutzt, die nicht automatisch zu Iterationen umformulierbar sind, dann hat Scala keinen Vorteil vor anderen Sprachen. Diese automatische Ersetzung von Endrekursion durch Iteration im Compiler ist übrigens kein Alleinstellungsmerkmal von Skala, sondern gehört zum Grundrepertoire des Compilerbaus. Auch der Basic-Compiler von Microsoft kann das, macht damit aber weniger Aufhebens als Scala. Diese Tricks greifen natürlich nur, wenn ein Compiler oder auch ein JIT-Compiler im Spiel ist, was bei der Bash als rein interpretierte Sprache eben nicht der Fall ist. Deshalb:
Ja, Bash kann rekursive Funktionen und ist funktional dabei genau so gut wie andere Sprachen, einschließlich Scala. Und: Nein, Bash ist dabei nicht so schnell wie andere Sprachen, auch Skala ist dabei wesentlich schneller.
Das soll aber niemand grundsätzlich von der Verwendung der Sprache Scala abhalten.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
kB schrieb: user_unknown schrieb: […] Das ist auch nicht ganz richtig. In Scala […] Das trifft auch für Scala nicht zu.
Du hast offenbar überlesen, dass es in diesem Thread nicht um Scala geht, sondern um Bash. Ich habe auch nur etwas über die Bash geschrieben. Deine Kritik geht also am Thema und am Gesagten vorbei.
Dann lies nochmal, was Du selbst geschrieben hast:
Wenn man es mit der Rekursionstiefe übertreibt, muss man bei der Bash genau wie bei jeder anderen Programmiersprache mit Abstürzen wegen Speichermangel rechnen.
Man muss nicht in jeder Programmiersprache, abhängig von der Rekursionstiefe, mit Abstürzen rechnen. Du schreibst da ganz explizit nicht über die Bash, sondern über jede andere Sprache.
Man kann bei der Bash die Aufruftiefe und damit die Rekursionstiefe bei Funktionsaufrufen begrenzen über die Variable FUNCNEST, welche normalerweise nicht gesetzt ist. Außerdem sind natürlich auf „normaler“ Hardware rekursive Programme langsamer als iterative Programme,
Hier verwendest Du die Formulierung "rekursive Programme" ohne Einschränkung auf die Bash, die Du gemeint haben magst, aber da Du zuvor selbst andere Programmiersprachen ins Spiel gebracht hast, ist eine solche Absicht nicht naheliegend. Es wirkt mehr wie eine Aussage über rekursive Programme.
was bei interpretierten Sprachen (Skript!) sehr schnell schmerzt. Das sind aber alles keine Probleme der Bash, sondern der Methode.
Auch hier sprichst Du von interpretierten Sprachen in Mehrzahl, also nicht spezifisch zur Bash, sondern allgemeiner. Auch der letzte Satz unterstreicht das. Ich halte fest: Du hast Dich speziell zur Bash geäußert und dies mit anderen Sprachen und rekursiver Programmierung allgemein in Bezug gesetzt, und diese Aussagen waren nicht akkurat. Deshalb habe ich das richtiggestellt, und ich weiß, dass da andere Sprachen nicht ganz unbelekt sind, aber mangels eigener Erfahrung habe ich als Beispiel Scala gewählt. Die Aussage "Alle Schwäne sind weiß" kann mit einem schwarzen Schwan widerlegt werden - man muss dazu nicht auch grüne und blaue nennen, aber schön, dass Du selbst welche kennst.
Sie ist auch inhaltlich falsch.
Doch.
Scala mag eine gute Programmiersprache sein, aber in Bezug auf rekursive Funktionen ist sie natürlich nicht grundsätzlich besser als andere.
Grundsätzlich besser als Bash, doch, natürlich!
Sie hat lediglich im Compiler eine Erkennung einer bestimmten Teilklasse von rekursiven Programmen, namentlich der endrekursiven Programme eingebaut und der Compiler optimiert solche Programme, genauer ersetzt er die Endrekursion durch eine Schleife. Das dies dann schneller ausgeführt wird, liegt in der Natur der Sache. Wenn man diese Compileroptimierung abschaltet
Da scheinst Du auch nicht 100% akkurat informiert zu sein. Der Schalter, den es gibt, bewirkt lediglich, dass man beim Kompilieren gewarnt wird, wenn eine als tail-recursive markierte Funktion
nicht tail-rekursive ist. Optimiert werden diese Funktionen so oder so.
oder allgemeinere Rekursionen benutzt, die nicht automatisch zu Iterationen umformulierbar sind, dann hat Scala keinen Vorteil vor anderen Sprachen.
Diese automatische Ersetzung von Endrekursion durch Iteration im Compiler ist übrigens kein Alleinstellungsmerkmal von Skala,
Ein Glück, dass das niemand behauptet hat.
sondern gehört zum Grundrepertoire des Compilerbaus. Auch der Basic-Compiler von Microsoft kann das, macht damit aber weniger Aufhebens als Scala.
Wie vornehm von ihm! Zum Glück hat er seine Fanboys, die es hinausposaunen! 😉
Diese Tricks greifen natürlich nur, wenn ein Compiler oder auch ein JIT-Compiler im Spiel ist, was bei der Bash als rein interpretierte Sprache eben nicht der Fall ist. Deshalb:
Stürzt leichter ab und ist deutlich langsamer, aber ist genauso gut wie andere Sprachen? Für die, denen Stabilität, Sicherheit und Geschwindkeit nicht als Qualitätskriterien gelten, sicher. ☺
Das soll aber niemand grundsätzlich von der Verwendung der Sprache Scala abhalten.
Wolltest Du schreiben, es solle niemanden von der Verwendung der Bash abhalten? So hat der Satz keinen Sinn.
|
sh4711
(Themenstarter)
Anmeldungsdatum: 13. Februar 2011
Beiträge: 912
|
OK, vielen Dank nochmals an alle für ihre Beiträge. Ich nehme mit, Rekursion geht in der bash mit einigen Vor- und Nachteilen die man zum Teil auch aus anderen Programmiersprachen kennt. Aufruf und Rückgabewerte werden syntaxbedingt anders ausgeführt/übergeben als z.B. in ... . Wobei dies nicht abwertend oder aufwertend gemeint ist. Das reicht mir erst mal. Da ich mich an die Bash rann tasten will probiere ich verschiedenstes immer wieder mal aus. Und jetzt war das Thema Rekursion an der Reihe. Da ich beim überfliegen der Literatur nicht das Schema gefunden hatte, analog zum Funktionsaufruf z.B. in c# oder Objekt Pascal, habe ich diese Frage gestartet. seahawk1986 schrieb: sh4711 schrieb: Und Probleme werden in der Regel iterativ gelöst und eher selten rekursiv aufgrund der Einschränkung beim Rückgabewert, richtig?
Die Rekursionstiefe in der Bash ist begrenzt (vgl. z.B. https://rosettacode.org/wiki/Find_limit_of_recursion#UNIX_Shell, wenn du das selber ausprobieren willst) - wenn man eine große Rekursionstiefe braucht, würde ich mir eine andere Programmiersprache aussuchen, die weniger Overhead hat.
Danke für den Link zu rosettacode.org. Das verrückte ist, dass ich eine solche Seite schon immer gesucht habe und bis heute nicht wusste das es diese Seite gibt. Und noch verrückter ist, dass ich am Wochenende auf code.golf immer wieder den Link zu rosettacode.org gelesen habe und mir einredete, trotz Neugierde, dass ich keine Zeit habe den Link aufzurufen 🙄 user_unknown schrieb: ... Fanboys, ...
Um Eure Diskussion wieder auf eine reine Sachebene herunter zu bringen, habe ich eigentlich schon erwähnt, dass Obejkt Pascal die schönste und beste Sprache ist, mit den tollsten und schnellsten Compilern? 😛 Danke noch mal.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
sh4711 schrieb:
user_unknown schrieb: ... Fanboys, ...
Um Eure Diskussion wieder auf eine reine Sachebene herunter zu bringen, habe ich eigentlich schon erwähnt, dass Obejkt Pascal die schönste und beste Sprache ist, mit den tollsten und schnellsten Compilern? 😛
Prima. Ein Dialekt davon, Hektopascal, läuft auf meinem Barometer.
|
lipkowski.be
Anmeldungsdatum: 15. Dezember 2019
Beiträge: 16
|
Hallo, zu deiner Kritik. Allem voran das war nur eine Beispiel um mein Handling von bash Funktionen zu zeigen. Also infos per Stderr, Rückgabe per Stdout. 1.) Was immer "lbe" bedeuten soll. Weder Datum, noch Uhrzeit wecken Assoziationen.
=> lbe_ ist bei mir ein Präfix, da ich alle meine Bash Funktionen in einer Datei habe und diese dann per Parameter1 selektiere (wie bei busybox).
Ist für das Beispiel nicht nötig aber macht der Gewohnheit. Hat aber den Vorteil das man nicht ausversehen eine binary in Linux überschreibt.
2.) Nicht sinnvoll: Deklaration und Initialisierung zu trennen.
=> Finde ich schon aus dem einfachen Grund, das man besser sieht das es sich um Variablen handelt. Zudem sind Variablen in Bash per default Global. Durch die von mir verwendete Variante, werden Sie als lokale Variablen definiert und mit einem leerwert gefühlt um unbedachte Interpretationen innerhalb der Funktion zu vermeiden.
3.) Nicht sinnvoll: Das Offensichtliche, Variablendeklartion, zu kommentieren.
=> Wie am Anfang beschrieben ist das ein Beispiel und in einem Beispiel gibt es nie zu wenig Erklärung dafür ist es da.
4.) Nicht sinnvoll: Ein Subpräfix "my". Wessen sonst? Man kann dann jede Variable und Funktion mit "my" dekorieren oder es wirft Fragen auf, wenn es unterbleibt. Der interessierende Part, wie die Variable denn nun heißt, wandert weiter und weiter nach hinten mit jedem Präfix.
=> Auch hier nur ein Beispiel für eine Variable. Also kein präfix.
5.) Nicht sinnvoll: Ein v_-Präfix für Variablen. Das ist unergonomisch, weil gerade der Namensbeginn beim Erfassen von geschriebenem Text eine große Rolle spielt.
=> Dadurch wird eindeutig sichtbar, das es eine lokale Variable ist. Das ist für mich essentiel.
6.) Änderst Du den Code hin zu einer Konstanten musst Du alle Vorkommen anpassen.
=> Ich verwende grundsätzlich keine Konstanten.
7.) Wieso nicht _mymsg, bzw. f_mymsg oder richtig skurill, _f_mymsg? Was soll der Unterstrich ausdrücken? Geschützte Systemvfunktion?
=> Ich verwende den Unterstrich am Anfang für Funktionen die nur innerhalb des Scriptes verwenden werden sollten. Das hat den Vorteil, das es klar ersichtlich ist und das man nicht ausversehen binarys überschreibt. Wir reden hier ja über bash wo man nie genau weiß was der Endnutzer auf seinem System installiert hat und meine Scripte sind so konzipiert, das Sie standalone funktionieren oder in andere Skripte inkludiert werden können.
8.) Wozu ist "return 0" am Ende einer Funktion gut?
=> Man hat dadurch eine klare Fehlercode Rückgabe. Man kann damit z.B in Abfragen vorher den Code kontrolliert unterbrechen.
9.) Die Fehlerausgabe für unnötig geschwätzige Ausgaben zu missbrauchen konterkariert auch die Trennung von STDERR und STDOUT. Was, wenn jemand jetzt die wirklichen Fehler in eine Datei umlenken will?
=> Es ist nur ein Beispiel wie man es machen kann. Mir hat es halt geholfen, bash Funktionen wie Funktionen in anderen Programmiersprachen zu verwenden.
10.) Sinnvoller wäre dann schon, wenn man dem User die Entscheidung über eine straffe oder ausladende Ausgabe überlassen will, dann baut man einen Schalter -v ein, und reagiert entsprechend.
=> Ja da hast du Recht. Es ist aber nur ein Beispiel was das einfach nicht behandelt, weil es nicht gefragt war. Ich verwenden bei mir immer die Globale Variable DEBUG und gebe wenn diese gesetzt ist debug infos aus.
user_unknown schrieb: lipkowski.be schrieb: Darf ich ein wenig Codereview üben?
function lbe_testsub
Was immer "lbe" bedeuten soll. Weder Datum, noch Uhrzeit wecken Assoziationen.
{ local v_mystr= #variable deklarieren
local v_mydate= v_mystr='Dies ist ein'
}}}
Nicht sinnvoll: Deklaration und Initialisierung zu trennen. Nicht sinnvoll: Das Offensichtliche, Variablendeklartion, zu kommentieren. Nicht sinnvoll: Ein v_-Präfix für Variablen. Das ist unergonomisch, weil gerade der Namensbeginn beim Erfassen von geschriebenem Text eine große Rolle spielt. Nicht sinnvoll: Ein Subpräfix "my". Wessen sonst? Man kann dann jede Variable und Funktion mit "my" dekorieren oder es wirft Fragen auf, wenn es unterbleibt. Der interessierende Part, wie die Variable denn nun heißt, wandert weiter und weiter nach hinten mit jedem Präfix. Beim Überfliegen ist es manchmal uninteressant, ob ein Aufruf eine Variable oder einen Wert oder eine Prozedur benutzt. Änderst Du den Code hin zu einer Konstanten musst Du alle Vorkommen anpassen. Wieso nicht _mymsg, bzw. f_mymsg oder richtig skurill, _f_mymsg? Was soll der Unterstrich ausdrücken? Geschützte Systemvfunktion?
v_mystr="${v_mystr}"' Test um'
_msg 'Datum und Uhrzeit wird bestimmt'
v_mydate="$(date)"
v_mystr="${v_mystr}""${v_mydate}"
_msg 'Gebe mystr zurueck'
echo "${v_mystr}"
Schließlich:
return 0
}
Wozu ist "return 0" am Ende einer Funktion gut? Und wieso rufst Du
echo 'Die Rückgabe war:'
echo "$(lbe_testsub)"
auf, statt
echo 'Die Rückgabe war:'
lbe_testsub Die Fehlerausgabe für unnötig geschwätzige Ausgaben zu missbrauchen konterkariert auch die Trennung von STDERR und STDOUT. Was, wenn jemand jetzt die wirklichen Fehler in eine Datei umlenken will? Sinnvoller wäre dann schon, wenn man dem User die Entscheidung über eine straffe oder ausladende Ausgabe überlassen will, dann baut man einen Schalter -v ein, und reagiert entsprechend.
|