Well, a wonderful day to all of you first!

But unfortunately, this is not the cause of my post

I got a little problem with wihu...

edit: solved, i forgot to use "command.x=cmd.exe /c install.cmd"

If I install something by calling a self-extracting archive, all works fine.

description.2.0.0=Logitech MouseWare 9.79.1
command.2.0.0=drivers\input\Logitech.MouseWare.9.79.1.exe
selected.2.0.0=1
hidden.2.0.0=0

But if I install something started from a batch file, problems arise:

description.0.1=SpyBot S&D 1.3
workdir.0.1=software\SpyBotSD
command.0.1=install.cmd
selected.0.1=1
hidden.0.1=0

This brings up "install.cmd completed.", but nothing gets executed!

Then I thought I put the "software\SpyBotSD" in the command.0.1, just to test, but then I get the following (not really descriptive, but *there* the description.x name is used ) error:

Status:1, "SpyBot S&D 1.3" wurde mit Code 1 beendet. Grund: Unzulässige Funktion.

(means: Status:1, "SpyBot S&D 1.3" has ended with exitcode 1. Function not available/accessible/somethinglikethat )

These are also everything that turns up in the logfile when I start wihu with the /verbose and /log switches...

What is the error I keep making? edit: not placing cmd.exe /c before "install.cmd"

I used wihu 2.1.10.2 for this. (edit: 2.1.10.3 and 2.1.6.0 do not work this way, too)

Thanks in advance for all answers.

Greetings,

C.RAZY

Yeah, you already found it on yourself:

batch files (.cmd, .bat, ...) have to be called by ...

command.0=cmd /c @batchfile.cmd
workdir.0={relative path to batch file!!!}

Besides I recommend calling MSI-files always by ...

command.0=msiexec /i msifile.msi ...
workdir.0={relative path to msi file!!!}

... and MSP-files by ...

command.0=msiexec /update mspfile.msp ...
workdir.0={relative path to msp file!!!}

Besides me never forgetting cmd.exe /c for batch files again (and for completeness did the msiexec /i (or /update) to msi/msp-files even before my problem arose), can anyone explain just *why* this is the case with such files?

I am just curious, as i now have found workarounds to all my problems B)

HAND,

C.RAZY

can anyone explain just *why* this is the case with such files?

Explain what?

batch files (.cmd, .bat, ...) have to be called by ...

command.0=cmd /c @batchfile.cmd
workdir.0={relative path to batch file!!!}

explain why they *have to* be called with cmd.exe /c

I just don't get why they can't be executed from wihu without the "cmd.exe /c" ...

Exactly, I would like to know why this is not an *option*, like normally "doubleclicking" a file.msi *OR* in a command shell, run "file.msi" *OR* running it through msiexec /i file.msi ...

TIA,

C.RAZY

explain why they *have to* be called with cmd.exe /c

That's not as easy as you think, but I'll change the code next days.

Sorry for not beeing here last days, but I had 1 harddisk failure, it's damaged now and many data were lost. So I had no time to take a look at this forum.

Benjamin

explain why they *have to* be called with cmd.exe /c

That's not as easy as you think, but I'll change the code next days.

Sorry for not beeing here last days, but I had 1 harddisk failure, it's damaged now and many data were lost. So I had no time to take a look at this forum.

Benjamin

Sorry, I should have thought first about the possibility that the misunderstanding lies not between me and some programmer (in this case, you and the one who wrote the "workdir.x"-feature, don't recall his name yet), but indeed between me and microsoft...

as my misunderstanding of programming concepts often has to do with this source.

And sorry for your hard drive failure, these things come across in the worst moments...

Hope it works out in the least negative way...

C.RAZY

explain why they *have to* be called with cmd.exe /c

That's not as easy as you think, but I'll change the code next days.

Benjamin

But why change this? It is just usual behaviour that batch files are called by cmd /c, isn't it.

But why change this? It is just usual behaviour that batch files are called by cmd /c, isn't it.

Yes, but before many other complains about it here

I think this will not take entire weekend to implement.

Benjamin

So I implemented registry shell\open\command execution as I said. command.x will be checked against registry if command is found there it will be used and each %1 ... %x placeholder in registry HKCR\<key>\shell\open\command will be replaced by corresponding specified arguments.

for example you'll find following command for .exe files in registry:

HKEY_CLASSES_ROOT\exefile\shell\open\command

"%1" %*

So if you would create a command.0 = test.exe 1 2 3

this will be replaced by "test.exe" 1 2 3

Inexplicably the command for .cmd and .bat files are the same which mean it should be executable directly too, which isn't the case during windows installation as I tested it once. So it is better to still use cmd.exe /c here.

Benjamin