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 support relocation based on the binary's own absolute path (instead of relying on a relative path) anytime over a script-based solution which attempts to expand relative paths to input and output file names.