RSS/Atom feed Twitter
Site is read-only, email is disabled

GIMP won't quit

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

12 of 12 messages available
Toggle history

Please log in to manage your subscriptions.

GIMP won't quit Roger Penn 26 Feb 22:15
  GIMP won't quit "Aurimas Ju 26 Feb 23:27
   GIMP won't quit Sven Neumann 27 Feb 19:59
   GIMP won't quit Roger Penn 01 Mar 05:00
    GIMP won't quit jcupitt@gmail.com 01 Mar 16:42
     GIMP won't quit jcupitt@gmail.com 01 Mar 16:47
      GIMP won't quit Roger Penn 02 Mar 01:47
     GIMP won't quit Kevin Cozens 01 Mar 22:25
     GIMP won't quit Graeme Gill 02 Mar 12:52
      GIMP won't quit jcupitt@gmail.com 02 Mar 13:13
       GIMP won't quit Graeme Gill 02 Mar 22:14
     GIMP won't quit Sven Neumann 05 Mar 14:34
Roger Penn
2011-02-26 22:15:07 UTC (over 13 years ago)

GIMP won't quit

Hey all,

I know this is more of a user question, but I don't think I'm going to find anyone that's going to be able to answer it other than here.

I'm using the GIMP to create custom graphics on the fly for a CMS by calling the script from the web page through ASP.NET. Now, I wouldn't blame anyone for saying, "Stop right there. That's your problem."

The problem I'm having is that I'm calling the script like this: gimp -i -b "myscript" -b "gimp-quit 0"

Immediately upon firing up the script, the Task Manger reports creation of a gimp.exe process. Then it forks another gimp.exe process. This one fires up script-fu.exe, does its thing, dies, and kills the second gimp.exe. However the first one stays running and will not quit.

On a server with hundreds of clients creating images with these scripts, within an hour I can be left with a few hundred gimp.exe processes running, which just about takes the server down!

So I have two questions:

1) Why is calling the script this way (which, btw, is the way it suggests on http://www.gimp.org/tutorials/Basic_Batch/) firing two gimp.exe processes and only killing one of them?
2) On a server where a hundred of these scripts could be running at one time, how does gimp-quit know which process to kill?

Thanks,

Roger Penn Ignoramus extrordinaire

"Aurimas Ju
2011-02-26 23:27:57 UTC (over 13 years ago)

GIMP won't quit

Hi,

On Sun, Feb 27, 2011 at 12:15 AM, Roger Penn wrote:

I'm using the GIMP to create custom graphics on the fly for a CMS by calling the script from the web page through ASP.NET.

For what you want to do, Script-fu server should be the best option. See http://docs.gimp.org/en/gimp-filters-script-fu.html (Section 10.6.4. Start Server).

Sven Neumann
2011-02-27 19:59:42 UTC (over 13 years ago)

GIMP won't quit

On Sun, 2011-02-27 at 01:27 +0200, Aurimas Juška wrote:

Hi,

On Sun, Feb 27, 2011 at 12:15 AM, Roger Penn wrote:

I'm using the GIMP to create custom graphics on the fly for a CMS by calling the script from the web page through ASP.NET.

For what you want to do, Script-fu server should be the best option. See http://docs.gimp.org/en/gimp-filters-script-fu.html (Section 10.6.4. Start Server).

I don't think so. As far as I can see Script-Fu won't handle multiple scripts running simultaneously.

Sven

Roger Penn
2011-03-01 05:00:10 UTC (over 13 years ago)

GIMP won't quit

Thanks for the suggestion. It sounds like that is the best solution. However, not being a programmer myself and not even having the python script they mention (running on Windoze we just download the pre-compiled binaries) I wouldn't have the first clue how to implement a script-fu server in the environment we use.

The method of calling it that I mentioned always worked fine with the GIMP 2.2. It was only after the upgrade to 2.6 that it started spawning the extra process and leaving it behind, and I'm not sure what the difference is. So I will look into using the script-fu server solution in the future after I can work out all the how's and so-forth, but for now if anyone knows the inner workings of gimp-quit or why calling gimp.exe from the command line forks two gimp processes I'd sure be grateful for some insight. Thanks.

2011/2/26 Aurimas Juška

Hi,

On Sun, Feb 27, 2011 at 12:15 AM, Roger Penn wrote:

I'm using the GIMP to create custom graphics on the fly for a CMS by

calling

the script from the web page through ASP.NET.

For what you want to do, Script-fu server should be the best option. See http://docs.gimp.org/en/gimp-filters-script-fu.html (Section 10.6.4. Start Server).

jcupitt@gmail.com
2011-03-01 16:42:54 UTC (over 13 years ago)

GIMP won't quit

On 1 March 2011 05:00, Roger Penn wrote:

work out all the how's and so-forth, but for now if anyone knows the inner workings of gimp-quit or why calling gimp.exe from the command line forks two gimp processes I'd sure be grateful for some insight. Thanks.

I might be able to help a little on the forks-two-processes thing. My app does this as well, because Windows distinguishes between command-line and GUI .exes.

When Windows launches a program from the shell, it checks a flag in the .exe to see if this is a command-line or a GUI program. If it's been tagged as a GUI program, it just gets started, but if it's been tagged as command-line, Windows will pop up a console and use that to display stdin and accept stdout for the program.

Conversely, if you start a command-line program from the command-line, command.com will display stdout, pipe stdin, and wait until the program terminates before showing the prompt again. If you run a GUI program from the command-line, stdin/stdout for the program go nowhere and command.com will offer the prompt again immediately without waiting for the program to finish.

As a result of this strange design, it's impossible on Windows to write a .exe that can be used smoothly both from the command-line and from the desktop.

The usual solution people recommend is to have a tiny wrapper .exe for command-line work. This is a program which is tagged as CLI and which when run starts the GUI .exe, linking that program's stdin/stdout back to the calling command.com, and then waiting for the GUI .exe to exit.

So it sounds to me, though I've not checked and this is just a guess, that the Windows wrapper .exe is not terminating correctly in the new gimp. Also, this is from memory of looking into this a few years ago, I've probably messed up the details, argh.

John

jcupitt@gmail.com
2011-03-01 16:47:53 UTC (over 13 years ago)

GIMP won't quit

On 1 March 2011 16:42, wrote:

So it sounds to me, though I've not checked and this is just a guess, that the Windows wrapper .exe is not terminating correctly in the new gimp. Also, this is from memory of looking into this a few years ago, I've probably messed up the details, argh.

Just in case it is the wrapper that's broken, here's the wrapper program I use, written for me by a Windows expert friend:

https://github.com/jcupitt/nip2/blob/master/src/nip2-cli.c

Perhaps it might be useful.

John

Kevin Cozens
2011-03-01 22:25:33 UTC (over 13 years ago)

GIMP won't quit

jcupitt@gmail.com wrote:

I might be able to help a little on the forks-two-processes thing. My app does this as well, because Windows distinguishes between command-line and GUI .exes.

Could you have Windows start GIMP as a GUI program but pass -i to GIMP to stop it from opening up its windows?

Roger Penn
2011-03-02 01:47:52 UTC (over 13 years ago)

GIMP won't quit

Your mention of a wrapper made me wonder, "what? where?" I don't believe there was any such thing in the GIMP 2.0. So I looked in the bin directory and lo and behold! gimp-console-2.6.exe. Apparently now there are separate executables for GUI and console use. Either there weren't before, or the pre-compiled binary distro I used didn't include the console version. I called this from the web page instead of gimp-2.6.exe and problem solved! I think the official GIMP documentation needs to be updated to reflect this.

All the same, thanks for sharing your friend's wrapper. I will check it out just in case there are further issues, and it may come in handy for someone else as well!

Thanks everyone for taking the time to be so helpful and for the really useful advice.

On Tue, Mar 1, 2011 at 8:47 AM, wrote:

On 1 March 2011 16:42, wrote:

So it sounds to me, though I've not checked and this is just a guess, that the Windows wrapper .exe is not terminating correctly in the new gimp. Also, this is from memory of looking into this a few years ago, I've probably messed up the details, argh.

Just in case it is the wrapper that's broken, here's the wrapper program I use, written for me by a Windows expert friend:

https://github.com/jcupitt/nip2/blob/master/src/nip2-cli.c

Perhaps it might be useful.

John _______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Graeme Gill
2011-03-02 12:52:29 UTC (over 13 years ago)

GIMP won't quit

jcupitt@gmail.com wrote:

As a result of this strange design, it's impossible on Windows to write a .exe that can be used smoothly both from the command-line and from the desktop.

I've written a couple of applications that run from the command line and happily throw up windows and interact with the desktop on MSWin (and OS X and Linux). There's nothing special about it - any normal command line main() program with stdin/out/err can create windows by calling CreateWindow().

Graeme Gill.

jcupitt@gmail.com
2011-03-02 13:13:13 UTC (over 13 years ago)

GIMP won't quit

On 2 March 2011 12:52, Graeme Gill wrote:

jcupitt@gmail.com wrote:

As a result of this strange design, it's impossible on Windows to write a .exe that can be used smoothly both from the command-line and from the desktop.

I've written a couple of applications that run from the command line and happily throw up windows and interact with the desktop on MSWin (and OS X and Linux). There's nothing special about it - any normal command line main() program with stdin/out/err can create windows by calling CreateWindow().

Yes, but if they are tagged as CLI .exes (which they will be if you can run them from the command-line and the CLI blocks until they exit) when you run them from the Windows shell by double-clicking an icon you will get an annoying extra console window linked to stdin/stdout.

John

Graeme Gill
2011-03-02 22:14:33 UTC (over 13 years ago)

GIMP won't quit

jcupitt@gmail.com wrote:

Yes, but if they are tagged as CLI .exes (which they will be if you can run them from the command-line and the CLI blocks until they exit) when you run them from the Windows shell by double-clicking an icon you will get an annoying extra console window linked to stdin/stdout.

You can use stdio from a WinMain application if you:

AttachConsole(ATTACH_PARENT_PROCESS); freopen("CONOUT$","wb",stdout);
etc.

so that it runs without a console normally, but uses one if launched from the command line.

Graeme Gill.

Sven Neumann
2011-03-05 14:34:51 UTC (over 13 years ago)

GIMP won't quit

On Tue, 2011-03-01 at 16:42 +0000, jcupitt@gmail.com wrote:

On 1 March 2011 05:00, Roger Penn wrote:

work out all the how's and so-forth, but for now if anyone knows the inner workings of gimp-quit or why calling gimp.exe from the command line forks two gimp processes I'd sure be grateful for some insight. Thanks.

I might be able to help a little on the forks-two-processes thing. My app does this as well, because Windows distinguishes between command-line and GUI .exes.

When Windows launches a program from the shell, it checks a flag in the .exe to see if this is a command-line or a GUI program. If it's been tagged as a GUI program, it just gets started, but if it's been tagged as command-line, Windows will pop up a console and use that to display stdin and accept stdout for the program.

Conversely, if you start a command-line program from the command-line, command.com will display stdout, pipe stdin, and wait until the program terminates before showing the prompt again. If you run a GUI program from the command-line, stdin/stdout for the program go nowhere and command.com will offer the prompt again immediately without waiting for the program to finish.

As a result of this strange design, it's impossible on Windows to write a .exe that can be used smoothly both from the command-line and from the desktop.

Which is why GIMP ships two binaries. A UI version called gimp.exe and a command-line tool called gimp-console.exe. The latter does not provide any user interface and doesn't even link with GTK+.

Sven