User forums > Help

Problem with codeblocks user settings path

<< < (2/2)

mandrav:

--- Quote ---It's seems that if a HOME environment var is defined, it's used instead of USERPROFILE.
--- End quote ---

Thanks for sharing this. It's tricky...

Yiannis.

cataddict:
OK, I'll resurrect this thread as my first post. I also get the '%USERPROFILE%/.Codeblocks' couldn't be created (error 3: ...)" message when using CB RC-1 (and finalbeta). I'm using Win 2000 SP4 and it happens the same on both my machines. I saw reference to having %HOME% set could cause problems -> it is set to HOME=%userprofile% by default on both machines. I'm afraid to delete HOME since I don't know what if anything that would break.

Oddly, the version of CB that I compiled myself a week or so ago from the HEAD doesn't exihibit this problem. It creates the .CodeBlocks directory and workspace files fine.

Any new thoughts??

FYI - I love where this program is heading!

rickg22:
A possible fix would be to test if the USERPROFILE env variable is not set. If so, set it to mimic the HOME variable.

cataddict:
USERPROFILE variable is set USERPROFILE=c:\Documents and Settings\Administrator

but I can change:
HOME=%USERPROFILE%
to
HOME=C:\Documents and Settings\Administrator

and RC1 seems to work with a hardcoded value for HOME

kagerato:
The environment variable (%HOME%, in this case) may have been an unexpandable REG_SZ value in the registry.  The only way to know whether that is/was the case or not is to check the appropriate key in the registry.  Global environment variables are defined at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment , and local environment variables are defined at HKEY_CURRENT_USER\Environment.  The name of the value will be the environment variable's designation (without the percent identifiers), and the value's data is what the environment variable will be replaced by (expanded to) when used in a valid context.

The registry is a rather esoteric system, though.  If the environment variable's value is of type REG_SZ (essentially, a basic string), then no expansion using other environment variables will occur.  This can cause problems because most parsers expect that an expanded environment variable will produce an absolute path to a valid location.  The potential conflict of interpretation can be avoided by defining environment variables using REG_EXPAND_SZ -- this type of value will undergo environment variable expansion before the literal string is returned to the accessing program.

That explanation is probably too long-winded for most; just ensure that any environment variables which utilize other environment variables in their data are of type REG_EXPAND_SZ.

Navigation

[0] Message Index

[*] Previous page