Can't run custom extension in 0.48.1

Reproduced with Inkscape 0.48+devel r10252
Not reproduced with Inkscape 0.47 on OS X 10.5.8 (i386)

For testing, a simple test extension calling a shell script was used, with
a)
<command reldir="extensions" interpreter="bash">debug-interpreter.sh</command>
b)
<command reldir="extensions" interpreter="bash --login">debug-interpreter.sh</command>

Both variants work fine in 0.47, but fail in 0.48(+devel) with this error message:

Can't Spawn!!! spawn returns: Failed to execute child process "" (No such file or directory)

Note: for the test, the INX file and the shell script had been put into the user extensions directory:
  $HOME/.config/inkscape/extensions

Reproduced on Windows XP, Inkscape trunk revision 11992.
Unfortunately, GDB returns no backtrace.

Any progress on this bug?

According to the RELAX NG XML schema (see http://wiki.inkscape.org/wiki/index.php/INX_extension_descriptor_format#RELAX_NG_XML_schema), the interpreter attribute should accept python or perl only, without any command line parameter.

...
       element command {
         inx.reldir.attr,
         attribute interpreter { "python" | "perl" }?,
         text
       },
...

And thus the current behavior could be considered valid (except that the error message should be a bit more clear).

But src/extension/implementation/script.cpp uses a table to associate the interpreter name to the appropriate executable ("python" returns "pythonw" on win32, and "python" on other systems), and accepts some interpreters that are not in the XML schema, such as "ruby" (associated with "ruby") and "shell" ("sh").

That said, the interpreter value seems to be used to retrieve the full executable path only, and using another name (bash, java) should work correctly providing that the executable is in the user's path and that the name match the executable name on all the systems the extension is installed.

Patch in progress.

Adding a "crash" tag. Not only unexpected interpreters don't work on Windows, but they also crash the application...

First attempt to solve the issue.

The patch accepts any interpreter providing that it is in the path. Interpreter arguments are not supported yet (in that case, the interpreter is used without argument).

The Windows crash is worked around, but not solved (exception not correctly caught in Glib::spawn_async_with_pipes).

Hi Jazzynico, you posted a WIP patch to this bug a year ago, would you mind updating us on the current status of the fix for this issue?

Hi Bryce, it's still WIP because it doesn't work with arguments. I'll see if I can work on it before we freeze the code. If not, I'll commit my patch and update the report accordingly.
BTW, I've planned to update my other open reports soon.

New patch that accepts arguments (debug code activated).
Quickly tested on Windows XP, Inkscape trunk revision 12923.
Really needs more tests on all systems.

Improved patch.
Seems to work correctly with basic shell commands, but still returns java errors when running java -jar <javaexec>. Apparently related to the way the working directory is set.