Sdusercustomizedir

[MikeBoswell]

I have added the SDUSERCUSTOMIZEDIR as a system variable.

I want to pick up the %username% variable in the path that I define SDUSERCUSTOMIZEDIR w/.

What does not work is the %username% is taken literally.

It creates a folder called %username%.

Any thoughts on my syntax or what may be going wrong?

Thanks,
Mikeb

[MikeBoswell]

someone must know what Im doing wrong.

Is it that SD cant use system variables?

Do I need to escape it differently?

???

Thanks,

[John van Doorn]

Hi Mike,

I'm not sure if I understand your question.
First of all I assume you are running windows.

You should be able to set an environment variable using an othe variable e.g. set SDUSERCUSTOMIZEDIR=D:\home\%USERNAME%

I've tried this on my system and it is creating the correct directory.
I did not use any quotes around the value, maybe this is causing the problem you're describing.



John

[clausb]

OSDM does not try to evaluate macro parameters such as %USERNAME% in environment variables - that's the shell's job. As John pointed out, with proper quoting it should be possible to achieve just what you want.

Claus

[gmatelich]

I'm not sure if this is what you're after, but here the syntax I use to load a file based on an environment variable:

(load (format nil "~A/Macros/GregsTappedHole.lsp" (oli::sd-sys-getenv "SDSITECUSTOMIZEDIR")):if-does-not-exist nil)

[clausb]

You might also want to take a look at the Developer Kit functions sd-load-customization-file and/or sd-get-customization-file which allow to load your own special files using the same logic (corp/site/user hierarchy) as it is used for the standard customization files.

Claus

[MikeBoswell]

Thanks for the additional ideas. I might need to use one.

I have not tested this on some other machines, it may just be mine, but I still cant get my %USERNAME% to actually use its value (ie mboswell).

SDUSERCUSTOMIZEDIR=\\servername\common\OSDM\%USERNAME%
Also tried:
SDUSERCUSTOMIZEDIR=//servername/common/OSDM/%USERNAME%

I set both in the system-properties-advanced-envvar under system variables. This will create a directory named %USERNAME% not mboswell. The files in %USERNAME% do get loaded and cust are saved there but.........

[John van Doorn]

Mike,

What happens when you start a command prompt and type:
echo %USERNAME%

Does this return the expected value?


If it does,
Try set SDUSERCUSTOMIZEDIR=\\server\%USERNAME% in this command prompt window.
Check to see if the substitution works in this commandprompt window by typing set SD <enter>


If all the above works as expected, try to start OSDM from this command prompt.

[clausb]

I just set SDUSERCUSTOMIZEDIR to c:\home\%USERNAME% on my system (via the control panel), then started up OSDM. Sure enough, when I enter (display (getenv "SDUSERCUSTOMIZEDIR")) in the user prompt line, OSDM tells me that the environment variable is currently set to c:\home\clausb - i.e. the reference to %USERNAME% is automatically expanded. Looks fine to me.

Then I added an sd_customize file to the c:\home\clausb directory which displays a startup message in the output box and restarted OSDM. I see the startup message, so everything seems to work just fine here.

Claus

[MikeBoswell]

Did I say system variables?

It looks like that was the problem.

This all works fine if I set the variable as a 'user variable' thru the windows gui NOT as a 'system variable'>

Problem solved.

THANKS for the help.

[MikeBoswell]

OK
So 'user varialbe' works for the current user, but if a new user comes by and sits down at that machine he/she does not get the variable set.

When you guys tested it was it a user or system variable?

Do you know of a way to set it for all users?

Thanks,

[John Scheffel]

That is very odd. In Windows it should not matter if an environment variable is set as a user or system variable. Either way, it should become part of the environment when you boot Windows. The difference is that they are stored in different parts of the Registry. System variables are loaded first for any login, and the user variables are loaded second only for the userid that they are attached to. This means that user variables can change the value of system variables with the same name. However, once Windows has started they should all be part of the environment and I don't think there is any way to tell where they came from.

You might try setting it as a system variable, then logout and login. Open a command prompt window, then run the command "set". This will list all variables which are currently part of the environment, regardless of the source (Registry, Startup files, etc.). If you don't see the system variable, then something is not working correctly because it is not being set in the environment.

[clausb]

Interesting. When I set a system environment variable FOOBAR to %USERNAME%, then the contents of FOOBAR is, well, %USERNAME%, when I try it out in a DOS command window. So this confirms Mike's findings.

I think this actually makes sense, in a way. System settings apparently cannot depend on user settings, such as %USERNAME% in this particular case. I assume that when Windows evaluates system environment settings, it simply does not take user settings into account.

I'm sure that this problem comes up in other places as well, however, not just for SDUSERCUSTOMIZEDIR. I see several possibilities:

• Sneak in a batch file into the user login process which sets environment variables as needed. I know it can be done since our IT folks seem to do it, but don't ask me how.
• Redirect everybody's profile directories to a central server, either by changing the registry entries which control the location of the profile directories, or by using roaming profiles. Since all settings are then located on a central server anyway, there is no need for SDUSERCUSTOMIZEDIR anymore.

Claus

[MikeBoswell]

Thanks John and Claus,

Claus I have come to the same conclusion as you.
John I think you misunderstood a bit. Unders 'system var' %USERNAME% is not expanded.

My new approach, maybe.

Can I call a Dos command from my sd_customize file pointed at by the SDCORPCUSTOMIZE variable?

Something like..

(sd_exec_dos_command "set SDUSERCUSTOMIZEDIR=\\server\user_cust\%USERNAME%")

User custs are loaded after corp, so Im thinking this would work if the set will set for the sd shell.

Watcha think?

[clausb]

Won't work, unfortunately. This approach will set the environment variable, but only locally in the command shell which you are starting. As soon as the command shell terminates (i.e. after executing the "set" command), the environment variable is gone.

Even if you could set the "global" environment variable (global to the user, not to the system), OSDM wouldn't be able to pick it up. When an app starts, it gets a copy of the current environment (which contains all those system/user variables); it will from then on work with that copy. When the variable changes while the app is running (for example, because a user modifies the variable in the control panel), the app won't notice it unless you restart it.

However, the approach you suggest could still be made to work somehow. OSDM can modify its own copy of the environment variables by using the undocumented LISP command "putenv" (there might be an official IKIT command for this as well, I didn't check), so you could do something like this:

(putenv "SDUSERCUSTOMIZEDIR" (format nil "\\\\server\\share\\~A" (oli:sd-sys-getenv "USERNAME")))

This will retrieve the current value of %USERNAME%, build a proper server path based on that value, and modify SDUSERCUSTOMIZEDIR. It is not clear whether or not this is sufficient to redirect customization searches. OSDM might inquire the value of SDUSERCUSTOMIZEDIR from the operating system very early during the startup process, so changing the variable later on might not have any effect.

Good luck,

Claus