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

[clausb]

If you want to pursue the "execute batch script during user logon process" approach, here are a few links:

http://www.winnetmag.com/WindowsScripting/Article/ArticleID/20502/20502.html
http://www.computerperformance.co.uk/Logon/logon_scripts.htm
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q176/1/97.asp&NoWebContent=1
http://www.experts-exchange.com/Operating_Systems/Win2000/Q_20781573.html

Hope this helps,

Claus

[MikeBoswell]

Claus,

That command does set the variable, but like you suspected, too late in the load.

what if I set up a routine in the corp sd_customize that checked if the SDUSERCUSTOMIZEDIR was set. If yes continue if no set it permanently and restart OSDM or gracefully crash ?

I think a 3rd party setenv would set it permanently, or setx in the res kit maybe.

This has become a challenge at this point.
:mad:

Still having fun though.

Oh yeah Im triing to avoid the login batch approach.

[Markus]

Originally posted by clausb
... 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.

Yes, that's correct. It is not sufficient to assign a new value to this system variable. OSDM checks this variable very early in the startup process and stores its value in an internal variable.
I'm not sure why you want to change this variable, but you could try to assign a new value to ui::*corp-ui-cust-dir*. This might work, but I can't guarantee this.

Cheers,
Markus

[clausb]

If setting the environment variable in the customize files is too late, you can try to start OSDM with a -bootform script. Add the -bootform option in the command line for OSDM (you will have to modify the shortcut for this) and have it execute the putenv LISP code. The downside of this approach is that you will have to change the shortcuts on all systems where OSDM is installed, and that's probably not an option for you, either.

There doesn't seem to be silver bullet solution for this in your situation, or at least it hasn't occurred to me yet (ideas welcome). Most people trying to centralize their users' profile settings probably simply use roaming profiles which is a general OS mechanism meant to address exactly this problem. However, roaming profiles require a pretty homegenous setup on all systems using them. But then, I never tried to use roaming profiles before, so there might be interesting configuration options for Windows administrators to fine-tune them for your needs.

Claus

[Thom Ivancso]

Hello Mike,

You could use a VBScript placed in the users C:\Documents and Settings\username\Start Menu\Programs\Startup folder so that when the user logs in it would run automatically. I wrote one that works great it writes into the system or users environment a SDUSERCUSTOMIZEDIR variable set to C:\username\sd_user folder and I then wrote a user_customize file the just displayed a message box. I will include the VBScript called UserName.txt, just rename it to UserName.vbs and run it. The script has the code for placing the variable in either the system or user environment.

I hope this helps.

Cheers
Thom

[Thom Ivancso]

Forgot to post the file, here it is.

:rolleyes:

Cheers
Thom

[John Scheffel]

Originally posted by clausb
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.
That does make sense. Since the system variables are set first and user variables second, a system variable cannot expand the value of a user variable.

Another option would be to start Modeling with a batch file which sets the variable then calls the standard startup executables. You can then modify the shortcut which starts Modeling to run the batch file. A simple batch file would be something like:


set SDDIR=C:\Program Files\CoCreate\OSD_Modeling_12.0.0.8
set SDUSERCUSTOMIZEDIR=\\servername\common\OSDM\%USERNAME%

chdir /d %SDDIR%\binNT
"%SDDIR%\SD.exe" "%SDDIR%\binNT\SolidDesigner.exe" %1 %2 %3 %4 %5 %6 %7 %8 %9

[Wolfgang]

you can put a BATCH file into c:\document_and_settings\<user>\startmenu\program\autostart

this batch might contain something linke

set SDUSERCUSTOMIZEDIR=somewhere\%USERNAME%\....

hmmm.. will this work?

at least this is working for me to do a subst command. . but I fear that this ENV variable is again only valid for this (temporary) dos shell..

Just an idea..

may be the more modern versions of windows have somthing like an 'export' in their dosshell?

[MikeBoswell]

Wolfgang, John, and Thom,

Thanks for the latest suggestions.

I am going to do my best to avoid revisiting (physically or remotely) all of the seats to set this up. I like to exploit my the most convient approach which a little bit of exported/imported registry has allowed me to do w/ the SDCORPCUSTOMIZEDIR. That is all in place and it is great when I can just plug something new in and everyone gets it on the next session. Cant argue w/ that.

Sooooo........

Does anyone know the OSDM command that would allow me to kick off a batch file on startup of OSDM.

IF var is set, continue
else
I will use this command to run a bat that will perm set the var
Then command (exit) to shutdown and relaunch the OSDM session.

I think this is worth a try.

So anyone know the command that accesses win2000 commands from within OSDM?

THANKS A TON FOR ALL THE INTEREST AND TIME.

Mikeb

[clausb]

Once again, setting an environment variable from a batch file which you start from OSDM will NOT change OSDM's environment, i.e. your copy of SDUSERCUSTOMIZEDIR will NOT change.

For this reason, I don't think it will help you much to know that the official Integration Kit function to start external commands is (oli:sd-sys-exec "somecmd").

Claus

[MikeBoswell]

Thanks,

Actually, Thom's vb scipt should work.

Thom, do you know of a way to force windows to reread it's env so that the user does not need to logout/in??

I will set the var , if it is not already, and force the session to close. The var will be picked up as soon as the user launches the follow-up session.

Worst case the user will need to logout/in in order to pick up the new SDUSERCUSTOMIZEDIR.

(if (equal (oli:sd-sys-getenv "SDUSERCUSTOMIZEDIR ") nil) [(display "setting SDUSERCUSTOMIZEDIR, please relaunch session") (oli:sd-sys-exec "Thom's VB") (sleep 5) (exit)] (display "already set"))

2 things about the above:
1. How do you say 'if (not equal ( xxxxx' in LISP or is the 'nil' thing an OK approach for the var not being set.
2. I get errors running mult command in the 'then' statement. suggestions?



Thanks everyone .

Mike Boswell

[clausb]

To force a system-wide update of environment variables, you need to fire the WM_SETTINGCHANGE event (in broadcast mode). See http://msdn.microsoft.com/library/en-us/wceui40/html/cerefWM_SETTINGCHANGE.asp and http://msdn.microsoft.com/library/en-us/dllproc/base/environment_variables.asp for details.

For your LISP questions, check the Common LISP reference manual at http://www.lispworks.com/reference/HyperSpec/ or the LISP introduction at http://psg.com/%7Edlamkins/sl/contents.html. There is also a short introductory text on LISP in the Integration/Developer Kit documentation which is installed along with OSDM.

Claus

[Thom Ivancso]

Hello Mike,

Glad the VBScript worked. If you have the VBScript set the user environment variable the user will not need to log out and in again to have it set. Normally user variables take as soon as they are set, unlike system variables that require a re-boot. You can also write a checking routine in the VBScript to check to see if the variable is set or not. Also as far as single point customizations and administrations go, you can place the VBScript on a shared access drive and copy a shortcut of it in to the users C:\Documents and Settings\username\Start Menu\Programs\Startup folder. This way if you want to make a global change you can and the shortcut will pick it up as soon as you save the changes.


Hope this helps
Happy Holidays
Thom

[MikeBoswell]

So here is what Ive got:

In the SDCORPCUSTOMIZE sd_customize:

(if (equal (oli:sd-sys-getenv "SDUSERCUSTOMIZEDIR") nil) (oli:sd-sys-background-job "\\\\server\\users\\me_common\\vicor_cust_nt\\corp_cust\\run_user_cust.bat"))
(if (equal (oli:sd-sys-getenv "SDUSERCUSTOMIZEDIR") nil) (exit))

In the SDCORPCUSTOMIZE directory:

run_user_cust.bat

--> bat consists of:

\\serveri\users\me_common\vicor_cust_nt\corp_cust\username.vbs
\\server\users\me_common\vicor_cust_nt\corp_cust\SD_shutdown.html


It works like this:

-user kicks off SD session.
-SDCORPCUSTOMIZEDIR sd_customize checks if SDUSERCUSTOMIZE var is set.
-if set (life goes on)
-if not set runs Thom's vb script setting var
-exits SD
-shows an html message explaining what happened.

The user must log off log in to windows to pick up the SDUSERCUSTDIR.
Also, any local custs must be copied to the SDUSERCUSTDIR.

This will allow users to travel w/ their custs. (ie conference rooms, other PC's)