LilyPond's gs console output on windows

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

LilyPond's gs console output on windows

Werner LEMBERG

Folks,


on a Windows 10 box I downloaded and installed the binary distribution
of 2.19.83, which worked fine; I was able to compile a PDF on the
Windows command line (I think that drag and drop to the lilypond icon
doesn't work, but since my Windows knowledge is too limited I haven't
pursued this further).  Then I tried to directly call `gs', the
ghostscript binary that comes with lilypond.  It produces an empty
line on the console, and that's it.  Later on, I wondered why the
laptop's fan suddenly starts to run loudly – checking with the task
manager I saw that gs still run as a background process...

After some tests I found out that only redirecting the stdout output
to a file works on the Windows console.  On the other hand, using the
bash shell that comes with git for windows, I get proper output on the
bash window without redirection.  This behaviour is different to the
lilypond binary, which produces output in both the Windows console and
git bash.

I know wonder whether this problem is

  (1) limited to the gs program that comes with lilypond,
  (2) related to the way gub is compiling gs,
  (3) connected to changes in the Windows 10 console,
  (4) or whether this a generic issue with gs itself, probably fixed
      in newer gs versions.

If we will have this behaviour with the next gub build also, I suggest
that it gets documented.


    Werner
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
dak
Reply | Threaded
Open this post in threaded view
|

Re: LilyPond's gs console output on windows

dak
Werner LEMBERG <[hidden email]> writes:

> Folks,
>
>
> on a Windows 10 box I downloaded and installed the binary distribution
> of 2.19.83, which worked fine; I was able to compile a PDF on the
> Windows command line (I think that drag and drop to the lilypond icon
> doesn't work, but since my Windows knowledge is too limited I haven't
> pursued this further).  Then I tried to directly call `gs', the
> ghostscript binary that comes with lilypond.  It produces an empty
> line on the console, and that's it.  Later on, I wondered why the
> laptop's fan suddenly starts to run loudly – checking with the task
> manager I saw that gs still run as a background process...

Doesn't Windows use rungs or something like that for interactive use?

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: LilyPond's gs console output on windows

Werner LEMBERG
In reply to this post by Werner LEMBERG

Ten days ago I wrote the following.

> on a Windows 10 box I downloaded and installed the binary
> distribution of 2.19.83, which worked fine; I was able to compile a
> PDF on the Windows command line (I think that drag and drop to the
> lilypond icon doesn't work, but since my Windows knowledge is too
> limited I haven't pursued this further).  Then I tried to directly
> call `gs', the ghostscript binary that comes with lilypond.  It
> produces an empty line on the console, and that's it.  Later on, I
> wondered why the laptop's fan suddenly starts to run loudly –
> checking with the task manager I saw that gs still run as a
> background process...
>
> After some tests I found out that only redirecting the stdout output
> to a file works on the Windows console.  On the other hand, using
> the bash shell that comes with git for windows, I get proper output
> on the bash window without redirection.  This behaviour is different
> to the lilypond binary, which produces output in both the Windows
> console and git bash.
>
> I know wonder whether this problem is
>
>   (1) limited to the gs program that comes with lilypond,
>   (2) related to the way gub is compiling gs,
>   (3) connected to changes in the Windows 10 console,
>   (4) or whether this a generic issue with gs itself, probably fixed
>       in newer gs versions.
>
> If we will have this behaviour with the next gub build also, I
> suggest that it gets documented.

There wasn't a response – I would be glad to get a confirmation (or
not) so that I can add it as an issue in case more people see the
problem.


    Werner
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
dak
Reply | Threaded
Open this post in threaded view
|

Re: LilyPond's gs console output on windows

dak
Werner LEMBERG <[hidden email]> writes:

> Ten days ago I wrote the following.
>
>> on a Windows 10 box I downloaded and installed the binary
>> distribution of 2.19.83, which worked fine; I was able to compile a
>> PDF on the Windows command line (I think that drag and drop to the
>> lilypond icon doesn't work, but since my Windows knowledge is too
>> limited I haven't pursued this further).  Then I tried to directly
>> call `gs', the ghostscript binary that comes with lilypond.  It
>> produces an empty line on the console, and that's it.  Later on, I
>> wondered why the laptop's fan suddenly starts to run loudly –
>> checking with the task manager I saw that gs still run as a
>> background process...
>>
>> After some tests I found out that only redirecting the stdout output
>> to a file works on the Windows console.  On the other hand, using
>> the bash shell that comes with git for windows, I get proper output
>> on the bash window without redirection.  This behaviour is different
>> to the lilypond binary, which produces output in both the Windows
>> console and git bash.
>>
>> I know wonder whether this problem is
>>
>>   (1) limited to the gs program that comes with lilypond,
>>   (2) related to the way gub is compiling gs,
>>   (3) connected to changes in the Windows 10 console,
>>   (4) or whether this a generic issue with gs itself, probably fixed
>>       in newer gs versions.
>>
>> If we will have this behaviour with the next gub build also, I
>> suggest that it gets documented.
>
> There wasn't a response – I would be glad to get a confirmation (or
> not) so that I can add it as an issue in case more people see the
> problem.

Didn't Windows require something like rungs or mgs or gswin32c or so?

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: LilyPond's gs console output on windows

Karlin High
On Thu, Aug 22, 2019 at 2:36 PM David Kastrup <[hidden email]> wrote:

>
> Werner LEMBERG <[hidden email]> writes:
>
> >> I know wonder whether this problem is
> >>
> >>   (1) limited to the gs program that comes with lilypond,
> >>   (2) related to the way gub is compiling gs,
> >>   (3) connected to changes in the Windows 10 console,
> >>   (4) or whether this a generic issue with gs itself, probably fixed
> >>       in newer gs versions.
> >>
> >> If we will have this behaviour with the next gub build also, I
> >> suggest that it gets documented.
>
> Didn't Windows require something like rungs or mgs or gswin32c or so?

I have LilyPond 2.19.83 on Windows 7 Pro 64-bit SP1 and Windows 10 Pro
64-bit version 1903.

Both of them behave the same way on Windows console: output a blank
line and exit.

Windows 10 does the same thing on PowerShell.

But, with Windows Subsystem for Linux, one can type "bash" in the
console and it switches to a bash environment. That seems to execute
things as expected. I haven't tried Git on Windows' bash shell.

Now, about GhostScript helper programs:

C:\Program Files (x86)\LilyPond\usr\bin>dir *gs* /B
gs-9.21.dll
gs-9.dll
gs.dll
gs.exe
gsettings.exe
gspawn-win32-helper-console.exe
gspawn-win32-helper.exe
gsx.exe

I also have PDF Creator (from pdfforge.org) which has its own GhostScript.

C:\Program Files\PDFCreator\Ghostscript\Bin>dir /B
gsdll32.dll
gsdll32.lib
gswin32c.exe

C:\Program Files\PDFCreator\Ghostscript\Bin> gswin32c.exe
GPL Ghostscript 9.25 (2018-09-13)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>

Hopefully that was helpful. I can do further testing if requested.
--
Karlin High
Missouri, USA

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: LilyPond's gs console output on windows

Werner LEMBERG

>> >> I know wonder whether this problem is
>> >>
>> >>   (1) limited to the gs program that comes with lilypond,
>> >>   (2) related to the way gub is compiling gs,
>> >>   (3) connected to changes in the Windows 10 console,
>> >>   (4) or whether this a generic issue with gs itself, probably
>> >>       fixed in newer gs versions.
>> >>
>> >> If we will have this behaviour with the next gub build also, I
>> >> suggest that it gets documented.
>>
>> Didn't Windows require something like rungs or mgs or gswin32c or
>> so?
>
> I have LilyPond 2.19.83 on Windows 7 Pro 64-bit SP1 and Windows 10
> Pro 64-bit version 1903.
>
> Both of them behave the same way on Windows console: output a blank
> line and exit.
>
> But, with Windows Subsystem for Linux, one can type "bash" in the
> console and it switches to a bash environment.  That seems to
> execute things as expected. I haven't tried Git on Windows' bash
> shell.

Thanks for testing; git's bash shell works just fine.

It seems this is a GUB issue: It doesn't set the proper flag(s) to
build gs on windows as a console application.  In other words, right
now GUB builds `gswin32' and not `gswin32c'.  Maybe this is
intentional – I'm no expert on the Windows setup of GS.  If it is, we
should document that calling gs on the Windows console directly only
works if stdout gets redirected to a file, or if the binary is used
within a Unix shell like `git bash'.


    Werner


PS: The reason to call gs manually is to benefit from lilypond's
    `-dgs-never-embed-fonts' switch (also provided by lyluatex's
    `optimize-pdf' option), which needs post-processing with
    ghostscript.
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
dak
Reply | Threaded
Open this post in threaded view
|

Re: LilyPond's gs console output on windows

dak
Werner LEMBERG <[hidden email]> writes:

>>> >> I know wonder whether this problem is
>>> >>
>>> >>   (1) limited to the gs program that comes with lilypond,
>>> >>   (2) related to the way gub is compiling gs,
>>> >>   (3) connected to changes in the Windows 10 console,
>>> >>   (4) or whether this a generic issue with gs itself, probably
>>> >>       fixed in newer gs versions.
>>> >>
>>> >> If we will have this behaviour with the next gub build also, I
>>> >> suggest that it gets documented.
>>>
>>> Didn't Windows require something like rungs or mgs or gswin32c or
>>> so?
>>
>> I have LilyPond 2.19.83 on Windows 7 Pro 64-bit SP1 and Windows 10
>> Pro 64-bit version 1903.
>>
>> Both of them behave the same way on Windows console: output a blank
>> line and exit.
>>
>> But, with Windows Subsystem for Linux, one can type "bash" in the
>> console and it switches to a bash environment.  That seems to
>> execute things as expected. I haven't tried Git on Windows' bash
>> shell.
>
> Thanks for testing; git's bash shell works just fine.
>
> It seems this is a GUB issue: It doesn't set the proper flag(s) to
> build gs on windows as a console application.  In other words, right
> now GUB builds `gswin32' and not `gswin32c'.  Maybe this is
> intentional – I'm no expert on the Windows setup of GS.

Intentional or not, it does not seem like a good idea.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: LilyPond's gs console output on windows

Werner LEMBERG

>> It seems this is a GUB issue: It doesn't set the proper flag(s) to
>> build gs on windows as a console application.  In other words,
>> right now GUB builds `gswin32' and not `gswin32c'.  Maybe this is
>> intentional – I'm no expert on the Windows setup of GS.
>
> Intentional or not, it does not seem like a good idea.

Looking up GUB I see that it is intentional.  In a comment it is
suggested to build both a console version and a GUI version, but this
wasn't implemented.


    Werner
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel