search

skeeto / w64devkit

Portable C and C++ Development Kit for x64 (and x86) Windows
The Unlicense
3k stars 211 forks source link

Setting 'home' in w64devkit.ini doesn't work for me #90

Open AndrewGodfrey opened 11 months ago

AndrewGodfrey commented 11 months ago

I tried to use w64devkit.ini to change where it looks for ".profile", but I couldn't get it to work. From other discussions it seems like it works for other people but it doesn't for me. I also see that there was a big rewrite since 1.20.0 was released, so maybe this was fixed then. Anyway - I'll work around it, but in case this is interesting, here's what I observed. I'm running Windows 10.

I stepped through w64devkit.exe in the debugger, and I found that everything in homeconfig() succeeded. That is, it found my "home=%HOMEDRIVE%\%HOMEPATH%\foo" setting, correctly expanded the environment variables, etc. Then it called SetEnvironmentVariableW to set HOME, and that succeeded.

My best guess is that this env-var change isn't being inherited by CreateProcessW for some reason. When the shell starts, it executes the .profile in my %HOMEDRIVE%\%HOMEPATH% (not %HOMEDRIVE%\%HOMEPATH%\foo). If there's no .profile it executes nothing. And $HOME always points to %HOMEDRIVE%\%HOMEPATH%.

skeeto commented 11 months ago

The rewrite is better about error reporting, so perhaps try building and running that. It doesn't need to be called "w64kdevkit.exe" nor have the resources linked in. It only needs to be in the right directory when you run it. I'm happy you were at least able to step through it in a debugger!

From your description, I can't think of what might be going wrong. I'd expect CreateProcess to fail if it cannot pass the environment. Perhaps as another test, set a variable (in cmd.exe, etc.), run w64devkit.exe from that environment, and see if the new variable survives into the shell.

Another idea is to add CREATE_SUSPENDED to CreateProcess, attach to the newly-created, suspended process with GDB, and inspect the environment and other state.

AndrewGodfrey commented 11 months ago

For now I can put .profile in my ~ folder, so I don't need a solution myself.

Perhaps as another test, set a variable (in cmd.exe, etc.), run w64devkit.exe from that environment, and see if the new variable survives into the shell.

I don't understand that test. Lots of variables survive into the shell. It's only the 'home' that w64devkit.exe sets, is silently not taking effect. e.g. as if the CreateProcess is inheriting its env-vars from the parent process of w64devkit.exe. Anyway, fwiw I ran cmd, set zzz=test, and then ran w64devkit.exe, and observed that 'zzz' is set in sh.

AndrewGodfrey commented 11 months ago

btw I didn't try the CREATE_SUSPENDED test because I'm not building w64devkit myself. I only cloned it to see the source code.