staging.inyokaproject.org

Yanneck schrieb:

Ich möchte mich auch für die Shebang aussprechen, weil es sich auf die erste Zeile (first line) bezieht, die geschrieben wird. Des Weiteren ist # auch die Raute. Und das She meint ja das Doppelkreuz.

Das Holz, der Tisch, ⇒ Der Holztisch, das Tischholz.

Im Deutschen richtet sich das Geschlecht bei zusammengesetzten Substantiven auf den letzen Teil - das She ist also völlig unerheblich.

Noch unerheblicher ist nur "die erste Zeile" - ist das wirklich Dein Argument, oder habe ich das mißverstanden?

Das Ausrufezeichen steht für den Shebang, oder demnach das Shebang, aber das Geschlecht der dt. Übersetzung ist keine zwingende Regel zur Bestimmung des zu verwendenden Geschlechts; kann es auch nicht sein, denn für manche Worte gibt es mehrere Übersetzungen mit divergierendem Geschlecht.

Beispiel: Der Betrieb, Das Unternehmen, die Firma.

Im Wikiforum habe ich übrigens auch eine Diskussion eröffnet, weil es da ja eigentlich hingehört. http://forum.ubuntuusers.de/topic/baustelle-shebang/

Da wir aber oft mit dem Shebang zu tun haben, und hier die Experten sitzen, fand ich es nötig Euch zur Diskussion einzulagen.

Nicht so gut war die Idee den zweiten Thread für die Diskussion - nicht nur für die Einladung.

Ich möchte aber bitten die Diskussion ab sofort dort fortzuführen.

user unknown schrieb:

Yanneck schrieb:

Ich möchte mich auch für die Shebang aussprechen, weil es sich auf die erste Zeile (first line) bezieht, die geschrieben wird. Des Weiteren ist # auch die Raute. Und das She meint ja das Doppelkreuz.

Das Holz, der Tisch, ⇒ Der Holztisch, das Tischholz.

Im Deutschen richtet sich das Geschlecht bei zusammengesetzten Substantiven auf den letzen Teil - das She ist also völlig unerheblich.

Noch unerheblicher ist nur "die erste Zeile" - ist das wirklich Dein Argument, oder habe ich das mißverstanden?

Das Ausrufezeichen steht für den Shebang, oder demnach das Shebang, aber das Geschlecht der dt. Übersetzung ist keine zwingende Regel zur Bestimmung des zu verwendenden Geschlechts; kann es auch nicht sein, denn für manche Worte gibt es mehrere Übersetzungen mit divergierendem Geschlecht.

Beispiel: Der Betrieb, Das Unternehmen, die Firma.

So genau habe ich mir das nicht überlegt, war eigentlich mehr ein Bauchgefühl. Zumal es sich aber um ein Fachwort handelt, könnte (oder müsste?) man es auch durch Anführungszeichen hervorheben. Oder einfach eindeutschen: Schiebäng.

Das Ausrufezeichen

Habe nun mal den Fremdwörter-Duden bemüht, mir was Englisches beizubringen, und fand

HTML die [...]

wobei sich der Artikel also in der Tat auf den letzten Teil bezieht. Insofern also vielleicht doch das Shebang.

user unknown schrieb:

rklm schrieb:

user unknown schrieb:

Meine Faustregeln sähen allerdings anders aus:

Ich denke, es ist auch eine Seite für Leute, die anfangen Shell-Skripte zu schreiben, oder?

In erster Linie ist sie zur Arbeitserleichterung im S&P-Forum, wo es mühsam ist, das wieder und wieder zu erklären.

Und es soll nicht zu lang werden, damit es gelesen wird.

Dann hat der Artikel aber den falschen Titel; so allgemein, wie er ist, suggeriert er eine allgemeine Erklärung. Es müsste eher so etwas wie "Fehlerbehebung bei Startschwierigkeiten von Skripten" sein - und man sollte dann im Laufe der Zeit Fehler und Lösungen hinzufügen, die vielleicht nicht mit Shebang zu tun haben.

Bis dann

robert

rklm schrieb:

In erster Linie ist sie zur Arbeitserleichterung im S&P-Forum, wo es mühsam ist, das wieder und wieder zu erklären.

Und es soll nicht zu lang werden, damit es gelesen wird.

Dann hat der Artikel aber den falschen Titel; so allgemein, wie er ist, suggeriert er eine allgemeine Erklärung. Es müsste eher so etwas wie "Fehlerbehebung bei Startschwierigkeiten von Skripten" sein -

Der Name soll kurz und einprägsam sein. Du schaust das Problem m.E. von der falschen Seite an, so als lande jemand aus mysteriösen Gründen beim Artikel, versucht dann aus dem Titel den Inhalt zu deduzieren, und liest dann etwas was die Erwartungen, die der Titel weckte, nicht erfüllt.

Aber so soll es nicht funktionieren. Der Titel soll keine Erwartungen wecken, sondern ein Anker sein, den man leicht verlinken kann - man schreibt 'Shebang', klickt den Wikibutton, und fertig. Und aus dem Kontext, einem Supportthread, ergibt sich der Inhalt.

und man sollte dann im Laufe der Zeit Fehler und Lösungen hinzufügen, die vielleicht nicht mit Shebang zu tun haben.

❓

user unknown schrieb:

rklm schrieb:

In erster Linie ist sie zur Arbeitserleichterung im S&P-Forum, wo es mühsam ist, das wieder und wieder zu erklären.

Und es soll nicht zu lang werden, damit es gelesen wird.

Dann hat der Artikel aber den falschen Titel; so allgemein, wie er ist, suggeriert er eine allgemeine Erklärung. Es müsste eher so etwas wie "Fehlerbehebung bei Startschwierigkeiten von Skripten" sein -

Der Name soll kurz und einprägsam sein. Du schaust das Problem m.E. von der falschen Seite an, so als lande jemand aus mysteriösen Gründen beim Artikel, versucht dann aus dem Titel den Inhalt zu deduzieren, und liest dann etwas was die Erwartungen, die der Titel weckte, nicht erfüllt.

Aber so soll es nicht funktionieren. Der Titel soll keine Erwartungen wecken, sondern ein Anker sein, den man leicht verlinken kann - man schreibt 'Shebang', klickt den Wikibutton, und fertig. Und aus dem Kontext, einem Supportthread, ergibt sich der Inhalt.

Und was machen Leute, die im Wiki (oder sogar per Suchmaschine) suchen und den Artikel finden?

Ciao

robert

rklm schrieb:

Und was machen Leute, die im Wiki (oder sogar per Suchmaschine) suchen und den Artikel finden?

Ich bin geneigt zu sagen, es sei mir wurscht. Aber auch die lesen ja die Einleitung, und bekommen da gesagt, worum es geht.

Zweitens sollen sie ja auch nur zutreffendes aus dem Artikel erfahren, und drittens steht auch alles wichtige drin, wenn auch ungewöhnlich gewichtet und vielleicht sortiert, aber wie gesagt - die Einleitung erklärt wieso.

Oder welche Inhalte werden den Wikistreunern und ~suchern fehlen?

Der Artikel kann von mir aus scharf geschaltet werden.

2 Einträge konnte ich nicht einlösen, und zwar zu Blanks im Shebang - da weiß ich nicht, was alles gestattet ist, und was nicht.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

#!/bork
# !/bork
# ! /bork
#! /bork
#! / bork
# ! / bork
 #!/bork
 # !/bork
 # ! /bork
 #! /bork
 #! / bork
 # ! / bork

Im S&P-Bereich gab es dazu eine Nachfrage, die beim Versuch die beiden Threads zu mergen wohl über den Jordan gingen.

2.: mehrere Parameter trennen: Da gibt es wohl Unterschiede zwischen Linux und BSD - Details habe ich nicht begriffen, auch aus S&P, wo man jetzt auch nicht mehr nachfragen kann, da geschlossen.

Hi! user unknown schrieb:

Der Artikel kann von mir aus scharf geschaltet werden.

Wenn er denn den Wikikriterien entspräche... Schau doch bitte noch mal in Wiki/Referenz, da auch Verständlichkeit und Formulierung und überarbeite deine Formulierungen, und überprüfe auch noch mal die Wiki/Syntax, Dateien und Verzeichnisse werden z.B. fett gesetzt, "Zitate" aus Skripten etc. hingegen in monotype. Smilies brachen wir im Wiki auch nicht, und die Abteilung tl;dr kommt so garantiert nicht ins Wiki (der Imperativ von lesen ist übrigens "lies" , gegenfalls kann du "les'" im Zusammenhang mit "lese er das Wiki" als Ansprache der dritten Person verwenden, so er denn Friedrich der Große, o.ä. sei 😉).

2 Einträge konnte ich nicht einlösen, und zwar zu Blanks im Shebang - da weiß ich nicht, was alles gestattet ist, und was nicht.

1 2 3 4 5 6 7 8 9 10 11 12

#!/bork # !/bork # ! /bork #! /bork #! / bork # ! / bork #!/bork # !/bork # ! /bork #! /bork #! / bork # ! / bork

Im S&P-Bereich gab es dazu eine Nachfrage, die beim Versuch die beiden Threads zu mergen wohl über den Jordan gingen.

Sollte man da nicht einfach darauf hinweisen, dass man auf blanks verzichten solle? Scheint mir einfacher, als auszuklambüserne, was wo geht, und wo nicht, und in welchem Zusammenhang ja und nein und vielleicht, wenn.... Dein Anspruch war doch, Klarheit zu schaffen, nicht zu verwirren, wenn ich leise daran erinnern darf...

(Gilt übrigens auch für ./splash, mag ja nett gemeint sein, verwirrt aber auch mehr als dass es hilft...)

2.: mehrere Parameter trennen: Da gibt es wohl Unterschiede zwischen Linux und BSD - Details habe ich nicht begriffen, auch aus S&P, wo man jetzt auch nicht mehr nachfragen kann, da geschlossen.

Was aber für einen Ubuntuwikibeitrag für Anfänger imho eher unerheblich sein dürfte.

so long
hank

Heinrich Schwietering schrieb:

Hi! user unknown schrieb:

Der Artikel kann von mir aus scharf geschaltet werden.

Wenn er denn den Wikikriterien entspräche... Schau doch bitte noch mal in Wiki/Referenz,

Hab ich gemacht

da auch Verständlichkeit und Habe ich gemacht.

Formulierung Habe ich doch schon ersetzt - wenn Du was konkretes sagen willst - wieso tust Du's nicht? Willst Du ein Quiz spielen?

und überarbeite deine Formulierungen, und überprüfe auch noch mal die Wiki/Syntax, Dateien und Verzeichnisse werden z.B. fett gesetzt,

Nein. Fett setzt man etwas, das man hervorheben will, um die Aufmerksamkeit zu binden. Das ist in Büchern oft ein Pfad, wenn es ein Installationspfad ist, den der Leser sich merken soll, oder den er nachschlagen will. Hier tauchen dauernd Pfade auf, weil sie das Thema sind, aber der jeweilige Pfad ist gerade nicht wichtig, sondern halt irgendein Pfad, der nicht hervorgehoben gehört. Das lenkt nur ab, wenn man da jedes 3. Wort fett macht, und ist kontraindiziert.

"Zitate" aus Skripten etc. hingegen in monotype.

Du meinst mit dem Kursivbutton? Hab' ich gemacht.

Smilies brachen wir im Wiki auch nicht, und die Abteilung tl;dr kommt so garantiert nicht ins Wiki (der Imperativ von lesen ist übrigens "lies" ,

Stirb dumm!

habe ich weggemacht. Dann halt nicht.

gegenfalls kann du "les'" im Zusammenhang mit "lese er das Wiki" als Ansprache der dritten Person verwenden, so er denn Friedrich der Große, o.ä. sei 😉).

Fiel zum Opfer.

2 Einträge konnte ich nicht einlösen, und zwar zu Blanks im Shebang - da weiß ich nicht, was alles gestattet ist, und was nicht.

1 2 3 4 5 6 7 8 9 10 11 12

#!/bork # !/bork # ! /bork #! /bork #! / bork # ! / bork #!/bork # !/bork # ! /bork #! /bork #! / bork # ! / bork

Im S&P-Bereich gab es dazu eine Nachfrage, die beim Versuch die beiden Threads zu mergen wohl über den Jordan gingen.

Gingen wohl doch nicht über den Jordan, sondern sind auf Seite 2.

Sollte man da nicht einfach darauf hinweisen, dass man auf blanks verzichten solle?

Nein - wieso? Wenn man etwas nicht verstanden hat, dann soll man es nicht auch noch zur Norm erheben und den Leuten mit Erklärungen kommen.

Scheint mir einfacher, als auszuklambüserne, was wo geht, und wo nicht, und in welchem Zusammenhang ja und nein und vielleicht, wenn.... Dein Anspruch war doch, Klarheit zu schaffen, nicht zu verwirren, wenn ich leise daran erinnern darf...

Du darfst. Nur ist es gar nicht mein Anliegen da viel zu schreiben - wie gesagt, es war eine Idee von jmd. Drittem, dass man dazu noch was schreiben könnte. Man kann es auch zum Beispiel lassen.

(Gilt übrigens auch für ./splash, mag ja nett gemeint sein, verwirrt aber auch mehr als dass es hilft...)

Es hilft insofern als es verwirrt.

2.: mehrere Parameter trennen: Da gibt es wohl Unterschiede zwischen Linux und BSD - Details habe ich nicht begriffen, auch aus S&P, wo man jetzt auch nicht mehr nachfragen kann, da geschlossen.

Was aber für einen Ubuntuwikibeitrag für Anfänger imho eher unerheblich sein dürfte.

War auch eine externe Idee, und ich habe beide nochmal angesprochen, um denen, die mit ihren konstruktiven Anregungen geholfen haben, transparent zu machen, dass es jetzt, so wie es ist, nicht im Artikel ist.

Hallo,

Nein. Fett setzt man etwas, das man hervorheben will, um die Aufmerksamkeit zu binden.

Wenn du Wiki/Syntax in Frage stellst, dann

• ist das hier der falsche Ort

• solltest du das tun, _bevor_ du eine Artikel schreibst...

Zum Artikel: kursiv wird nicht syntax-konform verwendet. Ansonsten lese ich den Artikel heute Abend mal in Ruhe durch.

Gruß, noisefloor

Hi!

user unknown schrieb:

Wenn er denn den Wikikriterien entspräche... Schau doch bitte noch mal in Wiki/Referenz,

Hab ich gemacht

Oh, Entschuldigung, wir haben es ja mit einem Sophisten zu tun. Also: Nicht nur reinschauen, auch danach handeln...

wenn Du was konkretes sagen willst - wieso tust Du's nicht? Willst Du ein Quiz spielen?

Ich möchte nicht den ganzen Artikel hier zitieren. Der Stil ist imho nicht der, den wir im Wiki pflegen; wenn du in der Art in deinem Blog schreiben möchtest, tu das... Es sind ganze Textpassagen darin, die komplett überflüssig sind, da beißt die Maus keinen Faden ab, und die Debütantin schaut in die Röhre (vielleicht lag sie auch nur zulange darunter, um möglichst knusprig auf dem Ball zu erscheinen, und hat dabei einen Sonnenstich bekommen?).

Ganz zu Anfang schon:

Bei Shellskripten kommt es sporadisch zu Fehlern in Zusammenhang mit dem Shebang und symbolischen Links.

Du schreibst selber, dass das sporadisch so ist; du schreibst nicht, wie der Fehler sich äußert, und wie sich dem Anfänger, für den das ja deiner Angabe nach sein soll, der Zusammenhang zwischen der Shebang und dem symbolischen Link, den /bin/sh darstellt, erschließen soll, bleibt auch im Dunkeln. Er wird kaum unter "shebang" im Wiki oder sonstwo suchen... (btw: Unter aktuellen Ubuntu-Versionen ist der sh-link übrigens immer auf dash, wenn man da nicht händisch beigeht, und den link z.B. auf bash umbiegt, also auch da schon einer "hausgemachte" Verwirrung neben dem splash.)

Noch ein Beispiel aus dem Artikel, da du ja Konkretes haben wolltest:

So, das hat die Sache etwas subtiler gemacht, und wer sich davon angeregt fühlt, der schreibt in die eigenen Scripte auch noch Weichen hinein, die unterscheiden, ob das Script mit vollem Pfad oder relativem Pfad aufgerufen wurde.

Ah, danke für die wertvolle Information; Weichen kannte ich als Anfänger bei Schienen (Straßenbahn etc.) vielleicht noch aus meinen Lautsprecherboxen. Es gibt keinerlei Bezüge zu anderen Artikeln, die ggf. erklären, was ein z.B. ein absoluter, was ein relativer Pfad ist (ergo: es fehlt der Wissensblock), geschweige denn, was eine Weiche ist und wie sie in diesem Zusammenhang gesetzt wird. Also auch das so wie es jetzt dort steht imho insgesamt überflüssig, weil nicht erhellend, sondern weiter verwirrend.

Nein. Fett setzt man etwas, das man hervorheben will, um die Aufmerksamkeit zu binden. Das ist in Büchern oft ein Pfad, wenn es ein Installationspfad ist, den der Leser sich merken soll, oder den er nachschlagen will. Hier tauchen dauernd Pfade auf, weil sie das Thema sind, aber der jeweilige Pfad ist gerade nicht wichtig, sondern halt irgendein Pfad, der nicht hervorgehoben gehört. Das lenkt nur ab, wenn man da jedes 3. Wort fett macht, und ist kontraindiziert.

Schau doch bitte wirklich mal in Wiki/Syntax... (oh, entschuldige: halte dich bitte an das, was dort steht).

"Zitate" aus Skripten etc. hingegen in monotype.

Du meinst mit dem Kursivbutton? Hab' ich gemacht.

Nein, ich meine mit dem Monotype-Button, siehe Wiki/Syntax

Sollte man da nicht einfach darauf hinweisen, dass man auf blanks verzichten solle?

Nein - wieso? Wenn man etwas nicht verstanden hat, dann soll man es nicht auch noch zur Norm erheben und den Leuten mit Erklärungen kommen.

Hast du schon mal von einem Problem gehört, dass entstand, weil in einer Shebang zu wenige Leerzeichen verwendet wurden? Solange keine Option verwendet wird, fährst du ja wohl ohne Leerzeichen am besten...Scheint mir immer noch einfacher, als auszuklambüsern, was wo geht, und wo nicht, und in welchem Zusammenhang ja und nein und vielleicht, wenn....

Dein Anspruch war doch, Klarheit zu schaffen, nicht zu verwirren, wenn ich leise daran erinnern darf...

Du darfst. Nur ist es gar nicht mein Anliegen da viel zu schreiben - wie gesagt, es war eine Idee von jmd. Drittem, dass man dazu noch was schreiben könnte. Man kann es auch zum Beispiel lassen.

Danke, und: volle Zustimmung zum Lassen, es scheint - mir zumindest - nicht relevant zu sein.

(Gilt übrigens auch für ./splash, mag ja nett gemeint sein, verwirrt aber auch mehr als dass es hilft...)

Es hilft insofern als es verwirrt.

Ah ja, Verwirren hilft also dem hilfesuchenden Anfänger. Interessanter Ansatz.

so long
hank

Hi!

Oooops, die Debütantin hat sich im Ball geirrt! Oder ist zumindestens inkognito schon mal aufgetreten: Die Shebang. Naja, kann ja mal vorkommen, ist ja auch aufregend, so ein Debüt 😉. Schade um das Flitter, Make-up und den ganzen Aufzug...(the whole shebang, wie der Ami zu sagen pfegt 😀 )

Falls da was fehlt, sollte es dort wikikonform, ich wiederhole: wikikonform, eingebaut werden, sinnvollerweise in die Box mit dem Hinweis auf den englischen Beitrag zu besagtem Thema. Mehr ist imho dazu nicht nötig, kann auch dorthin aus dem S&P-Forum gut verlinkt werden.

(OT: die oben zitierte Baustelle ist seit April überfällig, wäre doch ein Anlass, das Ganze dort zu Ende zu bringen?)

so long
hank

Heinrich Schwietering schrieb:

user unknown schrieb:

Wenn er denn den Wikikriterien entspräche... Schau doch bitte noch mal in Wiki/Referenz,

Hab ich gemacht

Oh, Entschuldigung, wir haben es ja mit einem Sophisten zu tun. Also: Nicht nur reinschauen, auch danach handeln...

Du musst aufpassen, dass wenn Du das zu oft wiederholst, dein Gesicht dabei einfrieren kann, und Du tagein, tagaus nur noch "Sophist" sagen kannst. ☺

wenn Du was konkretes sagen willst - wieso tust Du's nicht? Willst Du ein Quiz spielen?

Ich möchte nicht den ganzen Artikel hier zitieren. Der Stil ist imho nicht der, den wir im Wiki pflegen;

Ich habe bereits erklärt, dass es einen Stil nur geben kann, um bestimmte Ziele zu erreichen, worauf Du nicht eingehst. Das nennt man einen Ignoranten. Wenn ich einen Dateipfad hervorheben will, dann würde ich das machen wie im Wiki festgelegt - ich will aber keinen Dateipfad hervorheben.

Du unterliegst einem Irrtum wenn Du meinst, dass man Dateipfade immer hervorheben muss. Eine solche Regelung wäre eine bürokratischer Zwangsmechanismus, ein Fetischdenken, so wie ja auch viele Leute glauben, dass sie immer hinter Uhu und Tempo ein Trademarkzeichen einfügen müssen, um nicht vor den Kadi gezerrt zu werden.

Aber das ist natürlich Quatsch. Die Dateinamen sollen gerade nicht hervorgehoben werden, so wie auch splash nichts spezielles bedeuten soll, und dass es nichts bekanntes sein soll wird durch ein unbekanntes natürlich dargestellt.

wenn du in der Art in deinem Blog schreiben möchtest, tu das... Es sind ganze Textpassagen darin, die komplett überflüssig sind, ... Ganz zu Anfang schon:

Bei Shellskripten kommt es sporadisch zu Fehlern in Zusammenhang mit dem Shebang und symbolischen Links.

Du schreibst selber, dass das sporadisch so ist; du schreibst nicht, wie der Fehler sich äußert, und wie sich dem Anfänger, für den das ja deiner Angabe nach sein soll, der Zusammenhang zwischen der Shebang und dem symbolischen Link, den /bin/sh darstellt, erschließen soll, bleibt auch im Dunkeln.

Bislang ist es Dein Geheimnis, wieso etwas, was ich nicht schreibe, eine überflüssige Textpassage ist.

Er wird kaum unter "shebang" im Wiki oder sonstwo suchen... (btw: Unter aktuellen Ubuntu-Versionen ist der sh-link übrigens immer auf dash, wenn man da nicht händisch beigeht, und den link auf bash umbiegt, also auch da schon einer "hausgemachte" Verwirrung neben dem splash.)

Und bis zu welcher LTS-Version und welcher Serverversion war die bash Standard?

Noch ein Beispiel aus dem Artikel, da du ja Konkretes haben wolltest:

So, das hat die Sache etwas subtiler gemacht, und wer sich davon angeregt fühlt, der schreibt in die eigenen Scripte auch noch Weichen hinein, die unterscheiden, ob das Script mit vollem Pfad oder relativem Pfad aufgerufen wurde.

Ah, danke für die wertvolle Information; Weichen kannte ich als Anfänger bei Schienen (Straßenbahn etc.) vielleicht noch aus meinen Lautsprecherboxen. Es gibt keinerlei Bezüge zu anderen Artikeln, die ggf. erklären, was ein z.B. ein absoluter, was ein relativer Pfad ist (ergo: es fehlt der Wissensblock), geschweige denn, was eine Weiche ist und wie sie in diesem Zusammenhang gesetzt wird. Also auch das so wie es jetzt dort steht imho insgesamt überflüssig, weil nicht erhellend, sondern weiter verwirrend.

Zeig mir den Weichenartikel, dann zeig ich Dir einen Wissensblock.

Nein - Dein Wissen ist vollkommen ausreichend um den Satz zu verstehen - man kann sich auch künstlich doof stellen.

Nein. Fett setzt man etwas, das man hervorheben will, um die Aufmerksamkeit zu binden. Das ist in Büchern oft ein Pfad, wenn es ein Installationspfad ist, den der Leser sich merken soll, oder den er nachschlagen will. Hier tauchen dauernd Pfade auf, weil sie das Thema sind, aber der jeweilige Pfad ist gerade nicht wichtig, sondern halt irgendein Pfad, der nicht hervorgehoben gehört. Das lenkt nur ab, wenn man da jedes 3. Wort fett macht, und ist kontraindiziert.

Schau doch bitte wirklich mal in Wiki/Syntax... (oh, entschuldige: halte dich bitte an das, was dort steht).

Wenn Du auf meine Argumente nicht eingehst, dann brauchst Du mit mir nicht zu diskutieren.

"Zitate" aus Skripten etc. hingegen in monotype.

Du meinst mit dem Kursivbutton? Hab' ich gemacht.

Nein, ich meine mit dem Monotype-Button, siehe Wiki/Syntax

Ach - ein 'a' für 'monotype'? Das ist geschickt. Fehlt leider ein Wissensblock vor dem 'a'. Im Editfeld des Forums gibt es den Button auch nicht, daher kenn ich ihn nicht, weil ich nur sporadisch im Wiki editiere, und so unergonomisch, wie der Button ist, kommt man nicht drauf, er könne für monotype stehen.

Sollte man da nicht einfach darauf hinweisen, dass man auf blanks verzichten solle?

Nein - wieso? Wenn man etwas nicht verstanden hat, dann soll man es nicht auch noch zur Norm erheben und den Leuten mit Erklärungen kommen.

Hast du schon mal von einem Problem gehört, dass entstand, weil in einer Shebang zu wenige Leerzeichen verwendet wurden? Solange keine Option verwendet wird, fährst du ja wohl ohne Leerzeichen am besten...Scheint mir immer noch einfacher, als auszuklambüsern, was wo geht, und wo nicht, und in welchem Zusammenhang ja und nein und vielleicht, wenn....

Bitte lies den Thread nochmal von vorne, wenn Du nicht mitbekommen hast, wie es zu den Blanks kam. Ich wiederhole nicht alles 3 mal für Dich.

(Gilt übrigens auch für ./splash, mag ja nett gemeint sein, verwirrt aber auch mehr als dass es hilft...)

Es hilft insofern als es verwirrt.

Ah ja, Verwirren hilft also dem hilfesuchenden Anfänger. Interessanter Ansatz.

Ja. Kannst Du Dir das nicht vorstellen? 😉