Hallo
juppes!Lilypond läuft wieder etwas runder, was die ominösen Fehlermeldungen nach Cmd-R betrifft. Jetzt sind es wieder wie zu Anfang unserer "Unterhaltung" sieben Mal, bis es meckert. Das ist ja schon mal was!
Na ja, streng genommen ist das nichts
Idealerweise sollte Lily von sich aus fehlerfrei laufen, was es auf den meisten Systemen ja auch tut! Lily ist für den eigenständigen Programmbetrieb konzipiert (bringt eigenes GS und Python mit), weswegen die ganzen Einstellungen, die wir gerade für dich anpassen/angepasst haben, nur Auswirkungen auf den Betrieb im Terminal und das Zusammenspiel mit externen Editoren haben dürften. Ich kann nur vermuten, dass Lily in der Not systemweite Einstellungen zu Rate zieht, um irgendwo überhaupt weiter zu kommen. Das Hauptproblem ist einfach, dass wir als Mac-User nach wie vor eine Randgruppe sind und die vorkompilierten Binaries eben nicht so umfassend getestet sein können wie für native Unix-/Linux- oder Windows-Systeme. Womöglich liegt es aber auch an uns selbst, weil wir vielleicht weniger Feedback an die Entwickler liefern … In deinem Fall könnte es simplerweise an der PPC-Architektur (wie auch bei GS für Mac OS X) liegen! Ich hab halt ’nen Intel-basierten Mac und kann solche Phänomene wie bei dir nicht 1:1 nachstellen. Die stabilen Versionen von Lily habe ich bei mir noch nie abk…en sehen
(Muss aber auch dazu sagen, dass ich den Lily-Editor resp. LilyPond als App – außer für dein aktuelles Problem – nie benutze.)
Terminal und TeXShop machen auch weiterhin keinerlei Probleme.
Dann ist es gut so – bleib dabei! In der englischen Liste sind Diskussionen zu beobachten, „LilyPad“ komplett zu überholen, um einen brauchbaren Editor gleich mitzuliefern; der Tenor ist allerdings, in erster Linie Lily selbst weiterzuentwickeln, und aufgrund wesentlich besserer, externer Editoren (Frescobaldi, jEdit mit LilypondTool, Canorus etc.) ein eigenes benutzerfreundlicheres GUI zurückzustellen. Das finde ich persönlich gar nicht schlimm, aber es erschwert dem Einsteiger sehr den Zugang zu Lily – gerade wenn es „die erste Begegnung“ mit Software auf Texteingabebasis ist. Die Entwickler wissen darum und wollen den Einstieg dadurch erleichtern, aber sie wissen auch, dass man das Rad (in Sachen Editor) nicht neu erfinden muss. Ich erwarte von Lily auch nur eine gute Notensatz-Engine – auf welche Art und Weise ich Lily mit Code füttere, darf ruhig mir selbst überlassen bleiben
Vielleicht liegt es ja gerade am spartanischen „LilyPad“, dass man sich gezwungenermaßen nach einem nützlichen Tool umsehen muss … Aber dann sollte man im Gegenzug insbesondere Einsteigern entgegenkommen und auf alternative Editoren schon auf
lilypond.org hinweisen!
Lilypond sucht jetzt tatsächlich auch nicht nur bei sich nach Ghostscript
Um das noch einmal abzugrenzen: es ist
GhostScript in Lily, das in diesen Pfaden sucht. Lily produziert mit Hilfe von GhostScript PS-Code, welchen GS nach PDF konvertiert. Lily hat also, nachdem es die Eingabedatei postscriptgerecht bearbeitet hat, nix mehr zu melden.
Sind die Zeilen per Zeilenumbruch getrennt?
Ist das von Bedeutung und wenn ja, wieso? Ich hatte an mindestens einer Stelle einen Zeilenumbruch.
Ja, das ist sogar ziemlich von Bedeutung. Ein
Leerzeichen ist ganz lapidar ein
typographisches Symbol. Leerzeichen werden in Programmabläufen höchstens einmal ausgewertet: tauchen bspw. 4 Leerzeichen hintereinander auf, wird das erste berücksichtigt und die verbleibenden 3 ignoriert.
Ein
Zeilenumbruch – also das Betätigen der Enter-/Eingabetaste – ist ein
Steuerzeichen. Es bedeutet: hier an dieser Stelle ist Schluss, mache fertig und warte auf Neues. Ein Leerzeichen macht
nicht Schluss, selbst wenn am Ende einer Textzeile der optische Effekt eines Zeilenumbruchs einträte. Der „optische Effekt“ der Enter-Taste ist natürlich ein Zeilenumbruch, aber wie sollte man ihn sonst erkennen? Fakt ist: Befehl eingeben, Enter drücken und den Befehl somit abschließen und ausführen.
In der Regel schreibt man jeden auszuführenden Befehl in eine neue Zeile (durch „Enter“ erzeugt). Die Anweisungen werden dann zeilenweise von oben nach unten abgearbeitet. Wenn man nun in
einer Zeile zwei Befehle hintereinander notiert, die nur durch Leerzeichen getrennt sind, werden diese als
eine Eingabe interpretiert. Dies führt meist zu Fehlermeldungen bzw. ungewollter oder gar keiner Verarbeitung. Die Kombination zweier Befehle in einer Zeile ist durch doppeltes kaufmännisches Und (
&&) möglich. Die beiden Befehle:
sudo tlmgr update --self
sudo tlmgr update --all
könnten dadurch in einer Zeile zusammengefasst werden:
sudo tlmgr update --self && sudo tlmgr update --allLässt man die
&& weg, wird allerhöchstens der zuletzt vollständig erkannte Befehl ausgeführt (in diesem Beispiel
sudo tlmgr update --all). Man ist jedenfalls auf der sicheren Seite, wenn man auch in Scripten die Befehle durch „Enter“ trennt. Es liegt zwar im Ermessen des Interpreters, ob er einen Befehl bereits ausführt, wenn er ihn als vollständig erkannt hat, aber dazu muss man genaueres darüber wissen: mal genügt ein Leerzeichen, mal nicht … Mach einfach
Enter und fertig.
Poste bei Gelegenheit mal den Output von env (am besten mit der Codefragment-Darstellung; der Button mit dem Gatterzeichen # ).
Sorry, das verstehe ich nicht. Meinst Du: "env # gs"? Oder "env gs #"? Da stoßen meine Unix-Kenntnisse schon wieder an ihre Grenzen...
Ups, weg vom Terminal
Du sollst nur (1) im Terminal
env eingeben und die Ausgabe hier im Forum posten, und zwar (2) formatiert als Code: wenn du einen Beitrag schreibst, gibt es doch die bunten Buttons über dem Texteingabefeld (oder benutzt du einen Textbrowser???); einer davon ist mit dem Gatterzeichen (#) versehen und nennt sich „Code einfügen“. Wenn du darauf klickst, wird an der aktuellen Cursorposition im Eingabefeld
[code][/code] eingefügt; dahinein kopierst du die Terminalausgabe. Ich hab es einfach mal „Codefragment-Darstellung“ genannt; es schafft eine eigene Zitierumgebung, in der alles „wie eingegeben“ dargestellt wird – incl. Zeilenumbrüchen, auf die es uns ja ankommt.
Die wichtigste Information aus dem
env-Ergebnis ist aber der Inhalt der PATH-Variable: Pfade werden von vorn nach hinten durchsucht. Wenn z.B. Pfade zu verschiedenen GS- oder Python-Executables gleichzeitig eingetragen sind, hört die Suche danach auf, sobald eine ausführbare Anwendung gefunden wurde. Es ist dann völlig egal, ob in einem anderen (nachfolgenden) Pfad eine gleichnamige und evtl. neuere Version vorhanden ist.
Und damit sind wir noch kurz bei den GS-Suchpfaden: die schauen schonmal gut aus! Die relevanten Pfade stehen ja vorn in der Liste, von daher wird mit den ersten Treffern gearbeitet, sofern Lily das für nötig hält. Ich frage mich trotzdem, weshalb Pfade zu
/usr/lib/DPS oder
/usr/openwin/* pauschal in die Anwendung kompiliert werden, selbst wenn dort nichts aufzufinden ist und deshalb keinen Schaden anrichten kann. Ich schau mir das auch mal in Windows an und frage notfalls die Entwickler.
Diese Nachricht der lilypond-user-Liste hatte mir Mut gemacht, die GS-Executable/Binary versuchsweise auszutauschen, aber das mochte nicht gelingen (trotz GS-Binary für Mac). Vielleicht war das vor 4 Jahren in einer Uralt-Lily-Version noch möglich.
[ups – falschen Button erwischt und grüßen vergessen]
Grüße, Robert
