Old 4th January 2011, 16:48   #1
nsnb
Senior Member
 
Join Date: Jul 2008
Posts: 157
Question Best Practices for Debugging NSIS Scripts?

I am embarrassed to admit that I have been going very long writing hundreds of NSIS scripts (with varying degrees of complexity) without ever using a debugger. So far, I have been able to get away with it, but every once in a while I stumble upon a problem that makes me wish there would be a way to single-step or view some console output.

What is the recommended way to debug NSIS scripts?

Is it the same for scripts that have 'SilentInstall silent' and 'SetSilent silent' on?

More specifically, I have a single line that doesn't work for some reason, but I have no clue why, because the NSIS script has 'SilentInstall silent' and 'SetSilent silent' on:

PHP Code:
  ReadEnvStr $varCOMSPEC COMSPEC
  nsExec
::Exec '"$varCOMSPEC" /C "$SYSDIR\attrib $PROFILE\Desktop\*"  > dtattr.txt ' 

Last edited by nsnb; 4th January 2011 at 19:03. Reason: typo in posting (not in actual script)
nsnb is offline   Reply With Quote
Old 4th January 2011, 18:01   #2
CrushBug
Senior Member
 
Join Date: May 2005
Posts: 119
Our biggest sanity saver is a logging macro that allows us to log to a text file in Documents and thus we can just add in a ${LogWrite} "varCOMSPEC=$varCOMSPEC" or return codes or what have you. We can also do log levels and wrap certain logging in a "${If} $LogLevel > 1" block.

After that, there was a Debug/DumpState plug-in that we used to use (although looking on my system right now, I can't find it anymore). This plug-in with put up a dialog with current variable and stack states. I don't know if it would work in a silent installer as we haven't specifically tried it in that state.
CrushBug is offline   Reply With Quote
Old 4th January 2011, 18:08   #3
blh83
Junior Member
 
Join Date: Aug 2010
Posts: 29
Well I usually use message boxes but those don't typically show in silent installs. I have noticed that using a banner shows up even on silent install (this may not be on purpose, but it could be a useful bug for you ). So you could do something like:

Banner::show "Some stuff ${some variable}"
;you may have to put an artificial delay here depending on what you're doing.
Banner::destroy

Also, looking at what you are trying to do, I am wondering why you are needing the ENVIRONMENT variable COMSPEC? I understand it holds the path to cmd.exe, but is it necessary to call cmd.exe? could you simply run:

nsExec::Exec '"$SYSDIR\attrib $PROFILE\Desktop\*" > dtattr.txt ' ?

Also, you spelled "attrib" wrong (you've got "atrrib"). As a side note, the attrib function also expects some sort of attribute to be passed in before the file name for which you are modifying. So I would expect to see something like:

nsExec::Exec '"$SYSDIR\attrib R $PROFILE\Desktop\*" > dtattr.txt ' for Read only.

I haven't used 'attrib' much so these are simple observations that may not be helpful.

When I run into problems calling an executable, I always open an actual command prompt and try it from there (by copying and pasting the relevant text from my installer so as to catch spelling errors like the one above). Hope this helps.
blh83 is offline   Reply With Quote
Old 4th January 2011, 19:08   #4
nsnb
Senior Member
 
Join Date: Jul 2008
Posts: 157
Lightbulb

Quote:
Originally Posted by blh83 View Post
Well I usually use message boxes but those don't typically show in silent installs
That's what I've been using too. Interestingly, in my silent install MessageBox does show up, so it helps.

Quote:
Originally Posted by blh83 View Post
Also, you spelled "attrib" wrong (you've got "atrrib").
You are correct. That was a typo in the posting, not in the script (I usually copy & paste verbatim but this time I failed to do so).

Thanks.
nsnb is offline   Reply With Quote
Old 4th January 2011, 19:12   #5
nsnb
Senior Member
 
Join Date: Jul 2008
Posts: 157
Question

Quote:
Originally Posted by CrushBug View Post
Our biggest sanity saver is a logging macro that allows us to log to a text file in Documents and thus we can just add in a ${LogWrite} "varCOMSPEC=$varCOMSPEC"... We can also do log levels and wrap certain logging in a "${If} $LogLevel > 1" block.
I looked at the NSIS User Manual but I couldn't find ${LogWrite}. Is that a plugin? Where do I find it?

Thanks.
nsnb is offline   Reply With Quote
Old 4th January 2011, 22:46   #6
CrushBug
Senior Member
 
Join Date: May 2005
Posts: 119
It was just an internally developed set of macros that use the built-in NSIS FileOpen 'a', FileSeek END and FileWrite $LogString commands. I would like to post the code and some future date, but we are in the middle of finalling a project right now, so it will be some time before I can get to it.
CrushBug is offline   Reply With Quote
Old 4th January 2011, 23:38   #7
LoRd_MuldeR
Major Dude
 
LoRd_MuldeR's Avatar
 
Join Date: Sep 2005
Location: Somewhere over the Slaughterhouse
Posts: 797
Something like this should be sufficient:

code:
Var mylogfile

Function .onInit
FileOpen $mylogfile "$TEMP\nsislog.txt" "a"
FunctionEnd

!macro _LogWrite text
FileWrite $mylogfile '${text}'
!macroend

!define LogWrite !insertmacro _LogWrite


My Plugins: StdUtils | NSISList | CPUFeatures | ExecTimeout | KillProc
My source of inspiration: http://youtu.be/lCwY4_0W1YI
LoRd_MuldeR is offline   Reply With Quote
Old 5th January 2011, 07:36   #8
T.Slappy
Major Dude
 
T.Slappy's Avatar
 
Join Date: Jan 2006
Location: Slovakia
Posts: 535
Send a message via ICQ to T.Slappy
Maybe you could use this: http://nsis.sourceforge.net/Nsisdbg_plug-in

Quote:
NSIS Debugger is a NSIS plugin which allows you to debug your NSIS installers. The plugin will create a dialog which will be displayed alongside the NSIS window. The first thing you will get familiar with is the tabbed pages. Use them to switch between variable list, stack view, debug log, config. and about page.
I did not test it, but it seems good.

Cool looking installer with custom design: www.graphical-installer.com
I offer NSIS scripting, C/C++/C#/Delphi programming: www.unsigned.sk
Develop NSIS projects in Visual Studio 2005-2019: www.visual-installer.com
or RAD Studio 2009, 2010, XE-10.3 Rio: www.rad-installer.com
T.Slappy is offline   Reply With Quote
Old 6th January 2011, 09:40   #9
Marshall7a
Junior Member
 
Join Date: Oct 2004
Location: UK
Posts: 33
I wrote a set of macros specific to my project that logged the name of the function/section, the values of all the registers, and the contents of the stack (using the stack plugin). Then, at the start and end of every function/section I called a "DebugPre" and "DebugPost" macro which wrote out all that information, as well as storing it in another huge set of registers dedicated to the purpose. That way, I could tell if the registers or stack were getting messed up by any function automatically (it would pop up a message box if there was an error at the end of a function).

Of course, this took a while to implement and debug the debug code so that it was stable and didn't cause any problems itself.

And a basic installer produced a 50MB log file when there were no errors.

You might call it overkill, but for a big/complex project it might be worth it - I was surprised by how many register/stack issues I had introduced that went unnoticed 99% of the time. (It depends on how functional you make an installer, and how many levels deep your macro/function calls go)

Although I do have to disable the debug code when releasing an installer because, even without the log file, it still slows down the installer a lot.

I've never been very sure about what is right. I'm not even sure that there is such a thing as right. Or wrong. Just places to stand.
Marshall7a is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Developer Center > NSIS Discussion

Tags
debug

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump