Comment 6 for bug 1617281

> 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[@]}"