#24 bin/gimp fails if Gimp.app have not been started

closed-invalid
nobody
None
5
2010-03-27
2010-02-26
No

Hi,

If you try to run bin/gimp from CLI without having launched Gimp.app before, it fails. The problem is that "/tmp/skl/" directory don't exists and so it don't find both "dbus-lunch" and "gimp-2.6" executables in PATH, and of course the needed symlinks.

If you manually lunch Gimp.app, the directory is created and following invocations of bin/gimp succeeds. As I'm using Gimp for an automated assets building pipeline, this is impractical.

It's hard to update bin/gimp script so that it can create the needed directory and symlinks if missing?

Regards,
Daniele

Discussion

  • If you want to launch GIMP from CLI, use the script '/Applications/Gimp.app/Contents/Resources/start' or run the binary '/Application/Gimp.app/Contents/MacOS/Gimp'.

     
  • I don't want to lunch the "graphical" GIMP, I use GIMP from CLI in batch mode to automatically execute custom scripts to process images with no user interaction, something like:

    gimp -i -c --batch-interpreter=python-fu-eval -b "execfile ('myscript.py'); myfunc('input.xcf', 'output.png')" -b "pdb.gimp_quit (0)"

    Those instructions are in a sort of Makefile used to build a lot of assets, the GUI don't have to start otherwise the process is no more automatic.

     
  • ~suv
    ~suv
    2010-02-27

    Using '/Applications/Gimp.app/Contents/Resources/script' doesn't necessarily open the GUI if called from the command line. I use it (rather - a slightly modified copy of it, located in a folder that is included in $PATH) to call gimp from inside Inkscape for export extensions as well as to externally edit linked images in the SVG document.

    just test it e.g. with:

    /Applications/Gimp.app/Contents/Resources/script --version

    If you don't like to use a wrapper script for the gimp binary why don't you install the unix-style command line version of gimp via MacPorts?

     
  • Now I'm on a Mac. You are right, "Resources/script" works. Unfortunately I need to modify it because it's a little too verbose and changes the working directory (that I need to keep due the build system). But it's a good starting point.

    Those are the modifications to remove the verbosity (are all redirections of standard error to /dev/null):

    File "script", line 10:

    cd - > /dev/null

    File "bin/help-locale", line 57:

    INSTALLED=`eval find "$HOME/Library/Application\ Support/Gimp/help" -name "gimp-help-index.html 2> /dev/null"`

    File "bin/set-fontsize", line 23:

    DPI=`defaults read org.x.X11 dpi 2> /dev/null`

    And to avoid the change of working directory when called from CLI, line 36 of "script" must be substituted with:

    if [ -z "$1" ]; then
    cd ~/
    fi

    this preserve the default behavior when GIMP is lunched using Spotlight or the icon but preserve the current working directory if invoked from CLI with some arguments.

    I hope you can embed those modifications on trunk.

    Regards,
    Daniele

     
  • If you want to make the script totally quiet, it's much easier to redirecct std error to std in, and both to /dev/null. Just call:

    Resources/script > /dev/null 2>&1

    (there should be no blanks in '2>&1')

    The only thing you need to patch is the line in 'Resources/script', which changes the working directory to the users home. Your modification isn't exactly the same as the current behavior. Think of starting GIMP by double clicking on a *.xcf file. The file will be handed over to GIMP on the command line of 'Resources/script'. If the user then creates a new image and wants to save this new image, the default location in the file chooser the user gets shown, is the root of the filesystem. The current behavior shows the user's home directory.

     
  • I can't redirect all to /dev/null as my scripts produce output that is logged.

    You are right, my modification breaks current behavior. Maybe the only solution is to split 'Resources/script' in two separate scripts: a "pre-setup" one, that build the necessary directory and links, and the "luncher". In this way the "pre-setup" one can be reused for the CLI.

    Unfortunately I've found another problem trying to parallelize my asset pipeline, running multiple instances of GIMP: "bin/gimp" script stores the DBUS session always in the same file (/tmp/skl/dbus-address-$UID), that then removes also if other instances are still running. It's not clear if this could issue problems on the running instances. Who uses this file?

     
  • hhmm, you don't need to redirect your script, only the one in Gimp.app. Just this one: '/App../Gimp.app/C../Recources/script'

    I can't see any advantage in splitting 'Resources/script'. If I'll do so, then I need a third script, which calls the setup-directory and then calls the launcher. And you need to write your own 'third' script which either calls the setup-direcory and rewrites the launcher of rewrites the setup-direcotory and calls the launcher.
    So what should be the advantage of spliiting 'Resources/script'?
    IMO it's much easier if you write your own version of 'Resources/script' or just patch the one in GIMP.app, if you don't care about the default save location. You only need to comment out the line 'cd ~/'.

    dbus is used only for making drag&drop work. ( d&d files on GIMP's icon). If you call GIMP from CLI in batch mode only, you can safely ignore dbus.

    BTW. the packages here on GIMP on OS X are meant to be used with the GUI, not from CLI. And if you use the GUI, there will be no multiple instances of GIMP. ;-)

     
    • status: open --> closed-invalid