command line "failed to load"

[Ryo Furue]

This bug appears to be the same as #165687 but that one was marked "Fix Released". I don't know how to re-open it, so here is a new report.

    $ inkscape --version
    Inkscape 0.91 r13725 (Jan 28 2015)
    $ inkscape somefile.pdf

This results in a popup window that says, "Failed to load the requested file somefile.pdf". But exactly the same file can be opened from "File" > "Open". I tested two different PDF files and both showed the same behavior.

Mac OS 10.11.6 .

Ryo

[su_v (suv-lp)]

How did you install Inkscape?

Noe that the official package from inkscape.org is _not_ optimized for direct commandline usage due to the legacy relocation support [1]: you need to specify the full path to input and output files if you somehow linked the 'inkscape' command to a launcher script inside the app bundle (via symbolic link or alias).

[1] tracked in bug #181639

[Ryo Furue (furue)]

> How did you install Inkscape?

If I remember correctly, I did

    $ brew cask install inkscape

This seems to install Inkscape.app under /Applications/ and make a symbolic link

    $ \ls -lF /usr/local/bin/inkscape
    . . . . /usr/local/bin/inkscape@ -> /Applications/Inkscape.app/Contents/Resources/bin/inkscape

> https://bugs.launchpad.net/bugs/181639

Thanks for the link. Then, my issue is a duplicate of the linked one. I guess a solution is

    $ open -a Inkscape somefile.pdf

One might think of turning this into a bash alias or a shell script, but then

    $ open -a Inkscape --version

doesn't work. So writing a shell script to wrap Inkscape.app isn't trivial.

In the meanwhile, I found that /Applications/Inkscape.app/Contents/Resources/bin/inkscape is already a shell script. Is it hard to convert the given filenames to their absolute paths in it?

[su_v (suv-lp)]

> Is it hard to convert the given filenames to their absolute paths in it?

Not possible (because ... the current legacy implementation of relocation support requires that the actual inkscape binary is launched from a specific path inside the application bundle, else inkscape fails to find and load required shared resources looked up at a path relative to the application bundle's top-level directory. Thus any shell script launcher is required to change directory to the top-level directory inside the application bundle first, before launching the inkscape binary itself, which of course requires that input and output files are referenced with absolute paths).

The known limitation has a long history and over time suffered additional setbacks due to changes implemented in inkscape core e.g. to improve support for other proprietary platforms (in this case: Windows).

A branch with a proposed minor refactoring of the internal relocation support for Mac OS X application bundles which would improve the current situation unfortunately never received attention or review by core inkscape developers.

Your best chances are to be patient and wait/hope for GTK3-based packages for future Inkscape releases (0.93 or later) - the switch to GTK3 (with Quartz backend) requires a more-or-less complete rewrite of Inkscape packaging for macOS from scratch anyway, and hopefully will not repeat the rather “simplistic” relocation support implemented in legacy packaging.

With regard to homewbrew casks - whatever is offered there is not maintained by the inkscape project, and the maintainers of such casks need to deal themselves with known upstream limitations in whichever way they think is appropriate (the inkscape project itself doesn't track issues with third-party package managers like e.g. homebrew casks).

Linking as duplicate to bug #181639 as mentioned earlier.

[Ryo Furue (furue)]

> > Is it hard to convert the given filenames to their absolute paths in it?
>
> Not possible (because ... the current
> legacy implementation of relocation support
> requires that the actual inkscape binary
> is launched from a specific path inside
> the application bundle, else inkscape
> fails to find and load required shared
> resources looked up at a path relative
> to the application bundle's top-level directory.
> Thus any shell script launcher is required to change
> directory to the top-level directory inside
> the application bundle first,

I'm sure I'm missing something, but I wonder why the launcher can't first convert the filenames given as arguments into their respective absolute paths, before changing directory to the top-level.

> With regard to home-brew casks
> - whatever is offered there is not maintained
> by the inkscape project,

Of course! I mentioned homebrew only because you asked, not in order to complain about it to you.

[su_v (suv-lp)]

Ryo Furue wrote:
> I'm sure I'm missing something, but I wonder why the launcher can't
> first convert the filenames given as arguments into their respective
> absolute paths, before changing directory to the top-level.

IIRC among the issues to solve for such a convenience script:
* a scripted way to determine which command line arguments are actually (relative) paths to input or output files, and which are other options
* a scripted way to determine whether the launcher script is called "regularly" (via app bundle i.e. already uses absolute paths to any referenced files) or directly in the terminal
... and likely other details I encountered in earlier attempts and forgot about again.

You are welcome to write a cli launcher script
 (e.g. Inkscape.app/Contents/Resources/bin/inkscape-cli )
which supports parsing all available inkscape command line options, extracts any file names with relative paths there, prepends the quoted full path (e.g. making use of expanded "$PWD") and re-assembles the original command line arguments again to be passed on otherwise unchanged (same order, same syntax) to the inkscape binary; all this before actually cd'ing to the bundle's top-level directory (and the rest of the environmental setup handled by the existing (pair of) launcher script(s)).

Such a separate script could then be used by anyone favoring to use the bundled app via Terminal instead of installing inkscape (from source, or via package manager) as regular command line app into a fixed prefix (without any of the limitations of the bundled version).

Most of the currently available command line options are documented on the man page:
https://web.archive.org/web/20160407002248/https://inkscape.org/en/doc/inkscape-man.html
(inkscape.org seems down at the moment with '502 Bad Gateway')

Note that input files can be passed as direct arguments, or via '--file blah.svg' or '--file=blah.svg'; the arguments for the various output formats supported via command line work similarly ('--export-png blub.png' works as does '--export-png=blub.png'). The file name itself might be quoted (with '"' or "'") or escape e.g. spaces ('\ ') or special unicode characters.
The specific order of the command line arguments IIRC only matters for verbs.

Note also that 'inkscape' calls can be “nested”: several of Inkscape's python-based extensions (and an unknown number of externally written and maintained custom extensions) spawn inkscape again e.g. to retrieve details about selected (or all) objects per id on the command line, or to export a selection or the drawing to PNG (maybe with a specific resolution or size) or PDF, or to further process the SVG content itself via verbs (e.g. the Synfig exporter). Such 'secondary' calls are of course then from an already changed working directory (if using the bundled version of Inkscape on OS X) and cannot rely on $PWD again (they are provided absolute paths to the copy of the SVG file in $TEMPDIR anyway). The 'secondary' inkscape process is spawned using the first 'inkscape' command found in $PATH; $PATH is modified (paths are prepended) in the current launcher script(s).

Personally, I'd favor modifying Inkscape's core source to suppo...

[Ryo Furue (furue)]

> IIRC among the issues to solve for such a convenience script:
> * a scripted way to determine which command line arguments
> are actually (relative) paths to input or output files,
> and which are other options
>* a scripted way to determine whether the launcher
> script is called "regularly" (via app bundle i.e.
> already uses absolute paths to any referenced files)
> or directly in the terminal
> ... and likely other details I encountered
> in earlier attempts and forgot about again.

Yes, I'm sure you developers thought a lot about the problem. So, please don't think I'm criticizing you.

Actually, I had written a little script (attached) before I posted my last comment. Of course, this kind of "toy" script won't cover all scenarios and it's not up to the standard of official scripts, but it may be useful for casual use.

> * a scripted way to determine which command line arguments
> are actually (relative) paths to input or output files,
> and which are other options

Whether the option starts with "-" or not isn't sufficient? I guess that means Inkscape accepts arguments that are not filenames and do not start with a "-".

>* a scripted way to determine whether the launcher
> script is called "regularly" (via app bundle i.e.
> already uses absolute paths to any referenced files)

But, to convert filenames to absolute paths doesn't require knowing whether the filenames are already absolute paths or not. It won't hurt if you convert an absolute path to an absolute path. Unless you try to canonicalize or resolve links, that conversion is no-op.

--------
#!/bin/bash

bin=/usr/local/bin/inkscape

files=()
opts=()
abspaths=()

for a in "$@"; do
    case "$a" in
    -*) opts+=("$a");;
    *) files+=("$a");;
    esac
done

for f in "${files[@]}"; do
    if [ -e "$f" ]; then
 abspaths+=( $(realpath -s "$f") )
    else
 "$f not found."
    fi
done

exec $bin "${opts[@]}" "${abspaths[@]}"

[su_v (suv-lp)]

Just a reminder: 'realpath' is not provided by the OS.

[ Yes, one could write a bash function as substitute, or require coreutils (or a custom version of just 'realpath') installed via a package manager available on OS X (though then again if the user already has to use a package manager like homebrew, macports or fink for the cli launcher script: why not also install inkscape via the same package manager (and forget about the custom cli launcher)?) ]

[Ryo Furue (furue)]

> Just a reminder: 'realpath' is not provided by the OS.

Um . . . reminder to whom?

This is my guess: You think that I'm proposing my script for an official distribution with inkscape? No! As I said, mine is a "toy" script, not up to the standards of distributable scripts.

That's exactly why I did NOT comment on realpath not being standard. (I knew it. I also started to think about how to implement realpath without relying on non-standard tools.)

No. I just posted my script for non-developer users who might be reading this conversation in the future. It already serves me and may well be useful to others when they are hit by the same problem. When they find realpath missing, they will search the Internet for it.

> (though then again if the user already
> has to use a package manager like home-brew,
> macports or fink for the cli launcher script:
> why not also install inkscape via the same
> package manager (and forget about the custom cli launcher)?

Sorry I don't understand this part. I read it three times. . . .

Anyway, what do you think about converting filenames to their absolute paths in your official launcher script before changing directory?

Another issue: I'd like to suggest changing the error message when the file isn't found. "Failed to load the requested file somefile.pdf" puts the user much more easily off the track.

I'm not saying this error message is incorrect. It IS correct. But, many users would think that there are some problems in the file (corrupted image, etc.). The standard message is "somefile.pdf: file not found" when the application cannot find the input file.

I'm not saying that this standard message would put the user in the right track, but it would avoid sending the user to a completely wrong track.

[su_v (suv-lp)]

> Anyway, what do you think about converting filenames to their
> absolute paths in your official launcher script before changing
> directory?

The legacy packaging for the X11-based Inkscape application bundle on OS X as used for Inkscape 0.91 (and older releases) is a dead end (there will likely be no further official Inkscape packages released based on the current state of the packaging scripts, nor will the current packaging scripts be further maintained).

<opinion>
From my point of view it makes no sense for the project to spend time attempting to add more workarounds for limitations known to be caused by a decision made many years ago about a simplified relocation support in core inkscape for OS X application bundles at the expense of fully supporting regular command line usage with the inkscape binary (configured and compiled with '--enable-osxapp') included in such OS X application bundles.
The fix is to rewrite relocation support (load Inkscape's shared resources relative to the absolute path of the executable itself, like on Windows) or - alternatively - to allow Inkscape to search, find and load its shared resources from XDG locations (which can be changed at runtime via env variables like $XDG_DATA_DIRS) on all supported platforms.
</opinion>

On the other hand the number of reports filed about this issue does indicate that a (custom) launcher script implementing a workaround as proposed (ideally without relying on 'realpath' as additional dependency) would probably be appreciated by a (still small) inkscape user base on OS X (users who don't want to compile / install inkscape via package manager into a fixed prefix, but need to use inkscape via command line nevertheless).

Whoever will tackle packaging of future GTK3-based Inkscape releases (>= 0.93) as self-contained fully relocateble macOS application bundles ought to also rewrite Inkscape's core relocation support for that platform (apart from switching from MacPorts to 'gtk-osx' for the dependencies, and from custom scripts for filling the bundle and the subsequent library path rewriting to 'gtk-mac-bundler' for creating the application bundle itself) - to reach the same level of support as e.g. implemented for Windows and Linux based on the absolute path of the executable itself.

> Another issue: I'd like to suggest changing the error message when
> the file isn't found. "Failed to load the requested file
> somefile.pdf" puts the user much more easily off the track.
>
> I'm not saying this error message is incorrect. It IS correct. But,
> many users would think that there are some problems in the file
> (corrupted image, etc.). The standard message is "somefile.pdf: file
> not found" when the application cannot find the input file.

Messages like these are from core Inkscape (not specific to packaging or platform): if you have suggestions to improve them (across all platforms), please file a separate report (not related to any packaging issues on OS X).

[Ryo Furue (furue)]

> On the other hand the number of reports
> filed about this issue does indicate that
> a (custom) launcher script implementing
> a workaround as proposed (ideally without
> relying on 'realpath' as additional dependency)
> would probably be appreciated by a (still small)
> inkscape user base on OS X
> (users who don't want to compile / install inkscape
> via package manager into a fixed prefix,
> but need to use inkscape via command line nevertheless).

Your last parenthetical remark is a reflection of your assumption that

   most users who use command lines
   shouldn't mind compiling inkscape
   from source.

This assumption is likely false. Who would compile from source if "brew cask install inkscape" takes care of everything? It doesn't matter whether the user spends a lot of time on the command line or not. "Command line" and "compile from source" are almost entirely different issues, today.

Since I haven't interacted with too many different people, I don't know how typical we are, but many of my friends and colleagues use both Linux and Macs, and most of us rely on packaging systems, like apt, fink, rpm, macports, homebrew, etc. Compiling from source is the last resort, which is rarely needed today. On the other hand, we have to spend a lot of time on command line because some of the tools we need have only command line interfaces. Many of us are also long-term Unix users and use the command line out of habits. (Have you have the story about Linux users abandoning Linux and migrating to Mac?)

Finally, I don't think your offensive wording is necessary. That parenthetical remark and your "(still small)" indicate your contempt against the idea of including such a launcher script in the inkscape package. I'm not saying you should do so. All I'm saying is that it may be useful. Nothing more. And "the number of reports filed about this issue" suggests that my assessment isn't wrong.

[su_v (suv-lp)]

Sorry if my explanations came across as offensive (they were not intended to be, I'm personally aware of what it takes to compile ported packages from source on a Mac).

Casks are a rather recent invention to install application bundles provided by upstream projects. If asked by the cask maintainer, I for one would have advised against a solution which simply links the original launcher script into /usr/local/bin (since I'm aware of the unfortunate shortcomings of the current packaging method based on the legacy relocation support).

The limitation with currently provided pre-compiled packages for OS X is known and hopefully will be addressed by future Inkscape packaging for macOS provided for GTK3-based builds (without any dependency on X11).

My personal frustration - in large parts due to failing to change things for the better (e.g. merge proposal for bug #181639, working on the - now abandoned - experimental osxmenu branch) likely also affects my replies/comments in this report and results in wording that may offend others: I regret if this is the case, and apologize for it. Please do not take my replies here as some kind of "official" attitude of the project itself towards Inkscape users in general or Inkscape users on OS X in particular.