BUG: Ampersand in path causes ExecCmd to fail

[basilisk561]

Hello,

At install time I extract an EXE to $PLUGINSDIR.

On a page in the installer I attempt to shell out to this EXE as so:

ExecCmd::exec '"$PLUGINSDIR\myexe.exe" param1 param2 etc'

A certain Windows user is logged in with account username "Bob & Gina". The command shell attempt fails. Filemon reveals that ExecCmd is looking here:

C:\Documents and Settings\Bob & Gina\Desktop\G~1\LOCALS~1\Temp\nsw557.tmp\myexe.exe

When it should be looking here:

C:\Documents and Settings\Bob & Gina\LOCALS~1\Temp\nsw557.tmp\myexe.exe

Notice that "Desktop" is included in the incorrect path. This is because that is where the installer EXE is located and run from. If the installer EXE path changes, that is reflected in the path ExecCmd attempts to execute MYEXE.EXE from.

All other references to $PLUGINSDIR are evaluated properly -- installer INI files, etc. are correctly located. This is why I believe the problem resides with ExecCmd.

Any ideers on this?

FYI SetOutPath has no effect on this, in case that was a coming suggestion.

Thanks in advance!

[Red Wine]

Seems like you're right. What about included nsExec ?
Does it produce the same issue ?

[basilisk561]

Haven't tried nsExec.

I will say that it appears in the ExecCmd source that the code responsible for expanding $PLUGINSDIR and passing it to the plugins resides in NSIS itself. In other words, I would expect any plugins to have this same issue. ExecCmd just takes what it is given as far as the command line is concerned.

I would have thought this issue would have surfaced long before now. Or no?

Any things I can do like escaping the ampersand, etc. to get this working without a huge refactor like switching to nsExec?

[kichik]

The code that expands $PLUGINSDIR is indeed not present in any plug-in but in the installer itself. But as you said, it works fine in other places and the same expansion code is used everywhere so it's probably a problem with ExecCmd.

[basilisk561]

Originally posted by kichik
The code that expands $PLUGINSDIR is indeed not present in any plug-in but in the installer itself. But as you said, it works fine in other places and the same expansion code is used everywhere so it's probably a problem with ExecCmd.

Well, I don't have any personal evidence that $PLUGINSDIR gets handed off properly to plugins. Like you said, it does expand properly everywhere else.

What about the NSIS code that takes the plugin parameters and parses them into the array of strings for handoff to the plugin?

[kichik]

That's the code I meant. It's all the same for both plug-ins and other script parts.

[basilisk561]

nsExec works in this situation. I've changed my installer to that effect. No big deal.

Thanks to all who helped on this.

[Takhir]

Strange issue, might be good to have script sample. May be even reproducing situation without creation of special account
In ExecDos following 2 lines only work with path to executable

code:
popstring(ptp->dosExec);

...

if(!CreateProcess(NULL, ptp->dosExec, NULL, NULL, TRUE, 0, NULL, NULL, psi, &pi))

So I hope plug-in not changes path. To be sure I tested

code:
ExecDos::exec /NOUNLOAD /ASYNC /DETAILED /TIMEOUT=6000 "C:\Users\takhir\Documents\Kisa & Osja\consApp.exe" "test_login$\ntest_pwd$\n"

and this worked fine (while Windows permits ampersands in file/dir names).