Jan Nieuwenhuizen wrote: > Mojca Miklavec writes: > > > This solves it! If I call lilypond with the whole path, it works (but > > it should be working also when calling lilypond alone). I can modify > > the module which calls lilypond to fit my installation > > Ok, great. > > > , but it won't work for the others. > > What others?
Just as an example: Someone has written (still preliminary) support for LilyPond inclusion to ConTeXt (alternative to LaTeX), see http://article.gmane.org/gmane.comp.tex.context/22512. Well, the "script" calls "lilypond filename". Whoever wants to use this script, has to dig into the source and modify the line calling lilypond to match his own installation path. (In Linux this is not a problem at all.) But it's not only because of this single exception that may be used by some tens of people, out of which most use Linux. This looks like a lilypond misbehaviour (It may be that it's Microsoft's fault, but you can't make anything about it). You can't expect a programmer writing some piece of software which uses LilyPond to write: if OS == windows find the path where lilypond resides and call it with the whole path I don't even dare to start thinking what would happen if the path would have to be hardcoded for a GhostScript call. > That is for other programs in the lilypond bin directory. Why doesn't it happen already at the installation time then? People should be able to call lilypond from command line anyway. Thank you very much for the hint anyway, it will do for now, but it would be great if this could be fixed in the future releases. Mojca _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user