Hi Joe, Joe wrote: > Maybe expanding could be an command line option? At any rate, the > reason I asked was that I had a situation where I set: > > set SOFTWARE=%WPKGROOT%\Programs\ > > Then in some packages... > > <install cmd='"%SOFTWARE%\thunderbird\Thunderbird Setup 2.0.0.14.exe" > -ms' /> > <install cmd='"%SOFTWARE%\firefox\Firefox Setup 2.0.0.14.exe" -ms' /> > <install cmd='"%SOFTWARE%\PDFCreator\PDFCreator-0_9_5_setup.exe" > /VERYSILENT /NORESTART /SP-' /> > > These somehow all installed correctly with the trailing slash on SOFTWARE. > > The next would not install and I could not figure out why... > > <install cmd='msiexec /qn /i %SOFTWARE%\OpenOffice\openofficeorg24.msi' /> > > I had a 1619 error but could not understand the problem since the prior > three packages worked. I finally created a package to dump the environment > vars to a file and then noticed my mistake. I still don't understand > why it > worked for the first three. Probably because of quoting - your SOFTWARE variable is not quoted in the last example. This means it might fail if SOFTWARE contains spaces. Using <install cmd='msiexec /qn /i "%SOFTWARE%\OpenOffice\openofficeorg24.msi"' /> might help. But also this would not be much better to trace if variables are expanded. In general I don't want to introduce new parameters and switches for every small detail. Else we end up in a total mess of parameters and almost for each WPKG line of code we have a switch to enable/disable something. This is not user-friendly any more. In your case simply inserting a second command (which is for sure executed within the same context) would allow easy debugging: <install cmd='cmd /c set > "%TEMP%\debug-env.txt"' /> <install cmd='msiexec /qn /i "%SOFTWARE%\OpenOffice\openofficeorg24.msi"' /> br, Rainer |