Re: Path expansion in lilypond-book (and others)
On Wed, Jul 31, 2013 at 7:01 AM, Ralph Palmer ralphbugl...@gmail.comwrote: On Fri, Jul 26, 2013 at 5:55 PM, Chris Ritson chris.rit...@dunelm.org.ukwrote: From: Martin Tarenskeen Date: Fri, 22 Feb 2013 12:40:58 +0100 (CET) snip ERROR: In procedure primitive-load-path: ERROR: Unable to find file lily.scm in load path The clue to this is in a later posting from Robert Eckl. lilypond-book is using a construct os.path.abspath(os.path.dirname(sys.argv[0])) Greetings, Chris Ritson and BugList - I apologize for the late reply. This has been added as issue 3496 - https://code.google.com/p/lilypond/issues/detail?id=3496 Ralph ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Path expansion in lilypond-book (and others)
On Fri, Jul 26, 2013 at 5:55 PM, Chris Ritson chris.rit...@dunelm.org.ukwrote: From: Martin Tarenskeen Date: Fri, 22 Feb 2013 12:40:58 +0100 (CET) snip ERROR: In procedure primitive-load-path: ERROR: Unable to find file lily.scm in load path The clue to this is in a later posting from Robert Eckl. lilypond-book is using a construct os.path.abspath(os.path.dirname(sys.argv[0])) to locate itself and then to find the lilypond share directory from there. On my system (now fedora 19) /bin is a symbolic link to /usr/bin, but there is no equivalent link for /share. /bin is (rightly from the old days of Unix Edition 6) before /usr/bin in my PATH. This leads to an invalid name for lily.scm. I think the right thing to do will be to add os.path.realpath to expand any symbolic links giving the following patch:- *** lilypond-book.orig 2013-07-26 22:29:10.369168798 +0100 --- lilypond-book 2013-07-26 22:28:30.423492984 +0100 *** *** 71,77 sys.path.insert (0, os.path.join (d, 'python')) # dynamic relocation, for GUB binaries. ! bindir = os.path.abspath (os.path.dirname (sys.argv[0])) for p in ['share', 'lib']: datadir = os.path.abspath (bindir + '/../%s/lilypond/current/python/' % p) sys.path.insert (0, datadir) --- 71,77 sys.path.insert (0, os.path.join (d, 'python')) # dynamic relocation, for GUB binaries. ! bindir = os.path.abspath (os.path.dirname (os.path.realpath (sys.argv[0]))) for p in ['share', 'lib']: datadir = os.path.abspath (bindir + '/../%s/lilypond/current/python/' % p) sys.path.insert (0, datadir) There appear to be similar issues in other places as well:- /usr/bin/abc2ly:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) /usr/bin/convert-ly:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) /usr/bin/etf2ly:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) /usr/bin/lilymidi:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) /usr/bin/lilypond-book:bindir = os.path.abspath (os.path.dirname (os.path.realpath (sys.argv[0]))) /usr/bin/lilysong:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) /usr/bin/midi2ly:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) /usr/bin/musicxml2ly:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) Can this be turned into a bug suggestion, please? Chris Ritson Greetings, Chris Ritson - I will add this as an issue, but it would help to know what version of LilyPond you are using. Also, I'm running only Windows 7, and I'm not seeing this. Can anyone confirm whether or not this is occurring under Mac? Ralph ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Path expansion in lilypond-book (and others)
From: Martin Tarenskeen Date: Fri, 22 Feb 2013 12:40:58 +0100 (CET) snip ERROR: In procedure primitive-load-path: ERROR: Unable to find file lily.scm in load path The clue to this is in a later posting from Robert Eckl. lilypond-book is using a construct os.path.abspath(os.path.dirname(sys.argv[0])) to locate itself and then to find the lilypond share directory from there. On my system (now fedora 19) /bin is a symbolic link to /usr/bin, but there is no equivalent link for /share. /bin is (rightly from the old days of Unix Edition 6) before /usr/bin in my PATH. This leads to an invalid name for lily.scm. I think the right thing to do will be to add os.path.realpath to expand any symbolic links giving the following patch:- *** lilypond-book.orig 2013-07-26 22:29:10.369168798 +0100 --- lilypond-book 2013-07-26 22:28:30.423492984 +0100 *** *** 71,77 sys.path.insert (0, os.path.join (d, 'python')) # dynamic relocation, for GUB binaries. ! bindir = os.path.abspath (os.path.dirname (sys.argv[0])) for p in ['share', 'lib']: datadir = os.path.abspath (bindir + '/../%s/lilypond/current/python/' % p) sys.path.insert (0, datadir) --- 71,77 sys.path.insert (0, os.path.join (d, 'python')) # dynamic relocation, for GUB binaries. ! bindir = os.path.abspath (os.path.dirname (os.path.realpath (sys.argv[0]))) for p in ['share', 'lib']: datadir = os.path.abspath (bindir + '/../%s/lilypond/current/python/' % p) sys.path.insert (0, datadir) There appear to be similar issues in other places as well:- /usr/bin/abc2ly:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) /usr/bin/convert-ly:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) /usr/bin/etf2ly:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) /usr/bin/lilymidi:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) /usr/bin/lilypond-book:bindir = os.path.abspath (os.path.dirname (os.path.realpath (sys.argv[0]))) /usr/bin/lilysong:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) /usr/bin/midi2ly:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) /usr/bin/musicxml2ly:bindir = os.path.abspath (os.path.dirname (sys.argv[0])) Can this be turned into a bug suggestion, please? Chris Ritson ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
