Archive: Changing $TEMP path
Changing $TEMP path
I have a customer who has most of their user accounts set up as Restricted. On top of that they don't allow the users to write to the Temp folder under $WINDIR\temp or $TEMP. So, I'm wondering if there is a way for me to modify the $TEMP path. I'm figuring I'll set up a command line parameter for him to set the temp path. However, I tried setting $TEMP using -- StrCpy $TEMP "C:\newtemp" --and it won't compile. Is this not possible?
Use StrCpy in the .onInit function.
Ok, so what am I doing wrong? That's what I've been trying. I took the Basic.nsi script from the Modern UI folder and added:
Function .onInit
StrCpy $TEMP "C:\newtemp"
FunctionEnd
and it won't compile.
Function: ".onInit"
Usage: StrCpy $(user_var: output) str [maxlen] [startoffset]
Error in script "C:\Temp\Basic.nsi" on line 46 -- aborting creation process
You can't modify this variable, you should declare your own.
I would like to second this feature request. I am in a similar situation where I am not allowed to write to the C drive.
Right now, I am using my own directory but I then have to remember to delete these tmp files.
Is there a way that I can delete these files even if the user aborts the installation?
Thanks,
Thierry
See the documentation about callback functions.
But why not use the plug-ins directory ($PLUGINSDIR after calling InitPluginsDir)?
Modifying the $PLUGINSDIR doesn't really seem to solve the problem either. If I put a MessageBox as the very first thing in .onInit and then check the temp directory it has already written a file there (C:\Documents and Settings\andyg\Local Settings\Temp\nskC0.tmp). So, unless that temp file is there because I did a MessageBox it seems too late to change the plugins directory and use it as the temp folder. Is there a function before .onInit?
My client is claiming that my installs just won't work in his environment unless he can specify where the temp path is.
That isn't a file, it's a folder. Use it and it will be removed automatically (but don't forget to call InitPluginsDir).
It's actually a file for me. It's locked though, it won't even let me open it in Notepad. If I then click Ok on the MessageBox I get a folder after that with all my IO pages, bitmaps etc. I realize it renames itself everytime but in this instance I have a TMP file named nsbD3.tmp and then I get a nscD4.tmp folder after I click past the message box. I get the same result if I run the nsis20.exe install file. Both the temp file and folder do go away after the install is cancelled or completed. I'm running XP Pro SP1 if that matters.
That's probably the solid compression buffer. Don't use solid comression if you don't want it to be created.
Ok, I switched to using non-solid compression and the .tmp file did go away so that must have been what was causing that. I had to change things using MUI_INSTALLOPTIONS_EXTRACT_AS to File so that I could copy them into the user defined temp folder and that worked ok. However, plugins (like InstallOptions.dll), ioSpecial.ini and the header and wizard bitmap still go to the temp folder under profiles for that user. How can I get it so that these files will go into the usr defined temp folder? I'm thinking something like "InitPluginsDir c:\usertemp" would be great. I realize I may have to delete the files myself once the install is finished. Thanks,
You can call plug-ins the old fashioned way, with CallInstDLL. To avoid having to do that for every plug-in, you can get your first plug-in to change $PLUGINSDIR. $PLUGINSDIR is not changable from the script.
Are you saying that CallInstDLL will set the $PLUGINSDIR path or that my first plugin can somehow set the $PLUGINSDIR path? If the second is true is there an example of that somewhere? I've attached a modified version of Basic.nsi to illustrate what I'm trying. It ends up that the $PLUGINSDIR never gets set even after the call to CallInstDLL. The exdll.dll does get called though from the usertemp folder. The install runs but I have no idea where ioSpecial.ini and InstallOptions.dll are going.
The plug-in can change $PLUGINSDIR using the variables argument passed to its function. I suggest you simply examine what is passed in variables and see where the change is needed. The utility functions in exdll.h might help.
Awesome, I got the plug-in built and working. Here's what I did if anybody else is curious: I extract my DLL to whatever folder the user specifies on the command line and then call my DLL to change the PLUGINSDIR. Then I call InitPluginsDir from my script so that I can use the path and it also creates a unique folder under the user path, which is nice. Then I delete my DLL used to change the PLUGINSDIR and NSIS takes care of deleting the temp path it created and all the junk in it when the install finishes. I had to add a little code in .onInit but the rest of my script appears to work as is. If anybody wants more detail please ask. Thanks again kichik!
Do you mind posting a little bit more details about you made it happen? What does your dll like?
Thanks,
Thierry
The DLL didn't take much. I just took exdll and added this code to myFunction:
char buf[1024];
int e=-1;
popstring(buf);
e = myatoi(buf);
popstring(buf);
setuservariable(e, buf);
I ultimately ended up renaming the function and the DLL but that's about it besides adding the PLUGINSDIR to the enum in the header file. PLUGINSDIR then became #25 so when I call the DLL I used 25 to let it know which variable to change. Oh, I also had to grab the myatoi function from another example DLL.
SetOutPath $TEMPDIR
File /oname=$TEMPDIR\chngvrbl.dll "${NSISDIR} \Plugins\chngvrbl.dll"
Push $TEMPDIR
Push 25
CallInstDLL "$TEMPDIR\chngvrbl.dll" changeVariable
Several of my customers have been using this plugin in my installs with no problems. It was being used to change the $PLUGINSDIR. So, I thought that I would post the plugin to the Archive just in case anyone else could use it.