Re: my favorite bug :-)
Am 01.05.2015 um 13:53 schrieb Masamichi HOSODA: The bug would be fixed if lilypond would make ghostscript use a complete path to the intermediate lines.ps file for the ps to pdf conversion. Does anyone know how to convert from any path (relative and absolute path) to absolute path in scheme (guile) ? Maybe the functions in this file help you? https://github.com/openlilylib/openlilylib/blob/master/ly/_internal/utilities/os-path.scm Urs ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
The bug would be fixed if lilypond would make ghostscript use a complete path to the intermediate lines.ps file for the ps to pdf conversion. Does anyone know how to convert from any path (relative and absolute path) to absolute path in scheme (guile) ? Maybe the functions in this file help you? https://github.com/openlilylib/openlilylib/blob/master/ly/_internal/utilities/os-path.scm Thank you. But, now, I think using an absolute path for solving ghostscript file name issue is not a good idea. Using mkstemp generated temporary file is a good idea. It is the same way as gcc's intermediate file treatment. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
The bug would be fixed if lilypond would make ghostscript use a complete path to the intermediate lines.ps file for the ps to pdf conversion. Does anyone know how to convert from any path (relative and absolute path) to absolute path in scheme (guile) ? When the following command is used, lilypond uses the absolute (complete) path to the intermediate files. $ lilypond -dgui `pwd`/lines.ly It works fine. However, I think that the intermediate file should be temporary by mkstemp etc. If lilypond uses mkstemp generated temporary file, this ghostscript problem will not occur. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
There is a big difference: If you compile a .c file, the .o files stays by default; the compiler doesn't remove it. Uh, wrong? cd /tmp;echo main(){return 0;} gega.c;gcc -o gega gega.c;ls gega* gega gega.c I've meant using option `-c' of the compiler. BTW, if you specify option `-o', does gcc create an intermediate file `gega.o' that overwrites another file `gega.o' in the compilation directory? Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
On Fri, 1 May 2015 12:48:52 +0200 (CEST) Martin Tarenskeen m.tarensk...@zonnet.nl wrote: In this case, as an intermediate file example.ps is used. This is a problem if a file named example.ps already exists in my working directory. This file is brutally overwritten and deleted when I run lilypond without any warning or option to cancel, nor is a backup copy of the old file made. Exactly the behaviour that I want. When I work on manuscripts the .pdf (as well as the .midi) are objects. The .ly is the only source. Just like compiling .c files, I don't want a warning every time it is going to overwrite a .o file. If the intermediate file would be given a unique, not already existing, temporary filename, not only this issue would be solved but Solved for some, problem for others. I don't want to have to guess what my final manuscript is named. If I start with example.ly I know that example.pdf is my target. Scripts can deal with that easily. I use make for my charts. Having to deal with guessing output file names would be incredibly tricky if possible at all. also the original lines.ly - lines.ps - lines.pdf issue that started this thread would not be a problem anymore. Different issue. -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 788 2246 (DoD#0082)(eNTP) | what's for dinner. IM: da...@vex.net, VoIP: sip:da...@druid.net ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
Werner LEMBERG w...@gnu.org writes: There is a big difference: If you compile a .c file, the .o files stays by default; the compiler doesn't remove it. Uh, wrong? cd /tmp;echo main(){return 0;} gega.c;gcc -o gega gega.c;ls gega* gega gega.c I've meant using option `-c' of the compiler. Uh, removing the actual end product of a command would be sort of strange, wouldn't it? BTW, if you specify option `-o', does gcc create an intermediate file `gega.o' that overwrites another file `gega.o' in the compilation directory? dak@lola:/tmp$ touch gega.o dak@lola:/tmp$ gcc -o gega gega.c dak@lola:/tmp$ ls -l gega.o -rw-rw-r-- 1 dak dak 0 May 1 16:46 gega.o No. It is a safe bet that there _are_ intermediate files, but they'll likely end up somewhere on /tmp or similar. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
However, I think that the intermediate file should be temporary by mkstemp etc. If lilypond uses mkstemp generated temporary file, this ghostscript problem will not occur. +1 Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
Hello David and Masamichi! I've meant using option `-c' of the compiler. Uh, removing the actual end product of a command would be sort of strange, wouldn't it? Yes. But sometimes there are Makefile rules that remove intermediate files. BTW, if you specify option `-o', does gcc create an intermediate file `gega.o' that overwrites another file `gega.o' in the compilation directory? dak@lola:/tmp$ touch gega.o dak@lola:/tmp$ gcc -o gega gega.c dak@lola:/tmp$ ls -l gega.o -rw-rw-r-- 1 dak dak 0 May 1 16:46 gega.o No. It is a safe bet that there _are_ intermediate files, but they'll likely end up somewhere on /tmp or similar. Thanks for confirmation. The suggestion is to let lilypond do the same. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
Werner LEMBERG w...@gnu.org writes: In this case, as an intermediate file example.ps is used. This is a problem if a file named example.ps already exists in my working directory. This file is brutally overwritten and deleted when I run lilypond without any warning or option to cancel, nor is a backup copy of the old file made. Exactly the behaviour that I want. Certainly not. When I work on manuscripts the .pdf (as well as the .midi) are objects. The .ly is the only source. Just like compiling .c files, I don't want a warning every time it is going to overwrite a .o file. There is a big difference: If you compile a .c file, the .o files stays by default; the compiler doesn't remove it. Uh, wrong? cd /tmp;echo main(){return 0;} gega.c;gcc -o gega gega.c;ls gega* gega gega.c -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
There is a big difference: If you compile a .c file, the .o files stays by default; the compiler doesn't remove it. Uh, wrong? cd /tmp;echo main(){return 0;} gega.c;gcc -o gega gega.c;ls gega* gega gega.c I've meant using option `-c' of the compiler. BTW, if you specify option `-o', does gcc create an intermediate file `gega.o' that overwrites another file `gega.o' in the compilation directory? If I understand correctly, in this case, gcc does not use gega.o. gcc uses /tmp/ccXX.o etc. (XX is replaced by random unique charactor by mkstemp.) gcc removes it. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
Werner LEMBERG w...@gnu.org writes: Hello David and Masamichi! I've meant using option `-c' of the compiler. Uh, removing the actual end product of a command would be sort of strange, wouldn't it? Yes. But sometimes there are Makefile rules that remove intermediate files. Why bring up Make? Make has no mechanism for dealing with intermediate files (it removes _target_ files by default when the rule producing them errors out). So any removal of intermediate files has to happen by writing it as part of an action. You could equally well say sometimes there are shell scripts that remove intermediate files. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-) (fwd)
Did you know it is not possible/allowed to name a lilypond file align.ly or lines.ly? On my Fedora system I can find all the names that suffer from this bug by typing #ls /usr/share/ghostscript/9.15/lib/*.ps all these filenames (minus .ps) can not be used as lilypond inputfiles (plus .ly) for example create a file lines.ly with a minimal content \version 2.19.19 {c' d' e' f'} and compile ... Fortunately there are no prelude.ps, etude.ps, or sonata.ps in the ghostscript files ;-) In my cygwin64 environment, I've reproduced it. (I've installed lilypond by cygwin64 setup in the environment.) And, the following commands also has been reproduced it. $ lilypond -f ps lines.ly $ ps2pdf14 lines.ps lines.pdf On the other hand, the following commands has not been reproduced it. $ lilypond -f ps lines.ly $ ps2pdf14 `pwd`/lines.ps lines.pdf Perhaps it's a ghostscript's bug. (ps2pdf14 is ghostscript included command.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
for example create a file lines.ly with a minimal content \version 2.19.19 {c' d' e' f'} and compile ... I'm trying to narrow down the issue It seems that on some systems (like mine). # gs lines.ps is expanded to something like # gs /usr/share/ghostscript/9.15/lines.ps but # gs /complete/path/to/lines.ps is not. When compiling a lines.ly file, lines.ps is produced as an intermediate file before ghostscript converts this to lines.pdf The bug would be fixed if lilypond would make ghostscript use a complete path to the intermediate lines.ps file for the ps to pdf conversion. -- MT ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
my favorite bug :-) (fwd)
-- Forwarded message -- Date: Fri, 1 May 2015 09:47:25 +0200 (CEST) From: Martin Tarenskeen m.tarensk...@zonnet.nl To: lilypond-user mailinglist lilypond-u...@gnu.org Subject: my favorite bug :-) This issue has been reported in the mailing list some time ago - I think it was David Kastrup who discovered it - but I can't find it anywhere in the buglist or in the docs. Did you know it is not possible/allowed to name a lilypond file align.ly or lines.ly? On my Fedora system I can find all the names that suffer from this bug by typing #ls /usr/share/ghostscript/9.15/lib/*.ps all these filenames (minus .ps) can not be used as lilypond inputfiles (plus .ly) for example create a file lines.ly with a minimal content \version 2.19.19 {c' d' e' f'} and compile ... Fortunately there are no prelude.ps, etude.ps, or sonata.ps in the ghostscript files ;-) -- MT ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
On Fri, 1 May 2015, Martin Tarenskeen wrote: The bug would be fixed if lilypond would make ghostscript use a complete path to the intermediate lines.ps file for the ps to pdf conversion. The issue has brought me to another problem: LilyPond by default takes *.ly file as input and produces a *.pdf file as output. $lilypond example.ly --- result: example.pdf In this case, as an intermediate file example.ps is used. This is a problem if a file named example.ps already exists in my working directory. This file is brutally overwritten and deleted when I run lilypond without any warning or option to cancel, nor is a backup copy of the old file made. If the intermediate file would be given a unique, not already existing, temporary filename, not only this issue would be solved but also the original lines.ly - lines.ps - lines.pdf issue that started this thread would not be a problem anymore. I'm not a (LilyPond) developer but does it makes sense what I am suggesting? -- MT ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
In this case, as an intermediate file example.ps is used. This is a problem if a file named example.ps already exists in my working directory. This file is brutally overwritten and deleted when I run lilypond without any warning or option to cancel, nor is a backup copy of the old file made. Exactly the behaviour that I want. Certainly not. When I work on manuscripts the .pdf (as well as the .midi) are objects. The .ly is the only source. Just like compiling .c files, I don't want a warning every time it is going to overwrite a .o file. There is a big difference: If you compile a .c file, the .o files stays by default; the compiler doesn't remove it. However, lilypond, if called with option `--pdf' (which is the default), *does* remove the intermediate .ps file! If the intermediate file would be given a unique, not already existing, temporary filename, not only this issue would be solved but Solved for some, problem for others. I don't want to have to guess what my final manuscript is named. If I start with example.ly I know that example.pdf is my target. Scripts can deal with that easily. Perhaps a misunderstanding: If I say lilypond --pdf foo.ly I get `foo.pdf', no question. If I say lilypond --os foo.ly I get `foo.ps'. However, the former call creates an intermediate file `foo.ps' that gets deleted eventually by lilypond itself. And this is bad. also the original lines.ly - lines.ps - lines.pdf issue that started this thread would not be a problem anymore. Different issue. No, not at all. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
If the intermediate file would be given a unique, not already existing, temporary filename, not only this issue would be solved but also the original lines.ly - lines.ps - lines.pdf issue that started this thread would not be a problem anymore. I'm not a (LilyPond) developer but does it makes sense what I am suggesting? Yes, it does. As soon as your bug report gets added to the tracker, please add this your comment. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
The bug would be fixed if lilypond would make ghostscript use a complete path to the intermediate lines.ps file for the ps to pdf conversion. Does anyone know how to convert from any path (relative and absolute path) to absolute path in scheme (guile) ? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond