The method ImageMagickToolkit::imagemagickExec() when executed on windows, uses a "'start' workaround" to prevent a cmd shell from popping up. However, if the executed commandline contains an error, e.g. pointing to a non existing executable. fgets($pipes[1]) will block the request and will never return. When the cmdline gets executed in a command prompt a error popup appears waiting to be clicked to be dismissed. Apparently the process will be waiting on a similar event in the above case which can never occur.
So we should try to get rid of this start workaround without getting a cmd prompt window popped up on each call to imagemagickExec().
I am still trying some alternatives, to come up with the best approach.
- just not using "start ... /B ..." works fine for me (and no window popping up, but I will dive deeper into the history of when and why it was added).
- the related issue mentions another possible solution.
- ... ??? (other approaches).
Note the related issue is for 7.x and so I did not want to hijack that one for a 8.x solution.
Comments
Comment #2
fietserwinAdded the 7.x equivalent of this issue as related issue.
Comment #3
fietserwinThe 'bypass_shell" option is not going to work if one relies on the PATH to find convert.exe. Moreover to find dlls, the program should be started in the bin dir of IM. This is not always possible and it makes no sense if we allow to depend on PATH for the executable itself.
Comment #4
mondrakeCan anybody check if the latest patch in #2911289: Use Symfony process component instead of proc_open would solve this issue?
Comment #5
mondrakeI finally managed to get a Windows test environment on AppVeyor where I can reproduce the error, https://ci.appveyor.com/project/mondrake/imagemagick/build/1.0.75
#2911289: Use Symfony process component instead of proc_open seems in the right direction to fix it, see https://ci.appveyor.com/project/mondrake/imagemagick/build/1.0.73
Closing as duplicate.