NSIS nsProcess Plugin: Always returns "process not running" - unicode

Context
We are using NSIS 3.05 with Unicode true (this is important later).
We need to check if a certain process is running, let's call it "processToFind.exe".
In order to do that, we have been using nsProcess Plugin, which is set up correctly, found and integrated just fine.
We include Plugins from our git repository like this:
!addincludedir "C:\pathToRepo\NSIS\Include"
!addplugindir "C:\pathToRepo\NSIS\Plugins"
where pathToRepo is of course a valid path. We also tried using the default Plugin Directories (NSIS-Dir\Plugins\x86-unicode) to no avail (see below).
Documentation says, nsProcess (v 1.6) does suppport unicode. That's why we chose to use it.
NSIS UNICODE support (just rename nsProcessW.dll into nsProcess.dll)
When setting Unicode false or leaving the setting out (so default is ansi), it is working fine, too. ( = running processes found, not running processes not found )
The Installer is 32 bit, we are running on 64 bit Windows 10 machines.
Code
${nsProcess::FindProcess} "procexp.exe" $R0
MessageBox MB_OK "procexp: [$R0]"
which is defined in nsProcess.nsh (provided by plugin, not own code)
!define nsProcess::FindProcess `!insertmacro nsProcess::FindProcess`
!macro nsProcess::FindProcess _FILE _ERR
nsProcess::_FindProcess /NOUNLOAD `${_FILE}`
Pop ${_ERR}
!macroend
Problem
When having set Unicode true , nsProcess will always return 603 ("Process was not currently running").
That's the same, regardless if we try to find 32-bit or 64-bit processes.
That would be expected for 64-bit processes (they cannot be found from 32-bit installers, which is ok for us).
But I do expect it to find 32-bit processes.
Alternatives already explored:
Going through the list found at Check whether your application is running ...
Processes Plugin : Seems outdated, only sourcecode found.
"FindProcess.nsh" : Naming collision, didn't work, neither. Same symptoms.
DDE Server / Win32 Sync / Registry: Not an option.
"tasklist" command: Same symptoms. When executed in cmd, it works but not from installer.
nsExec::ExecToStack '"%SystemRoot%\System32\tasklist" /NH /FI "IMAGENAME eq ${processName}" | "%SystemRoot%\System32\find" /I "${processName}"' always returns "error". (* it's clear now why, see edit below)
"FindProcDLL" Plugin : skipped because
As of NSIS 2.46 this plugin no longer works...
Seemingly related Stackoverflow Questions explored:
NSIS : NsProcess UnExpected Output
Solution was to remove Unicode=true, which I cannot do.
NSIS- FindProc always returns 1
Uses FindProcDLL
NSIS - check if process exists (nsProcess not working)
Error was "Plugin not found" , which we do not have.
I am sure, we are making some "stupid" mistake since I cannot bring myself to believing we are the only ones with that requirement. So, any hints, suggestions and alternatives that are not listed above (or corrections to the above) are welcomed.
Edit
We totally messed up the tasklist call. As #Anders pointed out in comment: nsExec does not support pipes and on top of that, the syntax was also messed up.

Does official example work for you? It works on my machine.
Try this:
0) Delete all nsProcess.dll files (in NSIS, in your include folders, everywhere)
1) Remove line !addplugindir "C:\pathToRepo\NSIS\Plugins" from your script to use plugins in NSIS directories
2) Copy file nsProcessW.dll into **c:\Program Files (x86)\NSIS\Plugins\x86-unicode**
3) Rename file c:\Program Files (x86)\NSIS\Plugins\x86-unicode\nsProcessW.dll -> nsProcess.dll
4) Compile your script with Unicode true
I believe there is some file mismatch. To understand NSIS plugins structure see NSIS - check if process exists (nsProcess not working) .

I'm still using ANSI because I'm using some other plugins that don't have a Unicode variant, so nsProcess works for me, and I'm not sure how to answer your main question.
However, re: the tasklist command alternative you listed, the syntax isn't quite right. You're missing a closing quote after "IMAGENAME eq ${processName}["] and an opening quote before ["]${processName}" in the pipe to find.exe.
Also FYI note that if you use %SystemRoot%\System32\, a 32-bit process will be redirected to C:\Windows\SysWOW64\, and some programs have no 32-bit equivalent (e.g., pnputil). In this case, it doesn't really matter, but in any event to get around this, you should use $WINDIR\SysNative instead. You can also use ${DisableX64FSRedirection} from x64.nsh, but there are apparently some potential pitfalls there.
EDIT: Ah yes, and there's the issue with pipe and ExecToStack mentioned by Anders in the comments to the original question, requiring the call to be prefixed with cmd.exe /C

Related

code --diff fails when filename contains an ampersand '&'

I am experiencing a rather puzzling error while trying to perform a diff on two files using Visual Studio Code from the command line. I have a text file in the cloud where I save some work related notes. I need to resolve conflicts with other clients editing the file. Usually this only happens during a loss of connection though somehow I find myself having to resolve a lot of them so between this and other uses of diff I will use the usual syntax. It looks something like this:
code --diff "R&D (cloud conflict 2-5-23).txt" "R&D.txt"
My filename happens to have a '&' in it and this command launches the usual 2-way diff in VS Code and reads through the first file name with no problem but doesn't read past the second '&' and the resulting diff tab in VS Code looks something like:
R&D (cloud conflict 2-25-23).txt <-> R
Where the right side "R" doesn't exist. So it would seem '&' needs to be processed literally.
No problem, let's see if backslash \ is an accepted escape parameter...
code --diff "R\&D (cloud conflict 2-5-23).txt" "R\&D.txt"
Nope. Same problem. 🤔 In fact this outputs something even stranger:
Code diff tab:
&D (cloud conflict 2-25-23).txt <-> R
with shell output:
'D.txt' is not recognized as an internal or external command, operable program or batch file.
I also tried the carrot symbol '^' as an escape parameter to a similar effect. I just includes it in the first file and the editor still thinks the second file name is just "R".
The help file for the VS Code command line integration didn't have a lot to say about the --diff parameter other than a short description and I was hoping to get something about processing strings literally or escape characters. Perhaps another parameter that I need or maybe this has more to do with the shell in general.
I find it really strange that it can read the first full file name but breaks at the second '&'. Weirder still that if a supposed escape character is included in the second file name, it will omit that as well. 😵
For now all I can do is rename the file which is a bummer. 🤷‍♂️ I have VS Code version 1.75.0 on Windows 10 Home latest version/build and I'm using PowerShell version 5.1.19041.2364.
Edit: The issue definitely appears to be PowerShell related as it turns out. I was finally able to run this command successfully in a regular command prompt. (Simply typing "cmd" and Enter into the PowerShell window before running the diff command). Unfortunately, I happen to be running this command as part of PowerShell script. I may have to figure out how to run a CMD command from inside my PowerShell script if that is at all possible. I'm not sure. 🤔 If not, I need to figure out what exactly PowerShell is doing to my command when it reaches the '&' character.
tl;dr
You need a workaround:
cmd /c 'code --diff "R&D (cloud conflict 2-5-23).txt" "R&D.txt"'
Alternatively, using --%, the stop-parsing token:
code --diff "R&D (cloud conflict 2-5-23).txt" --% "R&D.txt"
Note: --% comes with fundamental limitations, notably the inability to reference PowerShell variables - see this answer.
Background information:
The root cause is that code is implemented as a batch file (code.cmd) and that cmd.exe, the interpreter that executes batch file inappropriately parses its list of arguments as if they had been submitted from INSIDE a cmd.exe session.
PowerShell, which - of necessity - has to rebuild the process command line behind the scenes on Windows after having performed argument parsing based on its rules, and - justifiably - places "R&D.txt" as verbatim R&D.txt on the process command line, given that the argument value contains no spaces.
The result is that cmd.exe interprets the unquoted R&D.txt argument on its command line as containing metacharacter &, which is its command-sequencing operator, causing the call to break.
Given that cmd.exe, the legacy Windows shell, is unlikely to receive fixes, the actively maintained PowerShell (Core) 7+ edition could as a courtesy compensate for cmd.exe's inappropriate behavior.
Doing so has been proposed in GitHub issue #15143, but, alas, it looks like these accommodations will not be implemented.

Using the --glob_ignores flag of SVN_Load_Dirs.PL

I am attempting to use the SVN_Load_Dirs.PL script file (https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/) to attempt to merge a platform drop.
However, I can't get the --glob_ignores flag to behave as I'd expect, and I know so little perl that I can't dig into the script to understand why. The format I am using is:
--glob_ignores=*.jazzignore
Where I want to ignore all .jazzignore files (although I am fine with anything with "jazzignore" in either the extension or name being ignored. I've looked for examples but can't find any actual usage of this flag anywhere. What I am looking for is a way to ignore all .jazzignore files and a few entire directories (like jazz5 for an example)
I assumed the flag would then be --glob_ignores="*.jazzignore *.jazz5" but that doesn't appear to be working.
It turns out that the script was failing silently because I was running it from a windows cmd (and therefore never getting to the flag option). Apparently there are some issues running it this way and it was designed to be run from a linux command line. After switching it works perfectly.

InstallShield Automation can't create object

I am working with Installshield 2014 and 2011. I'm using major upgrades and automated build scripts to handle the build. InstallShield is the stand alone build ver. for both.
Now everything worked fine with Installshield 2011 on windows 2003 servers. I could use the automation interface to open a project, change the product code (for the major upgrade) then save it right before building the installer.
The code for such is in a vbs file as such:
Dim oISM, oGUID
Set oGUID = CreateObject("InstallShield.GUID")
Set oISM = CreateObject("IswiAuto17.ISWiProject")
oISM.OpenProject strInstallShieldProjectFile
oISM.ProductCode = "{" & oGUID.CreateGUID( ) & "}"
oISM.SaveProject : oISM.CloseProject : set oISM = Nothing
Now we've upgraded to windows 2012 servers and InstallShield 2014. I've double checked and according to InstallShield the only change needed is the ver number (17 changes to 21).
But now nothing works. If I take the code out and put it in it's own vbs file for testing and run it, I get this:
ActiveX component can't create object: 'InstallShield.GUID'
Looking on google I see that's from running in 64 bit mode.... but I'm not. I'm running a cmd prompt in 32 bit mode.
http://helpnet.flexerasoftware.com/installshield18helplib/AutomationInterface64Bit.htm
I tried calling the script with:
%WINDIR%\SYSWOW64\cmd.exe /c cscript
as suggested here:
How do I run a VBScript in 32-bit mode on a 64-bit machine?
and other places. This did not work as I got the same error.
I tried removing that line as I'm sure I can create a guid another way, and reran it.
Then I got this when it tries to create the project:
Unknown runtime error: 'CreateObject'
Once again google came up and I checked:
https://community.flexerasoftware.com/showthread.php?189788-Automation-error
and couple others. I tried ensuring the dll was registered using the regsvr32 and it said it was successful. But after rerunning, it gave the same error.
I tried directly coping the command from the InstallShield documentation to ensure no spelling mistakes but again same error.
I even tried switching the case of the "sw" as mentioned here:
Installshield Automation is failing while running vbscript with error unable to create object
Again though, same error.
I also tried switching to powershell as powershell is much easier to debug and read.
The powershell code is simple and is as follows:
$oIsm = new-object -comobject IswiAuto21.ISWiProject
$oISM.OpenProject("$file")
$oISM.ProductCode = "{" + [guid]::NewGuid() + "}"
$oISM.SaveProject(); $oISM.CloseProject(); $oISM = $null
But this also does not work despite these saying it should:
https://community.flexerasoftware.com/showthread.php?190769-Automation-using-Powershell
http://blogs.flexerasoftware.com/installtalk/2011/01/getting-started-with-installshield-automation-and-powershell.html
When I use the 32 bit powershell I get this error:
new-object : Creating an instance of the COM component with CLSID {78D393F9-76E3-438C-9CAB-6664EF5FE1F2} from the IClassFactory failed due to the following error:
800a801d Exception from HRESULT: 0x800A801D.
If I run solely the vbs without a cmd prompt I also see the error of 800A801D in a pop up box.
How can I fix this? I'd like to use powershell but a vbs fix would help as well at this point. I have tried everything I can think of and google says I'm doing it correctly (32 bit powershell/cmd, registering the dll, creating the object, etc).
Did you install the automation interface? Typically it's an optional feature that's set to absent when you install InstallShield.
Typically the HRESULT should tell you what's wrong, or be so generic that it doesn't help. In this case, it's a bit of an enigma as I haven't found its definition anywhere. The leading 0x800A... indicates FACILITY_CONTROL and the trailing ...801d happens to match the tail of TYPE_E_LIBNOTREGISTERED (0x8002801D), but I don't know whether that's meaningful. Unfortunately FACILITY_CONTROL is defined by the control that issues the error, and that's not clear here.
Let's try to figure out what's wrong. My bet is on COM registration. If you want, you can skip to a likely fix by running regsvr32 C:\...\System\ISWiAutomation21.dll.
So let's follow what CreateObject("IswiAuto21.ISWiProject") will do. First it has to look up the ProgID:
C:\>reg query HKCR\ISWiAuto21.ISWiProject\Clsid
HKEY_CLASSES_ROOT\ISWiAuto21.ISWiProject\Clsid
(Default) REG_SZ {78D393F9-76E3-438C-9CAB-6664EF5FE1F2}
Then it has to look up the CLSID, and in this case, its InprocServer32 key:
C:\>reg query HKCR\Clsid\{78D393F9-76E3-438C-9CAB-6664EF5FE1F2}\InprocServer32
HKEY_CLASSES_ROOT\Clsid\{78D393F9-76E3-438C-9CAB-6664EF5FE1F2}\InprocServer32
(Default) REG_SZ C:\...\ISWiAutomation21.dll
ThreadingModel REG_SZ Apartment
If either of these are missing, it will be unable to find the COM server. In addition, the TypeLib subkey and the Type Library it references are both important:
C:\>reg query HKCR\Clsid\{78D393F9-76E3-438C-9CAB-6664EF5FE1F2}\Typelib
HKEY_CLASSES_ROOT\Clsid\{78D393F9-76E3-438C-9CAB-6664EF5FE1F2}\Typelib
(Default) REG_SZ {92278CC1-987E-4A01-940C-47DCADF27496}
C:\>reg query HKCR\Typelib\{92278CC1-987E-4A01-940C-47DCADF27496}\1.1\0\win32
HKEY_CLASSES_ROOT\Typelib\{92278CC1-987E-4A01-940C-47DCADF27496}\1.1\0\win32
(Default) REG_SZ C:\...\ISWiAutomation21.dll
If any of this information is missing, it will have to be repaired. The COM Server itself may need to probe several additional IDs at this point, so there's a chance that even if this subset is okay, there are others that are missing or corrupted. Self-registering the COM server should fix this. So should running the installation's repair.
Note that all of these queries were done using the 32-bit command C:\Windows\SysWow64\reg.exe, or you can peruse the registry visually with C:\Windows\SysWow64\regedit.exe.

Execute batch file using dos()

I got a problem when executing batch file commands through matlab. This batch file includes commands to run simulations in Adams. When I execute the batch file directly from DOS window, it works well. But if I use matlab to execute it (using command dos()), it gives error saying 'cannot check out the license for Adams'.
This confuses me: if the license is incorrect, it should not work no matter I execute the batch file directly in DOS or ask MATLAB to execute it. I also tried to execute other DOS commands through matlab using dos() and it worked well.
Does anyone know what the problem may be?
Such issues are commonly caused by some environment variables being changed or cleared by MATLAB. I have very similar experience on Linux and Mac OS X, where this causes havoc when using system or unix.
In Unix-like systems, MATLAB is started from a shell script where all of this happens. So you can either incorporate missing variables there or in the .matlab7rc.sh in your home directory (the latter is preserved when you upgrade MATLAB and it is much easier to use). I won't go into all the Unix details here.
An alternative workaround is to explicitly set those variables when you issue a system command (e.g. system('export variable=value ; ...')). It is quite a bit of work, but you can then use that MATLAB code on different computers with ease.
On Windows, I'm not completely sure about the exact location of the corresponding files (and whether MATLAB starts in quite a similar way as on Unix). But if they exist, you can probably find it in the MATLAB documentation.
Anyhow, the alternative fix should work here as well.
First you need to diagnose which system variables you need (likely a PATH or anything that has a name related to Adams).
To do so in Windows, run set from the Windows command prompt (cmd.exe) and from within MATLAB. Whatever differs in the output is a possible suspect for your problem.
To inspect just a single variable, you can use the command echo %variablename%.
I will assume that you have found that the suspect environment variable is missing and should be set to value.
The workaround fix is then to run your command in MATLAB as system('set suspect=value & ...') where you replace ... with your original command.

perl.exe remap error under cygwin

My Cygwin environment (Windows 7 O/S) has developed a strange problem. A couple of days ago I was running a perl script fine, but today I'm getting
0 [main] perl 5056 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\perl
5\5.10\i686-cygwin\auto\Socket\Socket.dll to same address as parent: 0x8F0000 != 0x960000
Stack trace:
Frame Function Args
0088B508 6102749B (0088B508, 00000000, 00000000, 00000000)
0088B7F8 6102749B (61177B80, 00008000, 00000000, 61179977)
0088C828 61004AFB (611A136C, 6123E0FC, 008F0000, 00960000)
End of stack trace
I tried running rebase, as advised here but the problem persists. Any answers appreciated, as I have a demo tomorrow for which this script is needed. Wasn't expecting a problem like this!
This is a semi-informed answer, as I have had similar difficulty and eventually flailed around until the problem went away.
rebaseall with no arguments will rebase all of the dll files that were installed from cygwin packages. However you will often have many other dlls from other programs you have built and installed, including from installed Perl modules with XS code, and you will need to tell rebaseall about these modules somehow.
There may be an easier way to do this, and I hope I haven't forgotten any steps, but I think I had some success doing something like this:
Get a list of all the dll's in your system that run under cygwin. Maybe something like find /bin /lib /usr /home -name \*.dll > /tmp/file1
exit all cygwin processes, open as ash or dash shell from a Windows command prompt, and run /bin/rebaseall -v > /tmp/file2. The -v switch sets a Verbose flag in rebase that lists all the files that get rebased with the default setting.
Use /tmp/file1 and /tmp/file2 to create a new file, say /tmp/file3 with the complete list of files you will want to rebase. From what I remember it is important for the system dlls (all the files in /tmp/file2) to be listed first,
Now run rebaseall -v -T /tmp/file3 (in ash, after closing all cygwin procs, etc.). Pay attention to the output. If there are error messages about rebasing some particular dll, remove that entry from /tmp/file3 and try again.
This may not solve your problem, but maybe it will get you most of the way there. If you do eventually figure it out, I hope you will come back and fill in some of the holes in this solution.
I think it is useful to point out that for most people running into this a simple "rebaseall" without any arguments seems to resolve this issue. I'll post a link to a very useful blog post from My Life, Starting up (I have no relation to that blog):
http://www.mylifestartingup.com/2009/04/fatal-error-unable-to-remap-to-same.html
The action list, (copied directly from the blog) is:
Let me tell you what you can do if you don't care what's actually happening.
1) Close out of Cygwin (and all cygwin processes).
2) Open a Windows command prompt (start -> run - > type 'cmd' or on vista : start -> type 'cmd' in the start search window)
3) Go to your cygwin bin directory. For me it is c:\cygwin\bin.
4) Type ash
5) Type '/usr/bin/rebaseall'
6) Resolve any errors (I had a warning that went unresolved and it still worked fine)
7) Reboot...and you should be good.
And if you DO care what's actually happening, read the blog entry, in addition to the answer by mob here on this same question.