Betriebssystemabhängig > Mac OS X
unverständliche Fehlermeldung
juppes:
hallo Robert,
Ich habe ".profile" nach Deinen Vorgaben abgeändert (war ja nicht viel anzupassen außer dem Benutzernamen für ~/Users/*/Fonts, wenn ich das richtig sehe). Ich bringe aber (und vielleicht steckt ja noch ein Denkfehler in meinen zusätzlichen Suchpfaden für Lilypond, die ich in ".profile" hineingeschrieben habe) Lilypond nicht dazu, dort auch tatsächlich zu suchen, denn eine Eingabe im Terminal
/Applications/LilyPond.app/Contents/Resources/bin/gs -h
ergibt nur:
. : /usr/share/ghostscript/8.70/Resource/Init :
/usr/share/ghostscript/8.70/lib :
/usr/share/ghostscript/8.70/Resource/Font :
/usr/share/ghostscript/fonts : /usr/share/fonts/default/ghostscript :
/usr/share/fonts/default/Type1 : /usr/share/fonts/default/TrueType :
/usr/lib/DPS/outline/base : /usr/openwin/lib/X11/fonts/Type1 :
/usr/openwin/lib/X11/fonts/TrueType
Der Inhalt von ".profile" bei mir sieht folgendermaßen aus:
LC_CTYPE=de_DE.UTF-8 export LC_CTYPE export PATH=$PATH:~/bin
GS_LIB="/usr/local/share/ghostscript/8.70/Resource/Init:/usr/local/share/ghostscript/8.70/lib:/usr/local/share/ghostscript/8.70/Resource/Fo$
export GS_LIB PATH="/usr/local/bin:${PATH}"
export PATH
Die erste Zeile stand vorher schon drin; die brauche ich, um nano UTF-8 beizubringen.
Hoffe, Du findest eine Ungereimtheit, die man beseitigen kann...
Und sonst: es ist vielleicht tatsächlich so, daß das Lilypond-GUI unter Mac OS X immer ein wenig hakt. Aber wenn andere Umgebungen nicht haken, dann nimmt man eben die, vor allem wenn sie noch mehr Features haben.
herzlichen Gruß
RobUr:
Hallo juppes!
--- Zitat ---Hoffe, Du findest eine Ungereimtheit, die man beseitigen kann...
--- Ende Zitat ---
Sind die Zeilen per Zeilenumbruch getrennt? Man kann diese auch anders schreiben (und am besten kommentieren):
--- Code: ---# UTF-8 fuer nano
export LC_CTYPE=de_DE.UTF-8
# Pfad zu /bin im Home-Verzeichnis den anderen Pfaden voranstellen
export PATH="~/bin:$PATH"
# Pfade zu GS 8.70-Libraries und Font-Ordnern
export GS_LIB="/usr/local/share/ghostscript/8.70/Resource/Init:/usr/local/share/ghostscript/8.70/lib:/usr/local/share/ghostscript/8.70/Resource/Font:/usr/local/share/ghostscript/fonts:/Users/ich/Library/Fonts"
# Pfad zu /usr/local/bin (wo gs liegt) den anderen Pfaden voranstellen
export PATH="/usr/local/bin:$PATH"
--- Ende Code ---
Ein-/ausgeloggt wirst du dich wohl haben … Poste bei Gelegenheit mal den Output von env (am besten mit der Codefragment-Darstellung; der Button mit dem Gatterzeichen # ).
Grüße, Robert
juppes:
hallo Robert,
da bin ich wieder (war zwei Tage unterwegs). Ich habe mal Deine Version von ".profile" bei mir eingesetzt. Erstmal sieht das natürlich übersichtlicher aus und zweitens hatte es positive Auswirkungen:
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!
Lilypond sucht jetzt tatsächlich auch nicht nur bei sich nach Ghostscript:
Search path:
. : /usr/local/share/ghostscript/8.70/Resource/Init :
/usr/local/share/ghostscript/8.70/lib :
/usr/local/share/ghostscript/8.70/Resource/Font :
/usr/local/share/ghostscript/fonts : /Users/ich/Library/Fonts :
/usr/share/ghostscript/8.70/Resource/Init :
/usr/share/ghostscript/8.70/lib :
/usr/share/ghostscript/8.70/Resource/Font :
/usr/share/ghostscript/fonts : /usr/share/fonts/default/ghostscript :
/usr/share/fonts/default/Type1 : /usr/share/fonts/default/TrueType :
/usr/lib/DPS/outline/base : /usr/openwin/lib/X11/fonts/Type1 :
/usr/openwin/lib/X11/fonts/TrueType
Terminal und TeXShop machen auch weiterhin keinerlei Probleme.
Habe aber noch zwei Fragen:
--- Zitat ---Sind die Zeilen per Zeilenumbruch getrennt?
--- Ende Zitat ---
Ist das von Bedeutung und wenn ja, wieso? Ich hatte an mindestens einer Stelle einen Zeilenumbruch.
--- Zitat ---Poste bei Gelegenheit mal den Output von env (am besten mit der Codefragment-Darstellung; der Button mit dem Gatterzeichen # ).
--- Ende Zitat ---
Sorry, das verstehe ich nicht. Meinst Du: "env # gs"? Oder "env gs #"? Da stoßen meine Unix-Kenntnisse schon wieder an ihre Grenzen... :-\
RobUr:
Hallo juppes!
--- Zitat von: 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!
--- Ende Zitat ---
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.)
--- Zitat von: juppes ---Terminal und TeXShop machen auch weiterhin keinerlei Probleme.
--- Ende Zitat ---
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!
--- Zitat von: juppes ---Lilypond sucht jetzt tatsächlich auch nicht nur bei sich nach Ghostscript
--- Ende Zitat ---
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.
--- Zitat von: juppes ---
--- Zitat von: RobUr ---Sind die Zeilen per Zeilenumbruch getrennt?
--- Ende Zitat ---
Ist das von Bedeutung und wenn ja, wieso? Ich hatte an mindestens einer Stelle einen Zeilenumbruch.
--- Ende Zitat ---
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:
--- Code: ---sudo tlmgr update --self
sudo tlmgr update --all
--- Ende Code ---
könnten dadurch in einer Zeile zusammengefasst werden:
--- Code: ---sudo tlmgr update --self && sudo tlmgr update --all
--- Ende Code ---
Lä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.
--- Zitat von: juppes ---
--- Zitat von: RobUr ---Poste bei Gelegenheit mal den Output von env (am besten mit der Codefragment-Darstellung; der Button mit dem Gatterzeichen # ).
--- Ende Zitat ---
Sorry, das verstehe ich nicht. Meinst Du: "env # gs"? Oder "env gs #"? Da stoßen meine Unix-Kenntnisse schon wieder an ihre Grenzen...
--- Ende Zitat ---
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
RobUr:
--- Zitat ---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.
--- Ende Zitat ---
Das sollte ruhig mal in der englischen Liste gepostet werden! Ich weiß nicht, wie lang Apple noch auf PPC baut (falls es daran läge), aber es sind gewiss genügend Maschinen damit im Umlauf.
Wenn du dabei Hilfe brauchst, vielleicht an James wenden (hat dort bereits einiges gepostet und arbeitet selbst am Mac) oder halt an mich (wär mal ein Anlass, dort mehr als zu lesen …).
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln