\include-Pfad in Variablen

[ingmar]

(1) Erzeuge irgendein Lilypondfile und speichere es unter dem Namen "2.ly". Beispielfile:

Code: [Auswählen]

\version "2.19.37"
{ c d e f g }
(2) Erzeuge folgendes Lilypondfile, das dieses aufruft (nenne es beispielsweise 1.ly):

Code: [Auswählen]

\version "2.19.37"
FILENAME="2.ly"

\include 2.ly
% \include \FILENAME
--> Kompiliert fehlerfrei!

(3) Nun kommentieren wir die letzte Zeile aus
--> Kompiliert immer noch fehlerfrei; wir sehen 2.ly zweimal eingebunden.

(4) Nun kommentieren wir die vorletzte Zeile ein, rufen das zweite File also nur noch per Variablennamen auf:
--> Fehlermeldung: Lilypond findet den Pfad nicht! Es sucht in einem temporären Pfad mit offenbar zufällig erzeugtem Namen

Anmerkungen
* Das Problem tritt auf unter Frescobaldi; vielleicht hat es ja auch damit zu tun.
* "./" vor den Filenamen zu setzen bringt offenbar auch nichts.
* Die Fehlermeldung zeigt die Pfade an, die versucht wurden; ich kann sie gerne hier posten, wenn das hilfreich ist.

Was tun?


Gruß,
--ingmar

Edit: Wie oben erkennbar, setzt der Aufruf mit ausdrücklichem Filenamen offenbar den Pfad richtig; man kann sich also helfen, indem man zunächst ein beliebiges anderes File aufruft. Aber es bleibt natürlich der Eindruck, dass da etwas nicht stimmt..

[Manuela]

Code: [Auswählen]

\include 2.ly
compiliert bei mir überhaupt nicht,
 ich muss

Code: [Auswählen]

\include "2.ly"
daraus machen.

Soviel ich weiß, kann man eine Variable unmittelbar nach ihrer Definition nicht verwenden, es muss noch mindestens ein weiterer Befehl dazwischen liegen. Aber auch nach Einfügen von Code dazwischen funktioniert es nicht.

Code: [Auswählen]

\version "2.19.42"

FILENAME="2.ly"
{ a e f }
\include \FILENAME
Ich vermute, dass das temporäre Verzeichnis gilt, wenn mit Frescobaldi gearbeitet und der Dateiname als Variable definiert wird. Wenn ich den absoluten Dateinamen einsetze, klappt es

Code: [Auswählen]

\version "2.19.42"

FILENAME="D:\\Lilypond\\.....hier mein Pfad\\2.ly"
{ a e f }
\include \FILENAME
Um das ganze etwas flexibler zu gestalten, könntest du z.B. folgendes machen:

Code: [Auswählen]

\version "2.19.42"

FilePath="D:\\Lilypond\\meinpfad\\"
FILENAME="2.ly"
{ a e f }

\include #(string-append FilePath FILENAME)

[ingmar]

Manuela:
\include 2.ly compiliert bei mir überhaupt nicht, ich muss \include "2.ly" daraus machen.

Öhh.. stimmt natürlich! Sorry. *rotwerd*

Du schlägst vor, den absoluten Pfad zu verwenden. Aber dann kann ich meinen Code niemand anders mehr geben! Sorry - die Möglichkeit fällt leider aus für mich.

Da nähm ich eher meinen eigenen Workaround, zuvor irgendein File einzubinden, ohne es wirklich zu verwenden.


Dennoch danke für Deine Mühe!
--ingmar

[iugin]

Hallo Ingmar

ausser die Anführungszeichen: bei mir kompiliert dein Code wunderbar.
Allerdings habe ich 2.18.2 noch, und nicht 2.19.42.
Ich habe auch mit Frescobaldi versucht, Version 2.18.1, alles ok.
Hilft natürlich nicht gross, aber vielleicht kann man das Problem so auf eine bestimmte Version begrenzen.

Lieber Gruss

Eugenio

[fugenkomponist]

Soviel ich weiß, kann man eine Variable unmittelbar nach ihrer Definition nicht verwenden, es muss noch mindestens ein weiterer Befehl dazwischen liegen. Aber auch nach Einfügen von Code dazwischen funktioniert es nicht.

Hier scheint tatsächlich irgendwo das Problem zu liegen. Ich kann aber deine Beobachtung nicht ganz teilen: Mit Code dazwischen gehts. Und mit 2.18.2 auch ohne. Da scheint sich in 2.19 was geändert zu haben, hab auch ne ungefähre Idee, wo.

Was aber geht:

Code: [Auswählen]

\version "2.19.42"
#(define FILENAME "2.ly")
\include \FILENAMEstatt

Code: [Auswählen]

\version "2.19.42"
FILENAME="2.ly"
\include \FILENAME
Durch die Verwendung von define ist ganz klar, wo die Definition von FILENAME fertig ist (in reiner LilyPond-Syntax ist das erst unter bestimmten Umständen so, deshalb wird FILENAME im \include noch nicht als unbedingt fertig angesehen, wenn ich das richtig verstanden hab).

Falls du doch bei der Zuweisung in LilyPond (per =) bleiben willst, würd ich keinen überflüssigen \include machen, sondern was wie #(define dummy 42), weil dann klar ist, dass da nichts wirklich wichtiges passiert und ein \include für LilyPond mit Arbeit (Datei öffnen, lesen, parsen, …) verbunden ist.

Edit: Noch einfacher als #(define dummy 42) ist #'()
Da passiert definitiv nichts gefährliches (könnt ja sein, dass dummy irgendwo definiert ist und nun überschrieben wird )

[ingmar]

fugenkomponist: Was aber geht:
\version "2.19.42"
#(define FILENAME "2.ly")
\include \FILENAME

Wir verwenden unterschiedliche Versionen, vielleicht liegt es auch daran. Bei mir wird es weder durch eine Verdauungspause nach der Variablendefinition noch durch die Definition in Guile statt Lilypond verbessert - dein Vorschlag kompiliert bei mir jedenfalls nicht:

Code: [Auswählen]

\version "2.19.37"
#(define FILENAME "2.ly")

DIGEST = "Jägermeister"
WAIT = "mach mal zwischendurch was anderes"
\markup ""
DIGEST = "Noch ein Jägermeister"

\include \FILENAME
Ich vermute weiterhin, dass in 2.19.37 \include bei ausdrücklicher Pfadangabe zunächst eine Art Standardpfad einstellt, dies bei Verwendung einer Variablen aber unterlässt. In 2.19.42 scheint das nun geändert worden zu sein, offenbar aber immer noch nicht so, wie ich es mir wünschen würde.


Aber danke für deine Antwort!
--ingmar

[fugenkomponist]

dein Vorschlag kompiliert bei mir jedenfalls nicht:

Sicher? Bei mir gehts unter 2.19.37 sowohl mit #(define FOO "2.ly") als auch mit FOO="2.ly", auch ohne #'() oder anderen Kram vorm \include. In 2.19.42 braucht man dann die define-Variante oder Kram vorm \include (und 2.18.2 verhält sich wie 2.19.37, was das angeht). Ich hab hier 2.19.37 und 2.19.42 für Linux (64bit). Und dein Jägermeister-Code ist sowieso in allen drei Versionen kein Problem.

Ich habs auch in verschiedenen Verzeichnissen probiert, um auszuschließen, dass es zufälligerweise im home-Verzeichnis keine Probleme gibt, aber in irgendwelchen Unterverzeichnissen.

Edit:
2.ly:

Code: [Auswählen]

{ c d e f g }1.ly:

Code: [Auswählen]

%\version "2.18.2"
%\version "2.19.37"
%\version "2.19.42"
%#(define FILENAME "2.ly")
%FILENAME="2.ly"
\include \FILENAMEAlle Kombinationen von einkommentierten Versionsangaben (Frescobaldi wählt dann wirklich die richtige Version, hab ich überprüft ) und FILENAME-Definitionen gehen. Nur

Code: [Auswählen]

\version "2.19.42"
FILENAME="2.ly"
\include \FILENAMEnicht.

2. Edit: 2.19.40 ist die erste Version, wo nicht mehr alles geht.
3. Edit: Genauer gesagt ist es da passiert, wo ich es schon geahnt habe: Es wurde eine einfachere Syntax für Scheme-Listen eingeführt, gleichzeitig kann man jetzt Variablennamen aus solchen Listen haben, was Dinge wie „violine.1 = …“ erlaubt. Es handelt sich dabei um diesen Commit, vielleicht sollte das dokumentiert werden in den Changes.
4. Edit: Hab nen bug report geschickt.

[Manuela]

Aha, it's not a bug, it's a feature! 

Das war aber keine wirklich gute Idee, die Syntax so zu ändern, dass diese includes ab 2.19.40 nicht mehr funktionieren.

BTW, fugenkomponist, weißt wo, wo/wie (Scheme-Variable) ich das Verzeichnis finde, in dem die Source steht (windows)? Ich habe zwar Code gefunden, aber das liefert mir nur das temporäre Verzeichnis, in das Frescobaldi den Code kopiert. Irgendwo sollte jedoch der ursprüngliche Dateipfad stehen, schließlich funktionieren die Direkt-Includes nach wie vor.

[fugenkomponist]

Naja, ausgelöst hat das schon ein neues, lang erwartetes Feature. Und Varianten dieses „bugs“ gabs vorher auch schon.

Code: [Auswählen]

\version "2.18.2"
FOO={c d e}
\FOOging schon nicht, jetzt halt auch

Code: [Auswählen]

\version "2.19.40"
FOO="This is a markup"
\FOOnicht mehr.

Wär natürlich schön, wenn beides ginge. Aber ich glaub, dass noch keiner nen Weg gefunden hat, das zu implementieren. Als Workaround hilft jedenfalls in beiden Fällen, ein #'() dazwischenzuschreiben. Suboptimal, aber man ist nicht gänzlich der Freiheit solcher includes beraubt

[fugenkomponist]

off-topic:

BTW, fugenkomponist, weißt wo, wo/wie (Scheme-Variable) ich das Verzeichnis finde, in dem die Source steht (windows)? Ich habe zwar Code gefunden

Wo denn, bzw. welchen Code? Finde ihn selbst auf die Schnelle nicht. Mach vielleicht lieber ein neues Thema dafür auf

[Manuela]

Naja, ausgelöst hat das schon ein neues, lang erwartetes Feature. Und Varianten dieses „bugs“ gabs vorher auch schon.

Code: [Auswählen]

\version "2.18.2"
FOO={c d e}
\FOO

Das Beispiel ist ein bisschen unglücklich gewählt, ich dachte schon, ab jetzt kann man Ziffern in Lilypond-Variablennamen verwenden (las O als 0).

Was genau ist jetzt das neue Feature? Link? (Link zu einer Change-Liste direkt auf der lilypond-Startseite wäre hilfreich)

[fugenkomponist]

Was genau ist jetzt das neue Feature? Link? (Link zu einer Change-Liste direkt auf der lilypond-Startseite wäre hilfreich)

lilypond.org → Handbücher 2.19.43 → Changes (weiter unten auf der Seite) → New features in 2.20 since 2.18
Die aktuell ersten drei Punkte („Dot-separated symbol lists […]“ ff.)

Also sind Ziffern schon auf gewisse Weise in Variablennamen möglich.

[Manuela]

Danke!

[martinusbaum]

hallo,
ich hoffe, hier ist die Ergänzungsfrage richtig:

wie geht lilypond 2.18.2 mit Verzeichnisnamen um, die deutsche Umlaute enthalten?
(\incllude "deutsch.ly" steht oben.
Oder richtig gefragt: wie muss ich vorgehen, dass Umlaute richtig umgesetzt werden?
danke

[harm6]

Als Test habe ich ein file geschaffen namens bääh.ly
Einziger Inhalt:
\markup "bääh
Also mit einem Fehler drin.

Dann \include "bääh.ly" in einem anderen file benutzt.
Funktioniert alles wie es soll, auch die Fehlermeldung mit 2.18.2

bääh.ly:1:10: error: EOF found inside string
\markup "
         bääh

Nach Korrektur, läuft auch alles wie es soll.


Insoweit völlig ohne jegliches Problem.
Ich würds trotzdem schlichtweg nicht machen. Manchmal klappt es nicht wegen irgenwelcher anderen Programme oder dem Betriebssystem oder was weiß ich...


Gruß,
  Harm

EDIT Auslassung korrigiert