This repository has been archived by the owner on Feb 19, 2019. It is now read-only.
[BUG] Working directory of shimgen generated files points to path target executable is in (GUI apps only) #508
Comments
|
Nope, let's call this a bug. |
ferventcoder
changed the title
|
Also #509 |
|
This seems to only be on GUI applications :( |
ferventcoder
added a commit
that referenced
this issue
Jul 11, 2014
- Shimgen no longer changes the working directory to target files (this only occurred for GUI apps) - Adding --shimgen-log to the end of a shim call command will cause the shim to log to the console information about what it is doing - Adding --shimgen-usetargetworkingdirectory to the end of a shim call will cause it to use the target executable's working directory instead of the current work directory.
ferventcoder
changed the title
|
@kevinsawicki I pushed a prerelease package with the fixes. Can you install chocolatey prerelease and then reinstall atom to regenerate the shim? Or have the person who reported the issue do this... :) choco install chocolatey -pre
choco install atom -fThen try the issue reported again to see if it also working for you now? |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm noticing that the working directory of applications created by shimgen seems to be the path that the target executable is in, not the path that the executable was launched from.
So if an application takes arguments that are relative paths, when they are resolved against the working directory they will be resolved against the location of the application, not the directory where the command was run.
Is this intended behavior and is there any workaround to access the original working directory where the command was run from?
The text was updated successfully, but these errors were encountered: