abcdgoldfish
26th May 2009 19:40 UTC

Overriding default dir with /D
My installer detects if it is running on a Vista or XP machine by using WinVer.nsh. Based on its results the installer installs code in one place or another. Works like a charm.

However, testers want to be able to install via the command line and use /D to override the installation directory. This is not working.

I am using this code:

Function .onInit
${If} ${AtLeastWinVista}
strcpy $INSTDIR "C:\Users\Public\Public Documents\blah"
${Else}
strcpy $INSTDIR "C:\Program Files\blah"
${EndIf}
FunctionEnd

Is there a way to override this code on the command line? If not then I will need a way to install via XP or Vista some other way. I'd appreciate any ideas or insights.

Anders
26th May 2009 19:50 UTC

I guess you could set installdir to something like "$programfiles\{117CCC32-4A26-11DE-A88F-DCAB55D89593}" and then see if its changed

abcdgoldfish
26th May 2009 21:15 UTC

I don't understand. The Vista installation should go under C:\Users\Public\Public Documents, not C:\Program Files. Also, where does the GUID come from and what does it represent?

Afrow UK
26th May 2009 21:35 UTC

If you use GetParameters followed by GetOptions (with `/D=`) then you can detect /D usage on the command line and jump over you code.

Edit: Ah sorry, /D will not show up in $CMDLINE!
Here is another idea. If $INSTDIR is not set to InstallDir before your code then you know /D has been used (not tried this but worth a try).

Edit #2: Or easier, if you don't use InstallDir at all then $INSTDIR will be empty unless /D has been used. This is assuming that /D is applied before .onInit is called (and so does the point in the first edit).

Stu

Anders
26th May 2009 22:18 UTC

My idea was the same as Afrow, just in a more stupid way, forget about checking for empty when i rushed to answer on my way out the door

msroboto
11th March 2010 20:33 UTC

I have tried everything in this post and I am stumped.

On a machine that already has my software installed I cannot detect if /D was passed or not.

$INSTDIR is set from the get go in that case.

I am not using InstallDir.

I tried setting InstallDir to something but it doesn't matter.

Is there a pre .OnInit function that I am missing?
Is there a way to know if /D was passed?

pengyou
12th March 2010 12:31 UTC

When you supply the /D option are you sure it is in the correct format, as described in the User Manual:

"It must be the last parameter used in the command line and must not contain any quotes, even if the path contains spaces. Only absolute paths are supported."

msroboto
12th March 2010 14:24 UTC

Yes if /D= is sent I get the correct value but I am trying to determine if /D was actually sent in or if it is coming from somewhere else.

If I am re-installing $INSTDIR is set and if /D is sent $INSTDIR will be set to whatever was passed.

I can't determine the difference.

I need to know if /D was passed on the command line.

I'm ok with the values.

pengyou
12th March 2010 14:43 UTC

Sorry, I misunderstood your question.

Have you tried Afrow UK's second idea:

If you don't use InstallDir at all then $INSTDIR will be empty unless /D has been used.

pengyou
12th March 2010 15:29 UTC

Afrow UK's idea works for me:

Name "/D Demo"
OutFile slash-d.exe

RequestExecutionLevel "user"

ShowInstDetails show

Section default
  DetailPrint "Command-line: $CMDLINE"
  DetailPrint ""
  StrCmp $INSTDIR "" no_slash_d_supplied
  DetailPrint "/D=$INSTDIR"
  Goto exit
  
no_slash_d_supplied:
  DetailPrint "No /D supplied ($$INSTDIR='$INSTDIR')"

exit:
  DetailPrint ""
SectionEnd

Command-line: slash-d.exe

No /D supplied ($INSTDIR='')

Completed

Command-line: slash-d.exe 

/D=C:\Program Files (x86)\Dummy\Install\Path

Completed

msroboto
15th March 2010 17:07 UTC

Run this script twice.
The first time it works.

The second time it will say that /D was supplied.

I know that the detail prints won't work in the on init so I am using a messagebox.


Sorry it took so long to get this little test together.

msroboto
15th March 2010 17:12 UTC

I see the issue now.

InstallDirRegKey is the culprit.

msroboto
15th March 2010 18:19 UTC

Sorry I fixed the test a bit and then couldn't attach again in the last post.