Commandline on Windows
Hi all,
In the FAQ I read: "Note that on Windows you must provide full paths for all files:
inkscape -e c:\mydir\file.png c:\mydir\file.svg
Without the c:\mydir\ it won't work."
Why is this so? Perhaps someone can point me in the direction of solving this?
Thanks, Johan
On Tue, Feb 16, 2010 at 8:24 AM, <J.B.C.Engelen@...1578...> wrote:
Hi all,
In the FAQ I read: "Note that on Windows you must provide full paths for all files:
inkscape -e c:\mydir\file.png c:\mydir\file.svg
Without the c:\mydir\ it won't work."
Why is this so? Perhaps someone can point me in the direction of solving this?
I wrote this, based on my experience, still valid. But I have no idea why :)
J.B.C.Engelen wrote:
Hi all,
In the FAQ I read: "Note that on Windows you must provide full paths for all files:
inkscape -e c:\mydir\file.png c:\mydir\file.svgWithout the c:\mydir\ it won't work."
Why is this so? Perhaps someone can point me in the direction of solving this?
Thanks, Johan
May this be related to the "current working directory" issue? See for example: https://bugs.launchpad.net/bugs/373315 "Print files go to Inkscape directory not to current" There you can find some links to other related bugs.
Luca
The issue is as follows
1. On Linux, we use XDG functions from GLib, like g_get_user_data_dir, to find our share/ directory and other things 2. On Windows, our share directory can be absolutely anywhere, and those functions are of little use 3. We solve this by calling the win32 function GetModuleFileName [1] 4. During implementing 3 somebody cut corners so that we use relative paths instead of appending our executable's directory in the front 5. For the hack in 4 to work, current directory must be set to the place where Inkscape's executable resides
[1] http://msdn.microsoft.com/en-us/library/ms683197%28VS.85%29.aspx
Regards, Krzysztof
On Mittwoch 17 Februar 2010, Krzysztof Kosiński wrote:
- For the hack in 4 to work, current directory must be set to the
place where Inkscape's executable resides
Does this happen before main() (i.e. is it some Windows-specific executable property)? Otherwise, how about simply converting all cmdline arguments to absolute paths before performing the chdir?
Or, after reading Luca's answer, it could make sense to switch back CWD to the old one before every load/save.
2010/2/19 Hans Meine <hans_meine@...240...>:
On Mittwoch 17 Februar 2010, Krzysztof Kosiński wrote:
- For the hack in 4 to work, current directory must be set to the
place where Inkscape's executable resides
Does this happen before main() (i.e. is it some Windows-specific executable property)? Otherwise, how about simply converting all cmdline arguments to absolute paths before performing the chdir?
No, we explicitly call SetCurrentDirectory. We can convert arguments to absolute paths in WinMain, but I'd rather fix this properly (e.g. not change the directory and be smarter about where we look for resources).
Regards, Krzysztof
On Feb 23, 2010, at 5:50 PM, Krzysztof Kosiński wrote:
2010/2/19 Hans Meine <hans_meine@...240...>:
On Mittwoch 17 Februar 2010, Krzysztof Kosiński wrote:
- For the hack in 4 to work, current directory must be set to the
place where Inkscape's executable resides
Does this happen before main() (i.e. is it some Windows-specific executable property)? Otherwise, how about simply converting all cmdline arguments to absolute paths before performing the chdir?
No, we explicitly call SetCurrentDirectory. We can convert arguments to absolute paths in WinMain, but I'd rather fix this properly (e.g. not change the directory and be smarter about where we look for resources).
Yes, yes, YES!!!
I want to be on record as what Krzysztof said here is right on target.
Not changing directory goes hand in hand with not being dependent on the directory setting of the current moment. Among other things such issues can get very complicated as soon as multithreading is in play. Given that we are trying to clean things up to take advantage of multiple cores, this is about to become a much more important issue.
Probably the top thing to do is correct where we look for resources. From way back this was originally addressed by simplistic #defines to paste static paths together, etc. Instead we need to get relative lookups hierarchal and properly relative. This is right in line with Krzysztof's hesitance to convert paths to absolute in WinMain.
On Feb 23, 2010, at 7:36 PM, Jon Cruz wrote:
Not changing directory goes hand in hand with not being dependent on the directory setting of the current moment. Among other things such issues can get very complicated as soon as multithreading is in play. Given that we are trying to clean things up to take advantage of multiple cores, this is about to become a much more important issue.
Probably the top thing to do is correct where we look for resources. From way back this was originally addressed by simplistic #defines to paste static paths together, etc. Instead we need to get relative lookups hierarchal and properly relative. This is right in line with Krzysztof's hesitance to convert paths to absolute in WinMain.
For example, this bug covers something I just saw recently in regards to optimal use of directories:
participants (6)
-
unknown＠example.com -
bulia byak -
Hans Meine -
Jon Cruz -
Krzysztof Kosiński -
LucaDC