cannot open relative paths using script extensions from command line

[Anye Li]

I am unable to open an EPS file from the comand line

$ inkscape -z -f drawing.eps -l drawing.svg

where drawing.eps exists in my working directory and is a valid EPS file. Inkscape tries to open it as an SVG file, which of course fails. When I instead use the command

$ inkscape -z -f `pwd`/drawing.eps -l drawing.svg

things work as I expect. I did some debugging and I believe my problem is with src/extension/implementation/script.cpp; at line 924

        working_directory = Glib::path_get_dirname(script);

but the the name of the input file is left alone, so the input file is sought in the working directory, i.e. the directory where the extension script lives.

This happened to me with Inkscape 0.48.0, built from source on RHEL5. I also built python2.6 and the entire gtk+ stack from source and installed everything under my home directory as I do not have root.

I did not have this problem with Inkscape 0.47 r22583 (Mar 12 2010) packaged with Debian 6.0 (Squeeze).

[su_v (suv-lp)]

reproduced with Inkscape 0.48+devel r9986 on OS X 10.5.8

[su_v (suv-lp)]

Possibly due to the fix for bug #505107 which causes to change the working directory before spawning the python process (see also <https://bugs.launchpad.net/inkscape/+bug/551433/comments/7>).

[su_v (suv-lp)]

@JazzyNico - can you confirm the regression relative to 0.47? (I don't have a command line version of 0.47 installed and can't test this specific issue (relative path names on the command line) with the osx-packaged version).

[jazzynico (jazzynico)]

Regression confirmed on Ubuntu 10.04.
Works as expected with 0.47, but not with 0.48 and trunk revision 9985.

[Patrick Monnerat (monnerat)]

Confirmed on Fedora 14
Version: inkscape-0.48.1-1.fc14.1.x86_64
See https://bugzilla.redhat.com/show_bug.cgi?id=701391

The attached patch fixes the problem by converting relative names to absolute before chdir().
Seems OK in Linux, but W$ code has to be validated.

[Kris (kris-degussem)]

Sorry for the late reaction.
Fix committed in revision 11299.
Thanks for your work and sharing the patch.

[Kris (kris-degussem)]

Fix backported for 0.48.4 in the 0.48.x brach revision 9890.

[Patrick Monnerat (monnerat)]

@Kris: thanks to you for committing

[su_v (suv-lp)]

Based on tests with archived builds, the fix for this issue introduces a different regression (in both branches: 0.48.x and trunk):
Bug #1022719 “Inkscape fails to open file from the web (via URL) on the command line (regression) ”
<https://bugs.launchpad.net/inkscape/+bug/1022719>

[John Paul Adrian Glaubitz (glaubitz)]

I think the patch suggested and used here is bad. It reinvents functions from the glib and therefore uses unnecessary #ifdefs for Windows.

I suggest reverting this patch and applying the one suggested by Michael Karcher in https://bugs.launchpad.net/inkscape/+bug/911146.

His patch is much simpler, properly makes uses of glib, doesn't reinvent the wheel and avoids any #ifdefs.

I'll attach the patch.

Cheers,

Adrian

[John Paul Adrian Glaubitz (glaubitz)]

I also just tested, the patch by Michael Karcher also doesn't introduce the regression in https://bugs.launchpad.net/inkscape/+bug/1022719. glib has no problems dealing with URLs when verifying the absolute file path.

I highly suggest reverting this patch and applying Michael's.

Cheers,

Adrian

[Patrick Monnerat (monnerat)]

@glaubitz:

Please, do as you want if your last patch WORKS !

But don't call patch "abs4dir" bad: it might be ugly from a C++ programmer standpoint. I'm definitely not a C++ programmer, I reenvented the weel because I did not know it already existed, but I can try to fix things I need quicker than the average reaction on this project that is, IMHO, very slow. The latency time is just inacceptable in a production environment. I just left this patch with the current bug report for people that were upset of waiting for a fix, as I was. This is the principle of reciprocity without which most opensource project could not live.

"abs4dir" patch is a "fireman" patch: it has fully reached its goals:
- Provide something working during 18 months (and maybe more),
- Draw attention of people that are real developers for this application.

I'm really happy someone puts finally some energy in this problem, but I'm really disappointed by the reaction times:
- 2 years between initial bug report and the fix released in a stable version.
- 17 months since the patch has been posted.
- 2 years for a "real developer" patch.

Last but not least: IMO the best fix would be to get rid of the chdir(): this is the ugliest thing in all this story.

Also I don't know why I've been set in charge of bug reports in this list, because I'm just an occasional submitter, not a developer: please take assignment of these reports if you want to actively manage them. Thanks.

[ScislaC (scislac)]

@Patrick: I'm sorry about your experience here. First off, let me apologize about the time to respond to your initial patch. We are a fully volunteer driven project and to say we are "understaffed" would be an understatement. Unfortunately sometimes things like this slip through the cracks and that really appears to be what happened in this case (evidenced by Kris apologizing after committing your original fix). Unfortunately, when it was committed just happened to fall between stable bugfix updates. The last bugfix update was unfortunately delayed by a few months due to an outstanding security vulnerability we were waiting for a fix on.

As for why you were assigned to this report, it was to ensure that we credited the person who submitted the fix for it. We're not saying you're always responsible for it, in most cases when a report is closed as Fix Released, that is the end of it. We have a policy for our project for contributors needing to submit 2 patches (which get accepted) to grant developer access, this is another reason we assign patch submitters to their reports (to track that). If you would like your assignment removed we can do that, but I can't promise it won't happen on future reports if you submit patches.