bug#36357: Wrong Ghostscript program name on MS Win

bug#36357: Wrong Ghostscript program name on MS Win

[Sebastian Urban]

Variable 'doc-view-ghostscript-program' has value - 'gs' - which is OK
for Unix and VMS, but NOT OK for MS Windows.  It should be 'gswin32c'.
For details look at the table in "How to Use Ghostscript", chapter
"2.1 Help at the command line: gs -h".

Perhaps it should be done as list of choice, like in case of
'tex-dvi-view-command'?

Or as S. Monnier wrote: "(...) the default could simply
(executable-find "gs") and (executable-find "gswin32c") and use
whichever was found (...)".

Also the same table says 'gsos2' for OS/2 systems.


S. U.


In GNU Emacs 26.2 (build 1, i686-w64-mingw32)
  of 2019-04-13 built on CIRROCUMULUS
Repository revision: fd1b34bfba8f3f6298df47c8e10b61530426f749
Windowing system distributor 'Microsoft Corp.', version 6.1.7601

bug#36357: Wrong Ghostscript program name on MS Win

[Eli Zaretskii]

> From: Sebastian Urban <mrsebastianurban@gmail.com>
> Date: Mon, 24 Jun 2019 18:04:41 +0200
> 
> Variable 'doc-view-ghostscript-program' has value - 'gs' - which is OK
> for Unix and VMS, but NOT OK for MS Windows.  It should be 'gswin32c'.
> For details look at the table in "How to Use Ghostscript", chapter
> "2.1 Help at the command line: gs -h".
> 
> Perhaps it should be done as list of choice, like in case of
> 'tex-dvi-view-command'?
> 
> Or as S. Monnier wrote: "(...) the default could simply
> (executable-find "gs") and (executable-find "gswin32c") and use
> whichever was found (...)".
> 
> Also the same table says 'gsos2' for OS/2 systems.

Tassilo, any objections to such a change?  It sounds TRT to me, but I
don't use these features, and don't have Ghostscript installed.

Thanks.

bug#36357: Wrong Ghostscript program name on MS Win

[Tassilo Horn]

No objections from my side.

Bye,
Tassilo


On July 6, 2019 10:13:59 AM Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Sebastian Urban <mrsebastianurban@gmail.com>
>> Date: Mon, 24 Jun 2019 18:04:41 +0200
>> 
>> Variable 'doc-view-ghostscript-program' has value - 'gs' - which is OK
>> for Unix and VMS, but NOT OK for MS Windows.  It should be 'gswin32c'.
>> For details look at the table in "How to Use Ghostscript", chapter
>> "2.1 Help at the command line: gs -h".
>> 
>> Perhaps it should be done as list of choice, like in case of
>> 'tex-dvi-view-command'?
>> 
>> Or as S. Monnier wrote: "(...) the default could simply
>> (executable-find "gs") and (executable-find "gswin32c") and use
>> whichever was found (...)".
>> 
>> Also the same table says 'gsos2' for OS/2 systems.
>
> Tassilo, any objections to such a change?  It sounds TRT to me, but I
> don't use these features, and don't have Ghostscript installed.
>
> Thanks.
>

bug#36357: Wrong Ghostscript program name on MS Win

[Eli Zaretskii]

> From: Sebastian Urban <mrsebastianurban@gmail.com>
> Date: Mon, 24 Jun 2019 18:04:41 +0200
> 
> Variable 'doc-view-ghostscript-program' has value - 'gs' - which is OK
> for Unix and VMS, but NOT OK for MS Windows.  It should be 'gswin32c'.

Fixed, thanks.

> Also the same table says 'gsos2' for OS/2 systems.

Emacs doesn't currently support building and/or running on OS/2.  We
don't have a system-type value for that platform.

bug#36357: Wrong Ghostscript program name on MS Win

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> CC: <36357@debbugs.gnu.org>
> Date: Sat, 06 Jul 2019 13:29:57 +0200
> 
> No objections from my side.

Thanks, I've made the proposed change.

bug#36357: Wrong Ghostscript program name on MS Win

[Sebastian Urban]

>> as I found out recently, adding only gswin32c was half of the      
>> problem.  After upgrading to 64bit OS and installing Ghostscript   
>> 64bit, there was no gswin32c.exe in the "bin" folder, only         
>> gswin64.exe and gswin64c.exe.  They forgot(?) to add it to the     
>> table in "Use" documentation, i.e. "gswin32c or gswin64c", instead 
>> of only "gswin32c", although they pointed this out in "Install"    
>> documentation                                                      
>> (https://www.ghostscript.com/doc/9.51/Install.htm#General_Windows).
>> So I think another "if" is needed.                                 
>                                                                      
> What "if" did you have in mind?  Emacs cannot know which version of 
> Ghostscript is installed, and there's no way I know of to code a    
> reasonable condition for that.                                      

Whether the OS is 64bit or 32bit, or if this is not possible or
difficult, then maybe 'system-configuration' variable.  It's not
perfect, because for example someone can install 32bit GS on 64bit OS,
but most probably - on 64bit Win someone will use 64bit Emacs and
64bit GS.  This doesn't solve the problem, but better defaults are
better defaults.

As an simpler alternative, it could be changed to 'gswin64c', because
these days people are using 64bit versions usually.

> However, the variable is a defcustom, so every user can customize it
> to the value which fits their system, if the default doesn't.       

Of course, but this is plan B.

bug#36357: Wrong Ghostscript program name on MS Win

[Eli Zaretskii]

> Cc: 36357@debbugs.gnu.org
> From: Sebastian Urban <mrsebastianurban@gmail.com>
> Date: Wed, 18 Mar 2020 18:26:31 +0100
> 
> > What "if" did you have in mind?  Emacs cannot know which version of 
> > Ghostscript is installed, and there's no way I know of to code a    
> > reasonable condition for that.                                      
> 
> Whether the OS is 64bit or 32bit

A 64-bit OS can perfectly well run 32-bit executables.

> This doesn't solve the problem, but better defaults are better
> defaults.

I'm not convinced this is a better default.  My 64-bit Windows system
is full of 32-bit executables, both those that I compiled and those I
did not.  If your proposal is a better default, how come no one
complained about this?

bug#36357: Wrong Ghostscript program name on MS Win

[Sebastian Urban]

 > I'm not convinced this is a better default.  My 64-bit Windows
 > system is full of 32-bit executables, both those that I compiled and
 > those I did not.

Well you're not a beginner and you can easily change settings, because
you know which and how, and we're talking about defaults, which should
help newcomers as much as possible.

If 64bit OS is in use and the program has two versions - 32bit & 64bit
- user will most likely choose 64bit version of the program.  64bit
software is popular now and leaving (in upcoming Emacs 27) 'gswin32c'
as default is... outdated?

Perhaps something like (idea, not code):

if 'system-configuration' == 64bit
    use gswin64c
else
    use gswin32c

could make setting the default a little bit better.  Maybe there is
better variable for this.

Again, as an alternative, a change to 'gswin64c' from 'gswin32c' would
be also appreciated, as more up-to-date solution.

 > If your proposal is a better default, how come no one complained
 > about this?

They don't use packages that use Ghostscript, don't care that much and
change tool, blame Windows for not working... kind of "who knows". :)

bug#36357: Wrong Ghostscript program name on MS Win

[Sebastian Urban]

Alright, 25 days have passed, and decision (preferably deed) for this
simple bug should be made.

Meanwhile I read initial e-mail for this bug and I found a quote:
 > Or as S. Monnier wrote: "(...) the default could simply
 > (executable-find "gs") and (executable-find "gswin32c") and use
 > whichever was found (...)".
Could this "executable-find" help in this case?

If not, and the condition based on "system-configration" will cause
more problems than it'll solve, then a simple change to "gswin64c"
should still be better option than leaving "gswin32c".


S. U.

bug#36357: Wrong Ghostscript program name on MS Win

[Arash Esbati]

Sebastian Urban <mrsebastianurban@gmail.com> writes:

> Alright, 25 days have passed, and decision (preferably deed) for this
> simple bug should be made.
>
> Meanwhile I read initial e-mail for this bug and I found a quote:
>> Or as S. Monnier wrote: "(...) the default could simply
>> (executable-find "gs") and (executable-find "gswin32c") and use
>> whichever was found (...)".
> Could this "executable-find" help in this case?
>
> If not, and the condition based on "system-configration" will cause
> more problems than it'll solve, then a simple change to "gswin64c"
> should still be better option than leaving "gswin32c".

I don't use doc-view, so I can't really tell, but preview.el (part of
AUCTeX) uses "executable-find".  Applied to
`doc-view-ghostscript-program', it could look like this:

--8<---------------cut here---------------start------------->8---
(defcustom doc-view-ghostscript-program
  (or
   ;; The GS wrapper coming with TeX Live
   (file-name-base (executable-find "rungs"))
   ;; The MikTeX builtin GS
   (let ((gs (executable-find "mgs")))
     ;; Check if mgs is functional for external non-MikTeX apps.
     ;; See http://blog.miktex.org/post/2005/04/07/Starting-mgsexe-at-the-DOS-Prompt.aspx
     ;; N.B.: Link doesn't work no more!
     (when (and gs (= 0 (shell-command
			 (concat (shell-quote-argument gs)
				 " -q -dNODISPLAY -c quit"))))
       (file-name-base gs)))
   ;; Windows Ghostscript
   (file-name-base (executable-find "gswin64c.exe"))
   (file-name-base (executable-find "gswin32c.exe"))
   ;; standard Ghostscript   
   "gs")
  "Program to convert PS and PDF files to PNG."
  :type 'file
  :version "28.1")
--8<---------------cut here---------------end--------------->8---

Best, Arash

bug#36357: Wrong Ghostscript program name on MS Win

[Arash Esbati]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

Arash Esbati <arash@gnu.org> writes:

> I don't use doc-view, so I can't really tell, but preview.el (part of
> AUCTeX) uses "executable-find".  Applied to
> `doc-view-ghostscript-program', it could look like this:

Following up myself, I suggest the patch attached.

@Tassilo: What do you think, does it make sense?

Best, Arash


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Improve-detection-of-Ghostscript-executable.patch --]
[-- Type: text/x-patch, Size: 1564 bytes --]

From 2b7bdf2b905271d1fd7c4d4af8a305ff40a50f05 Mon Sep 17 00:00:00 2001
From: Arash Esbati <arash@gnu.org>
Date: Tue, 21 Apr 2020 15:01:08 +0200
Subject: [PATCH] Improve detection of Ghostscript executable

* lisp/doc-view.el (doc-view-ghostscript-program): Add better
support for detection of Ghostscript executable on non-free
systems.  (bug#36357)
---
 lisp/doc-view.el | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/lisp/doc-view.el b/lisp/doc-view.el
index 8b3d5527f0..eddcd884dd 100644
--- a/lisp/doc-view.el
+++ b/lisp/doc-view.el
@@ -154,13 +154,29 @@ doc-view
 
 (defcustom doc-view-ghostscript-program
   (cond
-   ((memq system-type '(windows-nt ms-dos))
+   ;; The GS wrapper coming with TeX Live
+   ((executable-find "rungs.exe")
+    "rungs")
+   ;; The MikTeX builtin GS
+   ;; Check if mgs is functional for external non-MikTeX apps.  Was
+   ;; available under:
+   ;; http://blog.miktex.org/post/2005/04/07/Starting-mgsexe-at-the-DOS-Prompt.aspx
+   ((and (executable-find "mgs.exe")
+         (= 0 (shell-command
+               (concat (shell-quote-argument (executable-find "mgs.exe"))
+                       " -q -dNODISPLAY -c quit"))))
+    "mgs")
+   ;; Windows Ghostscript
+   ((executable-find "gswin64c.exe")
+    "gswin64c")
+   ((executable-find "gswin32c.exe")
     "gswin32c")
+   ;; Standard Ghostscript
    (t
     "gs"))
   "Program to convert PS and PDF files to PNG."
   :type 'file
-  :version "27.1")
+  :version "28.1")
 
 (defcustom doc-view-pdfdraw-program
   (cond
-- 
2.26.2

bug#36357: Wrong Ghostscript program name on MS Win

[Tassilo Horn]

Hi Arash,

looks right to me. Can you commit for yourself or should I do it for you?

Bye,
Tassilo

Am Di, 21. Apr 2020, um 15:16, schrieb Arash Esbati:
> Arash Esbati <arash@gnu.org> writes:
> 
> > I don't use doc-view, so I can't really tell, but preview.el (part of
> > AUCTeX) uses "executable-find".  Applied to
> > `doc-view-ghostscript-program', it could look like this:
> 
> Following up myself, I suggest the patch attached.
> 
> @Tassilo: What do you think, does it make sense?
> 
> Best, Arash
> 
> 
> Dateianhänge:
> * 0001-Improve-detection-of-Ghostscript-executable.patch

bug#36357: Wrong Ghostscript program name on MS Win

[Arash Esbati]

Hi Tassilo,

"Tassilo Horn" <tsdh@gnu.org> writes:

> looks right to me. Can you commit for yourself or should I do it for
> you?

Thanks for your response.  Please commit since I don't have access to
Emacs repo.  I can only offer to close this bug after your commit :-)

Best, Arash

bug#36357: Wrong Ghostscript program name on MS Win

[Sebastian Urban]

Thanks Arash for also looking into it, but part of the patch seems to
be unnecessary.  I'm writing about these lines:

# ;; The GS wrapper coming with TeX Live
# ((executable-find "rungs.exe")
#  "rungs")
# ;; The MikTeX builtin GS
# ;; Check if mgs is functional for external non-MikTeX apps.  Was
# ;; available under:
# ;; 
http://blog.miktex.org/post/2005/04/07/Starting-mgsexe-at-the-DOS-Prompt.aspx
# ((and (executable-find "mgs.exe")
#       (= 0 (shell-command
#             (concat (shell-quote-argument (executable-find "mgs.exe"))
#                     " -q -dNODISPLAY -c quit"))))
#  "mgs")

They probably belong to AUCTeX only and do nothing in Doc-view.  So
they should be removed.

I also looked into doc-view.el and right under this variable I found
"defcustom doc-view-pdfdraw-program", which looks exactly like
something we are (may be?) looking for.

To sum things up "doc-view-ghostscript-program" could look like this:

(defcustom doc-view-ghostscript-program
   (cond
    ((executable-find "gswin64c.exe") "gswin64c")
    ((executable-find "gswin32c.exe") "gswin32c")
    (t "gs"))
   "Program to convert PS and PDF files to PNG."
   :type 'file
   :version "27.1")

PS If it's alright could it be installed in 27.1?  It's not that big
of a change.


S. U.

bug#36357: Wrong Ghostscript program name on MS Win

[Tassilo Horn]

Sebastian Urban <mrsebastianurban@gmail.com> writes:

> To sum things up "doc-view-ghostscript-program" could look like this:
>
> (defcustom doc-view-ghostscript-program
>   (cond
>    ((executable-find "gswin64c.exe") "gswin64c")
>    ((executable-find "gswin32c.exe") "gswin32c")
>    (t "gs"))
>   "Program to convert PS and PDF files to PNG."
>   :type 'file
>   :version "27.1")

Why not use the return value of executable-find?  Is there a benefit in
using the non-qualified executable?  I've seen that there are other such
occurrences is doc-view.el... I'd just go with:

(defcustom doc-view-ghostscript-program
  (or
   (executable-find "gswin64c")
   (executable-find "gswin32c")
   "gs")
  "Program to convert PS and PDF files to PNG."
  :type 'file
  :version "27.1")

> PS If it's alright could it be installed in 27.1?  It's not that big
> of a change.

I tend to agree but that's to be decided by Eli (in Cc).  That would be
the complete diff from the current version:

--8<---------------cut here---------------start------------->8---
diff -u --label /home/horn/Repos/el/emacs/lisp/doc-view.el --label \#\<buffer\ doc-view.el\> /home/horn/Repos/el/emacs/lisp/doc-view.el /tmp/buffer-content-MettTK
--- /home/horn/Repos/el/emacs/lisp/doc-view.el
+++ #<buffer doc-view.el>
@@ -153,11 +153,10 @@
   :prefix "doc-view-")
 
 (defcustom doc-view-ghostscript-program
-  (cond
-   ((memq system-type '(windows-nt ms-dos))
-    "gswin32c")
-   (t
-    "gs"))
+  (or
+   (executable-find "gswin64c")
+   (executable-find "gswin32c")
+   "gs")
   "Program to convert PS and PDF files to PNG."
   :type 'file
   :version "27.1")
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

bug#36357: Wrong Ghostscript program name on MS Win

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Arash Esbati <arash@gnu.org>,  36357@debbugs.gnu.org, Eli Zaretskii
>  <eliz@gnu.org>
> Date: Tue, 21 Apr 2020 20:34:41 +0200
> 
> > PS If it's alright could it be installed in 27.1?  It's not that big
> > of a change.
> 
> I tend to agree but that's to be decided by Eli (in Cc).

I don't really understand how changing a defcustom's value can be
urgent, but go for it.

bug#36357: Wrong Ghostscript program name on MS Win

[Arash Esbati]

Hi Sebastian,

Sebastian Urban <mrsebastianurban@gmail.com> writes:

> Thanks Arash for also looking into it, but part of the patch seems to
> be unnecessary.  I'm writing about these lines:
>
> # ;; The GS wrapper coming with TeX Live
> # ((executable-find "rungs.exe")
> #  "rungs")
> # ;; The MikTeX builtin GS
> # ;; Check if mgs is functional for external non-MikTeX apps.  Was
> # ;; available under:
> # ;;
>      http://blog.miktex.org/post/2005/04/07/Starting-mgsexe-at-the-DOS-Prompt.aspx
> # ((and (executable-find "mgs.exe")
> #       (= 0 (shell-command
> #             (concat (shell-quote-argument (executable-find "mgs.exe"))
> #                     " -q -dNODISPLAY -c quit"))))
> #  "mgs")
>
> They probably belong to AUCTeX only and do nothing in Doc-view.  So
> they should be removed.

I tend not to agree here as I've seen people who only have
TeXlive/MikTeX installed on Windows which cater for a minimal
Ghostscript.  Those people could benefit from the code above.  OTOH, I
don't have a strong opinion on this, so I'm fine with whatever Tassilo
pushes to Emacs repo.

Best, Arash

bug#36357: Wrong Ghostscript program name on MS Win

[Tassilo Horn]

Arash Esbati <arash@gnu.org> writes:

Hi again,

> I tend not to agree here as I've seen people who only have
> TeXlive/MikTeX installed on Windows which cater for a minimal
> Ghostscript.  Those people could benefit from the code above.

I think that's a valid argument.  So that's what I would go for.

--8<---------------cut here---------------start------------->8---
@@ -153,14 +153,27 @@ doc-view
   :prefix "doc-view-")
 
 (defcustom doc-view-ghostscript-program
-  (cond
-   ((memq system-type '(windows-nt ms-dos))
-    "gswin32c")
-   (t
-    "gs"))
+  (or
+   ;; Standard Ghostscript
+   (executable-find "gs")
+   ;; Windows Ghostscript
+   (executable-find "gswin64c")
+   (executable-find "gswin32c")
+   ;; The GS wrapper coming with TeX Live
+   (executable-find "rungs")
+   ;; The MikTeX builtin GS Check if mgs is functional for external
+   ;; non-MikTeX apps.  Was available under:
+   ;; http://blog.miktex.org/post/2005/04/07/Starting-mgsexe-at-the-DOS-Prompt.aspx
+   (when-let ((mgs (executable-find "mgs")))
+     (when (= 0 (shell-command
+                 (concat (shell-quote-argument mgs)
+                         " -q -dNODISPLAY -c quit")))
+       mgs))
+   ;; Standard Ghostscript as fallback
+   "gs")
   "Program to convert PS and PDF files to PNG."
   :type 'file
-  :version "27.1")
+  :version "28.1")
--8<---------------cut here---------------end--------------->8---

We should ask ourselves if the order is ok, i.e., if on systems where
multiple gs installs are available, the "best" one gets selected.  So is
it correct to prefer gswin64c over gswin32c and that over rungs and mgs?

Another question: You both used executable-find with exe file extension.
Was that intended?  I mean, it makes sure we don't falsely set some
"gs.bat" or "gs.cmd" which might have nothing to do with GhostScript.
Is that a real danger?  If so, we need the OS distinction again.

Bye,
Tassilo

bug#36357: Wrong Ghostscript program name on MS Win

[Sebastian Urban]

 >> I tend not to agree here as I've seen people who only have
 >> TeXlive/MikTeX installed on Windows which cater for a minimal
 >> Ghostscript.  Those people could benefit from the code above.
 >
 > I think that's a valid argument.  So that's what I would go for.

I would say that this is not very "default" (default = normal
Ghostscript installation) setup, in which case user should set up
desired setting manually.  But it's your call, I won't object here.

About the code:

1. There is:
+   ;; Standard Ghostscript
+   (executable-find "gs")
...
+   ;; Standard Ghostscript as fallback
+   "gs")

What for is first "Standard Ghostscript"?  There is no "gs" in
Windows, and fallback will work for Unix.

2. Version is set to 28.1, so... we are skipping 27.1?  It's not big
deal for me, but some say: don't put off until tomorrow (28.1) what
you can do today (27.1).

 > We should ask ourselves if the order is ok, i.e., if on systems
 > where multiple gs installs are available, the "best" one gets
 > selected.  So is it correct to prefer gswin64c over gswin32c and
 > that over rungs and mgs?

I think it's OK, because "gswin32/64c" is, as I mentioned earlier -
the default way of setting up GS, and it should have higher priority
as default, as well as 64bits should be higher than 32bits version,
because... well, everything moves towards 64bits, so it is more
up-to-date order.  As for "rungs/mgs" - what is more common "TeX
Live/MikTeX"?

 > Another question: You both used executable-find with exe file
 > extension.  Was that intended?  I mean, it makes sure we don't
 > falsely set some "gs.bat" or "gs.cmd" which might have nothing to do
 > with GhostScript.  Is that a real danger?

"Falsely setting" file with the same name but different extension
crossed my mind.  So, yes we should include extension just to be sure,
that function will find exactly what we are looking for.

 > If so, we need the OS distinction again.

What for?


S. U.

bug#36357: Wrong Ghostscript program name on MS Win

[Tassilo Horn]

Sebastian Urban <mrsebastianurban@gmail.com> writes:

>>> I tend not to agree here as I've seen people who only have
>>> TeXlive/MikTeX installed on Windows which cater for a minimal
>>> Ghostscript.  Those people could benefit from the code above.
>>
>> I think that's a valid argument.  So that's what I would go for.
>
> I would say that this is not very "default" (default = normal
> Ghostscript installation) setup, in which case user should set up
> desired setting manually.

Well, if there is no harm in doing so, I don't see a reason not to
support those non-default setups automatically.  And in my opinion,
having a TeX distro and no manual ghostscript install seems not so
uncommon.

> About the code:
>
> 1. There is:
> +   ;; Standard Ghostscript
> +   (executable-find "gs")
> ...
> +   ;; Standard Ghostscript as fallback
> +   "gs")
>
> What for is first "Standard Ghostscript"?  There is no "gs" in
> Windows, and fallback will work for Unix.

The reason is that I wanted to prefer gs over rungs in case both are
installed (like on my GNU/Linux box).

> 2. Version is set to 28.1, so... we are skipping 27.1?  It's not big
> deal for me, but some say: don't put off until tomorrow (28.1) what
> you can do today (27.1).

Yes, that was wrong and a left-over of Arash's patch where he assumed
the change would go only into master instead of emacs-27.

>> We should ask ourselves if the order is ok, i.e., if on systems where
>> multiple gs installs are available, the "best" one gets selected.  So
>> is it correct to prefer gswin64c over gswin32c and that over rungs
>> and mgs?
>
> I think it's OK, because "gswin32/64c" is, as I mentioned earlier -
> the default way of setting up GS, and it should have higher priority
> as default, as well as 64bits should be higher than 32bits version,
> because... well, everything moves towards 64bits, so it is more
> up-to-date order.  As for "rungs/mgs" - what is more common "TeX
> Live/MikTeX"?

I think, this doesn't matter.  Nobody has both TeXLive and MikTeX
installed in parallel.

>> Another question: You both used executable-find with exe file
>> extension.  Was that intended?  I mean, it makes sure we don't
>> falsely set some "gs.bat" or "gs.cmd" which might have nothing to do
>> with GhostScript.  Is that a real danger?
>
> "Falsely setting" file with the same name but different extension
> crossed my mind.  So, yes we should include extension just to be sure,
> that function will find exactly what we are looking for.

Ok.

>> If so, we need the OS distinction again.
>
> What for?

Because I've thought it would be nice to test for (executable-find
"rungs") on any platform but (executable-find "rungs.exe") will of
course work only on Windows.  On the other hand, rungs on non-windows
platforms just calls gs anyway, so we can skip that there.

So if nobody complains, I'll commit the version below later.

--8<---------------cut here---------------start------------->8---
@@ -155,9 +155,21 @@ doc-view
 (defcustom doc-view-ghostscript-program
   (cond
    ((memq system-type '(windows-nt ms-dos))
-    "gswin32c")
-   (t
-    "gs"))
+    (or
+     ;; Windows Ghostscript
+     (executable-find "gswin64c.exe")
+     (executable-find "gswin32c.exe")
+     ;; The GS wrapper coming with TeX Live
+     (executable-find "rungs.exe")
+     ;; The MikTeX builtin GS Check if mgs is functional for external
+     ;; non-MikTeX apps.  Was available under:
+     ;; http://blog.miktex.org/post/2005/04/07/Starting-mgsexe-at-the-DOS-Prompt.aspx
+     (when-let ((mgs (executable-find "mgs.exe")))
+       (when (= 0 (shell-command
+                   (concat (shell-quote-argument mgs)
+                           " -q -dNODISPLAY -c quit")))
+         mgs))))
+   (t "gs"))
   "Program to convert PS and PDF files to PNG."
   :type 'file
   :version "27.1")
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

bug#36357: Wrong Ghostscript program name on MS Win

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Wed, 22 Apr 2020 11:05:24 +0200
> Cc: Sebastian Urban <mrsebastianurban@gmail.com>, 36357@debbugs.gnu.org
> 
> Another question: You both used executable-find with exe file extension.
> Was that intended?  I mean, it makes sure we don't falsely set some
> "gs.bat" or "gs.cmd" which might have nothing to do with GhostScript.
> Is that a real danger?  If so, we need the OS distinction again.

It is IME wrong and user-unfriendly to refuse to load foo.bat or
foo.cmd and insist on running foo.exe.  The reason is that having a
batch file that shadows a .exe program is the easiest way of
"customizing" programs, like adding default arguments, setting up a
special PATH value, etc.  I need to do that quite a lot, especially
when working in fascist domains where the admins think they know
better what I need and what I don't.  So I wouldn't like it if Emacs,
of all programs, would disallow me to have a gs64winc.cmd file when
the .exe somehow needs some help to run correctly.

Therefore, my suggestion is to use just "foo" without any extension.
If the user has a foo.bat that is found before foo.exe, it is their
misconfiguration, and they need to fix that locally.  However, more
often than not, the user _wants_ the batch file to run instead, and we
shouldn't punish users who know what they are doing on behalf of those
who don't.

Just my $0.02, feel free to disregard.

P.S. This is not Windows-specific, IMO: the same is true on Posix
systems where a shell script can "shadow" a program.

bug#36357: Wrong Ghostscript program name on MS Win

[Eli Zaretskii]

> From: Sebastian Urban <mrsebastianurban@gmail.com>
> Date: Wed, 22 Apr 2020 12:07:54 +0200
> Cc: 36357@debbugs.gnu.org
> 
>  > Another question: You both used executable-find with exe file
>  > extension.  Was that intended?  I mean, it makes sure we don't
>  > falsely set some "gs.bat" or "gs.cmd" which might have nothing to do
>  > with GhostScript.  Is that a real danger?
> 
> "Falsely setting" file with the same name but different extension
> crossed my mind.  So, yes we should include extension just to be sure,
> that function will find exactly what we are looking for.

We don't know what we are looking for; only the end user does.  Even
Windows allows to rename executable files, so there's nothing magic in
the name gswin64c.exe, the actual program can be called anything and
can have any valid executable extension.  Please leave the user the
freedom of starting Ghostscript via a batch file, if they so wish.

bug#36357: Wrong Ghostscript program name on MS Win

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> Another question: You both used executable-find with exe file
>> extension.  Was that intended?  I mean, it makes sure we don't
>> falsely set some "gs.bat" or "gs.cmd" which might have nothing to do
>> with GhostScript.  Is that a real danger?  If so, we need the OS
>> distinction again.
>
> It is IME wrong and user-unfriendly to refuse to load foo.bat or
> foo.cmd and insist on running foo.exe.  The reason is that having a
> batch file that shadows a .exe program is the easiest way of
> "customizing" programs, like adding default arguments, setting up a
> special PATH value, etc.

I agree, and I will omit the extension at least for gs{64,32}winc.  The
question is more how likely it is that some user has her own "rungs"
command/batch script which has nothing to do with "running GhostScript"
and then we call it in doc-view.  I mean, "rungs" is at least an English
word...

> P.S. This is not Windows-specific, IMO: the same is true on Posix
> systems where a shell script can "shadow" a program.

Sure, but I guess that users on POSIX systems take a bit more care in
naming their scripts, i.e., if their ~/bin/foo shadows /usr/bin/foo
that's most probably wanted for the very reasons you described.  On
Windows, where most programs install everything they need in their own
installation directory instead of assuming the dependencies were
installed individually (by a package manager), such a habit of PATH
hygiene (unambiguous naming xor shadowing on purpose) might not be so
common.

Bye,
Tassilo

bug#36357: Wrong Ghostscript program name on MS Win

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: arash@gnu.org,  mrsebastianurban@gmail.com,  36357@debbugs.gnu.org
> Date: Wed, 22 Apr 2020 16:14:41 +0200
> 
> > It is IME wrong and user-unfriendly to refuse to load foo.bat or
> > foo.cmd and insist on running foo.exe.  The reason is that having a
> > batch file that shadows a .exe program is the easiest way of
> > "customizing" programs, like adding default arguments, setting up a
> > special PATH value, etc.
> 
> I agree, and I will omit the extension at least for gs{64,32}winc.  The
> question is more how likely it is that some user has her own "rungs"
> command/batch script which has nothing to do with "running GhostScript"
> and then we call it in doc-view.  I mean, "rungs" is at least an English
> word...

I think it's unlikely.  E.g., on my system there's not a single file
that goes by the name "rungs" with any extension.  Another data point
is that package authors generally try to choose names for their
programs that don't clash with existing popular programs.  So I think
you could stop worrying about this.

bug#36357: Wrong Ghostscript program name on MS Win

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tassilo Horn <tsdh@gnu.org>
>> Cc: arash@gnu.org,  mrsebastianurban@gmail.com,  36357@debbugs.gnu.org
>> Date: Wed, 22 Apr 2020 16:14:41 +0200
>> 
>> > It is IME wrong and user-unfriendly to refuse to load foo.bat or
>> > foo.cmd and insist on running foo.exe.  The reason is that having a
>> > batch file that shadows a .exe program is the easiest way of
>> > "customizing" programs, like adding default arguments, setting up a
>> > special PATH value, etc.
>> 
>> I agree, and I will omit the extension at least for gs{64,32}winc.  The
>> question is more how likely it is that some user has her own "rungs"
>> command/batch script which has nothing to do with "running GhostScript"
>> and then we call it in doc-view.  I mean, "rungs" is at least an English
>> word...
>
> I think it's unlikely.  E.g., on my system there's not a single file
> that goes by the name "rungs" with any extension.  Another data point
> is that package authors generally try to choose names for their
> programs that don't clash with existing popular programs.  So I think
> you could stop worrying about this.

Ok, thank you all, that's the patch I've eventually pushed to emacs-27.

--8<---------------cut here---------------start------------->8---
@@ -155,9 +155,21 @@ doc-view
 (defcustom doc-view-ghostscript-program
   (cond
    ((memq system-type '(windows-nt ms-dos))
-    "gswin32c")
-   (t
-    "gs"))
+    (or
+     ;; Windows Ghostscript
+     (executable-find "gswin64c")
+     (executable-find "gswin32c")
+     ;; The GS wrapper coming with TeX Live
+     (executable-find "rungs")
+     ;; The MikTeX builtin GS Check if mgs is functional for external
+     ;; non-MikTeX apps.  Was available under:
+     ;; http://blog.miktex.org/post/2005/04/07/Starting-mgsexe-at-the-DOS-Prompt.aspx
+     (when-let ((mgs (executable-find "mgs")))
+       (when (= 0 (shell-command
+                   (concat (shell-quote-argument mgs)
+                           " -q -dNODISPLAY -c quit")))
+         mgs))))
+   (t "gs"))
   "Program to convert PS and PDF files to PNG."
   :type 'file
   :version "27.1")
--8<---------------cut here---------------end--------------->8---

Eli, I guess some brave soul merges from emacs-27 to master from time to
time, so there's nothing more I have to do, right?

Bye,
Tassilo