staging.inyokaproject.org

Danton schrieb:

Ich möchte noch anführen das man mit checkbashisms gut Bashismen erkennen kann dieser Skript gibt diese aus. Dies hat den Vorteil das man /bin/sh –→ /bin/dash nutzen kann, was enorme Geschwindigkeits-Vorteil bringt.

Premature optimization is the root of all evil. Und wann braucht man schon Geschwindigkeit auf der Shell?

Oft sind diese nicht mal Sinning da sie keine Vorteile bringen wie zb. bei function oder source.

Ich nehme an "sinnig" ist gemeint. Wobei mir zu "source" sofort ein Vorteil einfällt. Oder sind die Geschwindigkeitsvorteile oft nicht sinnig? 😉

Welchen Vorteil von source soll es den gegenüber . bieten? Die Dash ist massiv schneller als die Bash und gerade beim starten von großen Shell Programmen wie das booten bei Sysvinit oder configure spart dies ordentlich zeit. Die Bash hat viele Erweiterungen wie Arrays oder C-Like for und while Schleifen aber bei mache bringen keinerlei Vorteile.

Danton schrieb:

Welchen Vorteil von source soll es den gegenüber . bieten?

Ein Anfänger muss immer ermuntert werden den Punkt nicht zu übersehen. Da ist es schneller gleich "source" zu kommunizieren.

Die Dash ist massiv schneller als die Bash

Ohne zu sagen wobei sie schneller ist ist die Aussage sinnlos. Die meisten interaktiven Befehle die ich absetze sind so schnell, dass mir eine Zeitersparnis von 90% nichts bringt. Unterhalb von 300ms werden Unterschiede im Antwortverhalten nicht festgestellt, und das Reaktionsverhalten des Menschen ist so langsam, dass man nichts davon hat, wenn die Antwort stattdessen in 30ms erfolgt.

Der Einspareffekt ist massiv und dennoch unerheblich.

und gerade beim starten von großen Shell Programmen wie das booten bei Sysvinit oder configure spart dies ordentlich zeit.

Welches Shellprogramm bei Sys-V-Init würdest Du als groß bezeichnen?

Die Bash hat viele Erweiterungen wie Arrays oder C-Like for und while Schleifen aber bei mache bringen keinerlei Vorteile.

Es geht ja um einen Bash-Skripting-Guide für Anfänger. Da ist es keine gute Idee die jungen Heißsporne mit dramatischen Aussagen zur Performance zur Selbstkasteiung mit sh-Skripten zu erziehen.

"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity."

Wenn es wirklich bei jemand zu relevanten Performanceproblemen kommt, dann darf man natürlich auch die verwendete Shell als mögliche Ursache untersuchen. Als Allheilmittel taugt der Vorschlag dennoch nicht - eine individuelle Fehlersuche ist dann unverzichtbar.

user unknown schrieb:

Danton schrieb:

Welchen Vorteil von source soll es den gegenüber . bieten?

Ein Anfänger muss immer ermuntert werden den Punkt nicht zu übersehen. Da ist es schneller gleich "source" zu kommunizieren.

Das stimmt nur bringt abseits von der Interaktiven Bediehnung und bei großen Shell-Programmen wenig.

Die Dash ist massiv schneller als die Bash

Ohne zu sagen wobei sie schneller ist ist die Aussage sinnlos. Die meisten interaktiven Befehle die ich absetze sind so schnell, dass mir eine Zeitersparnis von 90% nichts bringt. Unterhalb von 300ms werden Unterschiede im Antwortverhalten nicht festgestellt, und das Reaktionsverhalten des Menschen ist so langsam, dass man nichts davon hat, wenn die Antwort stattdessen in 30ms erfolgt.

Darum ging es mir auch nicht, eher um das Programmieren. Bei der interaktiven Bedienung sind bash und zsh ungeschlagen.

Der Einspareffekt ist massiv und dennoch unerheblich.

und gerade beim starten von großen Shell Programmen wie das booten bei Sysvinit oder configure spart dies ordentlich zeit.

Welches Shellprogramm bei Sys-V-Init würdest Du als groß bezeichnen?

Den Unterschied hat man beim Umstieg von Dash auf /bin/sh gemerkt.

Die Bash hat viele Erweiterungen wie Arrays oder C-Like for und while Schleifen aber bei mache bringen keinerlei Vorteile.

Es geht ja um einen Bash-Skripting-Guide für Anfänger. Da ist es keine gute Idee die jungen Heißsporne mit dramatischen Aussagen zur Performance zur Selbstkasteiung mit sh-Skripten zu erziehen.

Das stimmt zur interaktiven Bedienung macht das Sinn. aber beim Programmieren von Shell-Skripten/Programmen macht dies Sinn, zu mal die Dash in bei Programmieren in 90% der Fälle keine Selbstkasteihung(meintest du Kastrierung?) erfordert.

"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity."

Wenn es wirklich bei jemand zu relevanten Performanceproblemen kommt, dann darf man natürlich auch die verwendete Shell als mögliche Ursache untersuchen. Als Allheilmittel taugt der Vorschlag dennoch nicht - eine individuelle Fehlersuche ist dann unverzichtbar.

Das stimmt, doch wenn ich für etwas Aufwand nehme ich bei der Programmierung von richtigen Shell-Programmen dies gerne ein ( oder auch bei Scripts wenn ich selbst erstellte Funktionen verwende wie zb. d_msg: eine Wrapper Funktion jeweils eine Shell-Ausgabe hat und je nach DE eine Ausgabe in kdialog, zenity oder xmessage(nur eingeschränkt), test_input (test wie groß $1 ist und gibt die passen Fehlermeldung aus err_input_messages=tet:tet aus) oder import: reine Funktion die ähnliches wie die Funktion aus Python liefert und dabei schaut das diese nicht doppelt geladen wird).

Danton schrieb:

user unknown schrieb:

Danton schrieb:

Welchen Vorteil von source soll es den gegenüber . bieten?

Ein Anfänger muss immer ermuntert werden den Punkt nicht zu übersehen. Da ist es schneller gleich "source" zu kommunizieren.

Das stimmt nur bringt abseits von der Interaktiven Bediehnung und bei großen Shell-Programmen wenig.

Ich widersprach der Aussage, dass die Verwendung von 'source' per se unsinnig sei. Ich habe nicht gesagt, dass source generell besser als . sei.

Die Dash ist massiv schneller als die Bash

Ohne zu sagen wobei sie schneller ist ist die Aussage sinnlos. Die meisten interaktiven Befehle die ich absetze sind so schnell, dass mir eine Zeitersparnis von 90% nichts bringt. Unterhalb von 300ms werden Unterschiede im Antwortverhalten nicht festgestellt, und das Reaktionsverhalten des Menschen ist so langsam, dass man nichts davon hat, wenn die Antwort stattdessen in 30ms erfolgt.

Darum ging es mir auch nicht, eher um das Programmieren. Bei der interaktiven Bedienung sind bash und zsh ungeschlagen.

Es geht ja nicht darum, worum es Dir geht, sondern es geht um den Wikiartikel zur Bashprogrammierung. In einem Bash-Einsteigerartikel zu empfehlen alle Bashismen zu entfernen und sie durch Code für die dash zu ersetzen ist Quatsch.

Der Einspareffekt ist massiv und dennoch unerheblich.

und gerade beim starten von großen Shell Programmen wie das booten bei Sysvinit oder configure spart dies ordentlich zeit.

Welches Shellprogramm bei Sys-V-Init würdest Du als groß bezeichnen?

Den Unterschied hat man beim Umstieg von Dash auf /bin/sh gemerkt.

Ich fragte welches Du als groß bezeichnen würdest. Wenn Du keins weißt, dann ist es jetzt zu spät der Frage auszuweichen; Du hättest dann nicht schreiben dürfen

und gerade beim starten von großen Shell Programmen wie das booten bei Sysvinit

Die Bash hat viele Erweiterungen wie Arrays oder C-Like for und while Schleifen aber bei mache bringen keinerlei Vorteile.

Es geht ja um einen Bash-Skripting-Guide für Anfänger. Da ist es keine gute Idee die jungen Heißsporne mit dramatischen Aussagen zur Performance zur Selbstkasteiung mit sh-Skripten zu erziehen.

Das stimmt zur interaktiven Bedienung macht das Sinn. aber beim Programmieren von Shell-Skripten/Programmen macht dies Sinn, zu mal die Dash in bei Programmieren in 90% der Fälle keine Selbstkasteihung(meintest du Kastrierung?) erfordert.

Nein. Ich meine http://de.wikipedia.org/wiki/Kasteiung in der Geschmacksrichtung Selbst~.

Was ist nun Deine Aussage dazu? Dass die Dash in 90% der Fälle - woher hast Du diese Zahl? - keine Selbsteinschränkung verlangt. Nun: Es geht um einen Leitfaden für das Programmieren mit der Bash. Die Dash ist nicht das Thema. Es interessiert schlicht nicht.

Du kannst auch nicht in den Schwimmunterricht mit der Nachricht platzen, dass die meisten Strecken sich besser zu Fuß zurücklegen lassen.

Wenn es wirklich bei jemand zu relevanten Performanceproblemen kommt, dann darf man natürlich auch die verwendete Shell als mögliche Ursache untersuchen. Als Allheilmittel taugt der Vorschlag dennoch nicht - eine individuelle Fehlersuche ist dann unverzichtbar.

Das stimmt, doch wenn ich für etwas Aufwand nehme ich bei der Programmierung von richtigen Shell-Programmen dies gerne ein ( oder auch bei Scripts wenn ich selbst erstellte Funktionen verwende wie zb. d_msg: eine Wrapper Funktion jeweils eine Shell-Ausgabe hat und je nach DE eine Ausgabe in kdialog, zenity oder xmessage(nur eingeschränkt), test_input (test wie groß $1 ist und gibt die passen Fehlermeldung aus err_input_messages=tet:tet aus) oder import: reine Funktion die ähnliches wie die Funktion aus Python liefert und dabei schaut das diese nicht doppelt geladen wird).

Es tut mir leid, aber Du musst diesen Absatz neu schreiben, und dann bitte nochmal lesen vor dem Abschicken. Wofür nimmst Du Aufwand, und was nimmst Du gerne ein? Das ist alles ein Kuddelmudel - kein Satz. Ich glaube auch sonst hat es niemand verstanden.

user unknown schrieb:

Danton schrieb:

user unknown schrieb:

Danton schrieb:

Welchen Vorteil von source soll es den gegenüber . bieten?

Ein Anfänger muss immer ermuntert werden den Punkt nicht zu übersehen. Da ist es schneller gleich "source" zu kommunizieren.

Das stimmt nur bringt abseits von der Interaktiven Bediehnung und bei großen Shell-Programmen wenig.

Ich widersprach der Aussage, dass die Verwendung von 'source' per se unsinnig sei. Ich habe nicht gesagt, dass source generell besser als . sei.

Die Dash ist massiv schneller als die Bash

Ohne zu sagen wobei sie schneller ist ist die Aussage sinnlos. Die meisten interaktiven Befehle die ich absetze sind so schnell, dass mir eine Zeitersparnis von 90% nichts bringt. Unterhalb von 300ms werden Unterschiede im Antwortverhalten nicht festgestellt, und das Reaktionsverhalten des Menschen ist so langsam, dass man nichts davon hat, wenn die Antwort stattdessen in 30ms erfolgt.

Darum ging es mir auch nicht, eher um das Programmieren. Bei der interaktiven Bedienung sind bash und zsh ungeschlagen.

Es geht ja nicht darum, worum es Dir geht, sondern es geht um den Wikiartikel zur Bashprogrammierung. In einem Bash-Einsteigerartikel zu empfehlen alle Bashismen zu entfernen und sie durch Code für die dash zu ersetzen ist Quatsch.

Der Einspareffekt ist massiv und dennoch unerheblich.

und gerade beim starten von großen Shell Programmen wie das booten bei Sysvinit oder configure spart dies ordentlich zeit.

Welches Shellprogramm bei Sys-V-Init würdest Du als groß bezeichnen?

Den Unterschied hat man beim Umstieg von Dash auf /bin/sh gemerkt.

Ich fragte welches Du als groß bezeichnen würdest. Wenn Du keins weißt, dann ist es jetzt zu spät der Frage auszuweichen; Du hättest dann nicht schreiben dürfen

Mir ging es um Sysvinit beim Booten als ganzes.

und gerade beim starten von großen Shell Programmen wie das booten bei Sysvinit

Die Bash hat viele Erweiterungen wie Arrays oder C-Like for und while Schleifen aber bei mache bringen keinerlei Vorteile.

Es geht ja um einen Bash-Skripting-Guide für Anfänger. Da ist es keine gute Idee die jungen Heißsporne mit dramatischen Aussagen zur Performance zur Selbstkasteiung mit sh-Skripten zu erziehen.

Das stimmt zur interaktiven Bedienung macht das Sinn. aber beim Programmieren von Shell-Skripten/Programmen macht dies Sinn, zu mal die Dash in bei Programmieren in 90% der Fälle keine Selbstkasteihung(meintest du Kastrierung?) erfordert.

Nein. Ich meine http://de.wikipedia.org/wiki/Kasteiung in der Geschmacksrichtung Selbst~.

Was ist nun Deine Aussage dazu? Dass die Dash in 90% der Fälle - woher hast Du diese Zahl? - keine Selbsteinschränkung verlangt. Nun: Es geht um einen Leitfaden für das Programmieren mit der Bash. Die Dash ist nicht das Thema. Es interessiert schlicht nicht.

Das stimmt es ist zu absolut, aber die Dash implementiert nur die POSIX Vorgaben für eine Shell die Bash erweiterte diese mit den Möglichkeiten der ksh und teilen der tcsh, da Shell Programme nur bis zu einem gewissen Grad der Komplexität bzw. in Sonderfällen, Sinnvoll sind hatte ich diese Aussage getan.

Du kannst auch nicht in den Schwimmunterricht mit der Nachricht platzen, dass die meisten Strecken sich besser zu Fuß zurücklegen lassen.

Wenn es wirklich bei jemand zu relevanten Performanceproblemen kommt, dann darf man natürlich auch die verwendete Shell als mögliche Ursache untersuchen. Als Allheilmittel taugt der Vorschlag dennoch nicht - eine individuelle Fehlersuche ist dann unverzichtbar.

Das stimmt, doch wenn ich für etwas Aufwand nehme ich bei der Programmierung von richtigen Shell-Programmen dies gerne ein ).

Es tut mir leid, aber Du musst diesen Absatz neu schreiben, und dann bitte nochmal lesen vor dem Abschicken. Wofür nimmst Du Aufwand, und was nimmst Du gerne ein? Das ist alles ein Kuddelmudel - kein Satz. Ich glaube auch sonst hat es niemand verstanden.

Ich wollte sagen du Recht hast da eine individuelle Fehlersuche unverzichtbar ist bei dem was du genannt hattest und wollte sagen das etwas Aufwand beim schreiben von Funktionen die oft verwendet werden oder die etwas komplexer sind Sinn hat. Wie zb. bei diesen die ich genannt hatte "oder auch bei kleineren Shell Scripten wenn ich selbst erstellte Funktionen verwende wie zb. d_msg: eine Wrapper Funktion die jeweils eine Shell-Ausgabe hat und je nach DE eine Ausgabe in kdialog, zenity oder xmessage(nur eingeschränkt) hat, test_input (testet wie groß $1 ist und gibt die passende Fehlermeldung aus err_input_messages=tet:tet aus) oder import: eine Funktion die ähnlicheswie die Funktion aus Python ist und zusätzlich noch den passen Rückgabe Status liefert ob die Datei schon geladen ist oder nicht und diese auch dann nicht lädt wenn diese schon geladen wird).

Ich würde den Artikel gerne noch um einen Abschnitt zum Thema Fehlersuche erweitern, insbesondere ein Hinweis auf Debugging bzw. Backtrace mit set -x.

Ist das sinnvoll? Oder hat jemand selber noch Vorschläge zur Fehlersuche? Ihr habt euch soviel Mühe mit dem Artikel gegeben, dass ich jetzt nicht einfach darin rumschreiben möchte.

Benachrichtigt über Verbesserungen habe ich manche davon wieder zurückverbessert.

Fremdwörter sind Wörter fremden Ursprungs, die soweit eingebürgert sind, dass sie wie deutsche Wörter behandelt werden. Insbesondere werden sie deutschen Regeln der Beugung und der Zusammensetzung unterworfen. So heißt es ein Stringvergleich, nicht ein String-Vergleich. Im Deutschen werden Vorsilben nicht mit Bindestrich abgetrennt, es heißt also ungequotet, nicht unge-"quotet" oder un-ge-"quotet".

Wer Zeichenketten unter einem Wust an Markup beerdigt (Klammern, Anführungsstrichen, Kursiv und fett) weil ihm der Ausdruck zu schrill erscheint, der sollte ihn vielleicht meiden.

Wenn man im Text die Begriffe String und Zeichenkette in loser Folge abwechselt liest sich der Text etwas netter und der User lernt en passant, dass das eine das andere bedeutet.

Nachdem meine Änderung teilweise rückgängig gemacht wurde, wüsste ich das jetzt doch gerne etwas genauer: was hat die Lesbarkeit des Backticks mit dem Zeichensatz zu tun?

WinXP to Edgy schrieb:

was hat die Lesbarkeit des Backticks mit dem Zeichensatz zu tun?

Gegenfrage: Was ist ein Font? Eine Saucengrundlage oder eine Schriftart?

Innerhalb der EDV eine Schriftart, soweit ich dies hier richtig verstanden habe. Weiterhin wird der Begriff "Schriftart" eher in der klassischen Drucktechnik verwendet, während "Font" in der EDV seit Aufkommen der grafischen Oberflächen so geläufig ist, dass sicher keiner ernsthaft auf die Idee kommt, es mit einer Saucengrundlage zu verwechseln.

Wozu aber der zusätzliche Verweis auf den Zeichensatz gut sein soll, hast du mir noch nicht erklärt. Ich halte den Begriff in diesem Kontext nach wie vor für sachlich falsch.

Öffne mal ein Terminal und gib dort ein

setxkbmap us

Die nachfolgenden Eingaben werden mit dem gleichen Font dargestelt, allerdings ist dann ein englischer Zeichensatz eingestellt. Wenn ich nun gemein wäre, würde ich behaupten, dass der deutsche Zeichensatz wieder mit setxkbmap gr wie "german" eingestellt wird, aber das ist nicht wahr, damit erhält man den griechischen Zeichensatzt, mit dem es sehr schwierig wird, irgendeinen Tastaturbefehl zu erzeugen. 😉

Bevor man das testet sollte man midestens 1 mal setxkbmap de ausgeführt haben, damit man diesen Befehl mit der Pfeiltaste wiederholen kann.

Hallo,

Schriftart ist der richtige Ausdruck für's Wiki, weil es das richtige deutsche Wort ist (und nicht Font). Zeichensatz ist in der Tat nicht korrekt, weil der nichts mit der Darstellung an sich zu tun hat.

So, und jetzt gehe ich einen Fond für den Sonntagsbraten ansetzen 😉

Gruß, noisefloor

Man könnte ja "Schriftart (Font)" schreiben, damit diejenigen, die kein oder kaum Englisch können ein wenig vorbereitet sind, wenn sie in nichtlokalisierten Programmen dem häufig verwendeten "Font" begegnen.

Hallo wxpte, danke für deinen Beitrag im Wiki. Könntest du bitte kurz hier erklären, warum find in einem Skript gefährlich ist (davon abgesehen muss man natürlich wissen, was man tut, wenn man find verwendet) - aber im Gegensatz zu ls halte ich find doch für sehr präzise.

//edited: auch via PN, da hier in der Historie auf Anhieb nicht gefunden....