I have a customer using Host Intrusion Protection and has set every User's temp folder not to allow execution (C:\users\\AppData\Local\Temp). NSIS extracts all plugin dlls and its own dlls into a folder below %TEMP%. The problem is nothing is allow to execute from temp so the entire install fails. What I need to know is how to tell NSIS to use a different folder. The only work around I can find is to edit the TEMP and TMP values under the registry key HCU\Environment from "%USERPROFILE%\AppData\Local\Temp" to something like C:\NSISTEMP. However even though this works changing the registry and then putting it back is not really an option. I also cannot just redirect InitPluginDir as that only effects plug-ins and not the rest of what NSIS extracts (icons xml files etc...). Any ideas?s
You can set %TMP% in a terminal/console window before running the installer, there is no need to edit the registry.
In NSIS v3+ you can use UnsafeStrCpy:
Function .onInit
UnsafeStrCpy $Temp "c:\foo\bar"
CreateDirectory "$Temp"
FunctionEnd
The real problem is the security "solution", why would preventing execution from %Temp% but not from other directories really provide any protection after the bad guys find out about this restriction?
If the installer is started with the special _?=$InstDir parameter then it is not copied to %Temp%.
Try this (look for more info in documentation) maybe it is safer than overriding $Temp folder and so on.
I just tried to redirect my code output to my code file itself, all contents in my code file are gone, any methods to recover?
What can you do to recover the file you overwrote? Virtually nothing as the disk blocks that were freed when file was truncated are likely the first ones overwritten.
What to do to avoid it? Use Version Control religiously (I prefer mercurial because it is the lightest for single-person projects).
You could also set the "noclobber" option in the shell set -C which will disallow
redirection_to > an_existing_file
with the message "cannot overwrite existing file". But don't do this. It is a generally bad practice because the one time you are in a shell without noclobber set, you will accidentally overwrite a precious file.
I have an installer working with NSIS that I'm updating at the moment. At several points, the installer needs to configure packages by replacing paths or values inside configuration files. Those configuration files have placeholders in them that are replaced by whichever deployment tool I'm using (NSIS for this specific case).
Scripts are mostly PHP scripts written to do some simple tasks that would have been excruciatingly complex in NSIS. For some reason though I keep going back to making my PHP scripts replace the placeholders by themselves instead of doing it in the NSIS script, which just isn't right.
My code looks like:
nsExec::ExecToStack '"$INSTDIR\Php\php.exe" "$INSTDIR\Apache\tools\findport.php"'
pop $1 ; return code
pop $2 ; port number
!insertmacro _ReplaceInFile "Apache\conf\httpd.conf" "APACHE_PORT" "$2"
The _ReplaceInFile macro comes from http://nsis.sourceforge.net/ReplaceInFile and works just fine if I use $INSTDIR instead of $2 in the above example. Showing $2 in a MessageBox shows the port number just fine.
I guess I'm doing something wrong but I can't figure out what it is, and debugging is a pain with NSIS.
Thanks,
I guess the lesson is to always verify paths before blaming the utility functions (Using Process Monitor is a good idea so you can tell if file-system redirection is getting in the way)
I would also like to add that using $instdir to hold anything other than a path is not a good idea since it will strip away invalid path characters behind your back. Use a normal register or a custom variable...
When working in the ocaml or ghci toplevels I often build up a significant "context" for want of a better word, values bound, functions, modules loaded, and so on. Is there a way to save all of that and reload it later so I can continue exactly where I left off? Or better yet, dump out the entire lot as a text file that could be reloaded or be trivially modified into code that I could compile into an executable (e.g. by adding a Main)?
Users of HOL light have had similar needs, and they use a checkpointing program to save a snapshot of the toplevel. See this message on the caml mailing-list, or page 8 of this HOL tutorial.
In general it is better to keep the definitions as source code, rather than a binary toplevel snapshot. Numerous tools allow to quickly load a .ml file into the toplevel for easy experimentation (emacs modes, etc.). See the warning in the HOL tutorial:
When developing large proofs in HOL, you should always keep the proof script as
an OCaml file ready to reload, rather than relying on ckpt. This will allow the proofs
to be later modified, used by others etc. However, it can be very convenient to make
intermediate snapshots so you do not have to load large files to work further on a proof.
This is analogous to the usual situation in programming: you should always keep your
complete source code, but don’t want to recompile all the sources each time you use
the code.
At least in OCaml there's no built-in support for that. On solution is to use rlwrap or any other readline wrapper to record your input's history to a file. For example :
> rlwrap -H mysession.ml ocaml
The drawback is that this will also record the input that had syntax errors so you'll have to clean that out. Note that by default rlwrap will automatically save your input in ~/.ocaml_history if you invoke it without the -H option.
In Haskell, just use :e file. This opens the standard editor and lets you edit some file. Afterwards, use :r to reload it. It will be automatically recompiled.
Please notice, that all your "ad-hoc" defined functions will be lost after this. Refer to the doc for more information.
ghci uses haskeline for commandline input history, so you can scroll up to repeat/edit inputs. Your input history is usually recorded in a file, which you can find as ghci_history in the directory given by
System.Directory.getAppUserDataDirectory "ghc"
There are various commands to explore the 'context' (:show bindings, :show modules, :def, ..) but their output won't suffice to reproduce your session (though it is worth knowing about them anyway).
In general, the advice to combine your ghci session with an open editor window is sound: if it is more than a throwaway definition, even if just for debugging purposes, better include it in a module to be loaded into ghci, so that you can reuse it.
Oh, and if by 'context', you mean some default settings or modules you want loaded, on a per-project basis, there is also ghci's configuration file. Also handy for defining your own ghci commands.
In ocaml, you can build your own top-level. It solves problem with loaded modules at least.
http://caml.inria.fr/pub/docs/manual-ocaml/toplevel.html#sec278
The ocamlmktop command builds OCaml toplevels that contain user code
preloaded at start-up.
The ocamlmktop command takes as argument a set of .cmo and .cma files,
and links them with the object files that implement the OCaml
toplevel. The typical use is:
ocamlmktop -o mytoplevel foo.cmo bar.cmo gee.cmo
This creates the bytecode file mytoplevel, containing the OCaml
toplevel system, plus the code from the three .cmo files. This
toplevel is directly executable and is started by:
./mytoplevel
This enters a regular toplevel loop, except that the code from
foo.cmo, bar.cmo and gee.cmo is already loaded in memory, just as if
you had typed:
#load "foo.cmo";;
#load "bar.cmo";;
#load "gee.cmo";;
on entrance to the toplevel. The modules Foo, Bar and Gee are not
opened, though; you still have to do
open Foo;;
yourself, if this is what you wish.
This has always bothered me too, so I wrote a quick python/expect script to replay ghci_history at the beginning of each ghci session.
It's not very polished. For example it always replays the whole history and that could be slow.
I wanted to write an NSIS script, let's call it for now setup.nsi, and check
if several required dll files already exists in $SYSDIR
Let me emphasize on the word "several"
What I understand from nsis IfFileExists documentation is that if I type in:
IfFileExists $SYSDIR\blabla.dll +2 +1
then it checks if blabla.dll is in $SYSDIR .. but what if I want to know if *.dll from where setup.nsi copies the file (i.e. the *.dll's that I am interested in installing in.. and they are a lot of them.. so I can't just go around checking for all the names) exists in $SYSDIR
During uninstallation I want to then be able to delete them from $SYSDIR (using some uninstall.log to see if I really copied them in $SYSDIR.. and again the wildcard question).
Please be patient with me as I am really new to NSIS scripts.
Is it REALLY necessary to write and delete in $SYSDIR ? Unless yours is a system file, there's no reason for it to be in $__SYS__DIR. If you need to use a specific version of a library, consider DLL redirection (put your DLL in your app dir and use the .local feature) - see the MSDN article on DLL redirection and Side-by-side assemblies.
Plus, you are one typo away from wrecking the user's computer ("Deleted: C:\Windows\System32\user32.dll").
As Piskvor mentions, I don't think you should be worrying about deleting system DLLs in the uninstaller. In case you want to overwrite system DLLs with an updated version, you may want to look at the SetOverwrite command. It lets you overwrite files if what you've got is newer.
Windows XP (SP2?) and up has file protection for system32, so you can't overwrite system critical files in there.
Do try to stay away from that.
Also, to check for your file specifically, see if there's a plugin for NSIS that can calculate checksums and compare that on uninstall. That's probably the safest, IF you really need to do it.
I'd suggest install files somewhere else and add that to PATH.