[OSX] 0.91: Command line invocation cannot find svg file

[Julian Gilbey]

In 0.48, the following worked fine. I've just upgraded to 0.91, and now it doesn't work:

Julians-MacBook-Pro $ /Applications/Inkscape.app/Contents/Resources/script -z --export-pdf=pic1.pdf pic1.svg

** (inkscape-bin:2549): WARNING **: Can't open file: pic1.svg (doesn't exist)

** (inkscape-bin:2549): WARNING **: Can't open file: pic1.svg (doesn't exist)

** (inkscape-bin:2549): WARNING **: Specified document pic1.svg cannot be opened (does not exist or not a valid SVG file)
Julians-MacBook-Pro $ ls
pic1.svg pic3.svg pic5.svg pic7.svg
pic2.svg pic4.svg pic6.svg

I tried running dtruss on this, and it doesn't even seem to attempt to open pic1.svg (but that may be a failure in the dtruss output to display the correct information).

I then tried running the same command again, but this time putting in complete pathnames, replacing pic1.svg with `pwd`/pic1.svg and it succeeded, but it placed pic1.pdf in the directory /Application/Inkscape.app, which is just plain weird. I could only get it to do the "correct" behaviour by specifying full pathnames for both the svg and pdf filenames.

My guess is that somewhere the binary is doing a chdir, but why is beyond me.

I haven't yet had a chance to test 0.91 on any other operating systems.

[su_v (suv-lp)]

You need to use absolute paths for any (all) files referenced on the command line (with '/Applications/Inkscape.app/Contents/Resources/script' you had to do this with Inkscape 0.48 too btw) - a known limitation with the current structure of X11-based, self-contained and fully relocatable application bundles for OS X (which are not optimized for such command line usage btw - it is recommended to install a regular command line build of inkscape via MacPorts, Fink or Homebrew if using it on the command line is the major use case).

Proposing to link as duplicate to
* Bug #181639 “Command-line invocation on Mac OSX partially broken”
  https://bugs.launchpad.net/inkscape/+bug/181639

[su_v (suv-lp)]

On 2015-04-27 22:33 (+0200), Julian Gilbey wrote:
> My guess is that somewhere the binary is doing a chdir, but why is
> beyond me.

It's not in the binary - it has to be done in one of the wrapper shell scripts (which one varies - in 0.48, it was in Contents/Resources/script, with 0.91 it is in Contents/Resources/bin/inkscape), and it is required because of the current limited relocation support in Inkscape itself (if compiled for an osx application bundle, relocation support is implemented by enforcing looking up the path to the required Inkscape resource files via a relative path starting at the top-level of the application bundle).

[Julian Gilbey (jdg)]

Thanks for the explanation. That's really bizarre, though: I used to call the 0.48 with just inkscape (I put the inkscape binary path in PATH), and it worked fine with relative pathnames. But it doesn't now work with 0.91.

[su_v (suv-lp)]

Linking as duplicate to bug #181639 - comment #4 there has a brief explanation about changes in 0.91 (see also the link in the footnote to the related comment in the shell script itself).