[Lilypond-auto] Issue 3496 in lilypond: Path expansion in lilypond-book (and others)

[lilypond]

Status: Accepted
Owner: ----
Labels: Type-Crash OpSys-Linux

New issue 3496 by address@hidden: Path expansion in lilypond-book  
(and others)
http://code.google.com/p/lilypond/issues/detail?id=3496

Chris Ritson wrote :

> 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?

I was using lilypond as packaged with fedora 19 (lx spin) - this is  
lilypond-doc-2.16.2-2.fc19.noarch

The same code sequence occurs in a more recent download - GNU LilyPond  
2.17.22

Unfortunately, I am not a python expert so it needs someone to be sure that  
adding os.realpath without further validation does not introduce unwanted  
security risks.

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings