InstallScript: ChangeDirectory() call fails only in SILENTMODE - installshield

I have the following test InstallScript InstallShield code, which executes correctly in the normal interactive mode, but crashes setup.exe /s (silent) mode on calls to ChangeDirectory that involve any sort of actual depth of directories.
//Note: "C:" ^ "temp" resolves to "C:\temp", but it never successfully
//executes when run silent mode. It works fine in interactive mode, however.
ChangeDirectory("C:" ^ "temp");
//No subsequent code gets executed at this point in silent mode
I'm running this on a Windows 2008 x64 Server in a command window with Administrator privileges. The c:\temp directory exists, and EVERYONE has been granted full control rights to it.
The exit code is -2147213312, which is 0x80042000 in the error guide corresponding to
The installation exited with the abort keyword because the end user
canceled the installation.
What could possibly be going on here? I've tried using the try/catch syntax to examine the error, but the catch block never executes in this case, seemingly asserting that there's no error but instead an abort called?

The Installscript Engine does a lot of stuff behind the scene. It keeps changing the working directory. Thus, it is not very reliable to use ChangeDirectory(). It is surely better to use FULL PATH to all executables and other files. LaunchAppAndWait() too has this trouble. So full path needs to be used without fail.
Further, the Installshield help for ChangeDirectory() clearly mentions the following:
When you are specifying a file in your script, always specify the full
path (using the appropriate InstallShield system variable, for
example, SRCDIR) rather than depend on the current folder having the
appropriate value. The script internally executes code that can change
the current folder, so its value may not be what you expect.
The thing is, results are not reliable. They may work or may not.

We get this errorcode when our recorded .iss file is missing an entry in the .iss response file.
See Creating the Response File for more Details.
Logging an installscript setup didn't give us much information, so we wrote some functions to write to a custom logfile which helped us a lot.

Related

Pure Data freezes when trying to record

Working with Pure Data, trying to record audio output from a patch I've made, and am 1) unable to create a file within pure data to write to and 2) attempting to use the writesf~ object causes the program to freeze after about two to three seconds. I suspect the two things are related- perhaps the program is attempting to write data somewhere, somehow, but it's going in the wrong place or some such and causing the program to freeze?
I've uninstalled the latest Pure Data release (0.51-1) and installed an earlier stable release (0.5-2) and even tried an alternative called "purr data (latest release)" all with the exact same result on my windows 10 acer laptop: no file created, and program freezes after a few seconds.
I'm testing with this patch:
I first click on the message that reads "open rec.wav" then the start then the stop, and if I take longer than three or so seconds to click on "stop" the program freezes, otherwise nothing at all happens.
I have performed system wide search for the audio file, including the folder that the patch is in, all to no avail.
Any trouble shooting hints will be carefully attempted.
Are you sure you have write-permissions on the target directory?
If your example you use rec.wav which has no explicit target directory (and is just using the "current", so it's hard to tell from outside what this directory would be).
#max-n's answer suggests to use /tmp/foo.wav which is an illegal directory on Windows. Due to a known bug, using an illegal (or otherwise non-writable) path will lock up Pd.
If your "current" directory happens to be your system root (aka C:\), you might well lack the permissions to write there.
You could check by starting the Pd from the cmdline and see whether the terminal spits out any weird errors:
⊞ Win+R
type cmd and hit Enter
in the opening terminal type the full path to your Pd-executable, e.g.:
C:\Program Files\Pd\bin\pd + Enter
(ideally leave out the extension (that is: use .../pd rather than .../pd.exe)
If the problem is indeed a permission problem, you can simply work around it by specifying the full path of the output file (and make sure that it is in a writable directory).
The easiest way to do this is by using a file-selector to choose the output file:
[bang(
|
[savepanel]
|
[open $1(
|
[writesf~]
There might be a reason why the helpfile uses a [delay 1000] to schedule a stop message in a predefined time.

Debugging non-responsive python/PyQt application in PyCharm

How do you go about debugging a non-responsive python/PyQt application in PyCharm?
I am an experienced programmer, but new to all thing python. I have been given a large application (36,000 lines), which works under Windows, to port to Linux.
Having made just a handful of changes for OS-specific stuff, when I run the application it comes up with its main window. But then after a few seconds it becomes dimmed, and when I close the window I am asked to confirm to end "the window is not responding".
(Aside: On a whim I decided to try running the app via sudo, and surprisingly it works fine. I have tried doing strace running as root versus non-root, but I'm fairly sure there is nothing obvious in the way of file accesses/permissions etc. that differs. This may be a clue, but just as likely to be a red-herring, e.g. if it's an "uninitialized variable".)
If I debug it inside PyCharm, at that point I expect to click the "Pause Program" button, so that I can get a trace back and begin to see where it is in the code, and start stepping or whatever. However, that button does nothing at this stage? Maybe it only "works" when on "a python instruction"?
If I force a core dump (from the keyboard) and examine with gdb, I can see that the stack frame shows it is way down inside libQtCore/libQtGui, in processEvents on a call to read.
So how do I begin to go about debugging why it is (presumably) busy doing something at this point, or at least not responding? Any tips would be welcome. I do hope this question will not fall foul of SO's "too general" policy, any tips to get someone going on debugging a "non-responsive" program would be welcome.
To answer my own question, since no responses seem to be forthcoming.
In this case, the problem turned out to lie in a file which is imported into other files, named pyperclip.py. That had code outside of any function, and in a path through the source executed under Linux but I think not under Windows, which included:
app = PyQt4.QtGui.QApplication([])
cb = PyQt4.QtGui.QApplication.clipboard()
Clearly some attempt to gain a clipboard object. For whatever reason, this appears to work when run as su, but when run as the logged on user it causes the whole application to "hang". Removing those two lines solved the unresponsiveness.
In terms of what I learnt from this for debugging unresponsive applications: you need to debug not from the entry point of the program, as I would have expected, but rather right from the start of each file, and actually step into each import line just in case it is executing some initial code. Horrible!

Python Terminal Calls Fail to Interact with Files

I am writing a program that handles some data on a server. Throughout the program, many files are made and sent as input into other programs. To do this, I usually make the command string, then run it like so:
cmd = "prog input_file1 input_file2 > outputfile"
os.system(cmd)
When I run the command, however, the programs being called report that they cannot open the files. If I run the python code on my local computer, it is fine. When I loaded it onto the server, it started to fail. I think this is related to issues with permissions, but am not sure how I can fix this. Many of the files, particularly the output files, are being created at run time. The input files have full permissions for all users. Any help or advice would be appreciated!
Cheers!
The python code you list is simple and correct, so the problem is likely not in the two lines of your example. Here are some related areas for you to check out.
Permissions
The user running the python script must have the appropriate permission (read, write, execute). I see from comments that you've already checked this.
What command are you running
If the command is literally typed into your source code like in the example, then you know what command is being run, but if you are generating any part of it (eg. the list of operands, the name of the output file, other parameters, etc), make sure there are no bugs in the portions of your code that generate the command. For example before the call to os.system(cmd) consider including a line like print("About to execute: " + cmd) so you can see exactly what will be run.
Directly invoke the command
If all the above looks good, try to execute the command directly at a terminal on your server. What output do you get then. It's possible that the problem is with the underlying command itself rather than your python code.

InstallShield Reponse File missing a response

I am trying to automate the install of a few setup files (.exe). I managed to get one working without any issue but am having difficulty with the second.
I created response files by using the following in command prompt:
MyProgram.exe -r
This generated a "setup.exe" file in C:\Windows as I would expect it to. Here is an example of what the file looks like in notepad:
[{PRODUCT_GUID}-DlgOrder]
Dlg0={PRODUCT_GUID}-SdWelcome-0
Count=5
Dlg1={PRODUCT_GUID}-SdLicense-0
Dlg2={PRODUCT_GUID}-SdAskDestPath-0
Dlg3={PRODUCT_GUID}-SdSelectFolder-0
Dlg4={PRODUCT_GUID}-SdStartCopy-0
[{PRODUCT_GUID}-SdWelcome-0]
Result=1
[{PRODUCT_GUID}-SdLicense-0]
Result=1
[{PRODUCT_GUID}-SdAskDestPath-0]
szDir=C:\Example\
Result=1
[{PRODUCT_GUID}-SdSelectFolder-0]
szFolder=Example\Folder
Result=1
[{PRODUCT_GUID}-SdStartCopy-0]
Result=1
I run the install with the setup.iss (response file) using the command:
program.exe /S /f1.\setup.iss
All response files seem to work except for one. The program opens a dialog asking me to select from a pair of radio buttons to select what language manual I want it to install. I want it to default to hit the "Next" button but there's obviously nothing recorded in the .iss file to do so.
What do I have to manually add to the .iss file in order to complete this prompt?
Why doesn't my recording put this in?
Additional information:
If I manually hit "Next" at this step, the program completes install as expected.
The program successfully installs when I install everything manually.
It sounds like this installation includes a custom dialog that doesn't properly handle either MODE SILENTMODE or RECORDMODE. For silent installations to work properly, it needs to call SilentWriteData and SilentReadData when appropriate.
If you are the author of this installation (whether original or inherited), you should handle this case. If you are not the author and are trying to install this installation silently, you should contact the vendor, or (as Glytzhkof suggests) ask on a more relevant site for workarounds.
I think the response file will only contain the actual answers that were input during the original response file creation session. Did this missing dialog show up during the original setup run? Reboot dialogs and rare to display dialogs are often missing from the response file.
It could also be that the missing dialog is a custom made dialog and not a built-in Installshield dialog. I suppose this could mean it doesn't behave in the standard way.
How complex is this setup? How many systems are you deploying to? To reliably deploy files like these it is common to use "setup capture" and repackage as MSI files - so called application repackaging.
Depending on how many setups you have, how important they are and how many machines they need to reliably work on it might be worth capturing them. This is a highly complex task at times, but yield more reliable deployment once done right. Personally I find the biggest benefit of repackaging is the availability of a reliable uninstall - provided you have cleaned up the capture properly. Otherwise you have to create response files for the uninstall too. Very clunky and error prone - even when done well.
You might want to take this discussion to serverfault.com - the system administrator equivalent to stackoverflow.com. You can also have a look here: http://unattended.sourceforge.net/installers.php

I've downloaded an .exe file but it closes quickly as it opens

I am trying to open a downloaded .exe file but it closes as soon as it opens. Is there any possible way so that I can open it for a longer duration to read the content.
It's probably a console application rather than a GUI application. Use the command prompt to run the .exe.
Do the following...
Hold down your Windows key on your keyboard and then tap "R".
This will bring up the Run dialog. Type in "cmd" (without the quotes). Hit enter.
(this will work in all Windows versions - browsing the start menu/screen differs in each version)
If you saved the file to c:\downloads and it's called myFile.exe, type
C:
cd C:\Downloads
myFile.exe
Some of the steps are a bit redundant - if you know what you're doing in the command prompt then skip as needed (but then you probably wouldn't be posting this question). This will work even if you saved the file to D:\downloads.
Another example - if you saved the file to D:\folderA\Folder with a space\ and the file is called "my file with a space.exe" then type
D:
cd "D:\folderA\Folder with a space"
"my file with a space.exe"
If there is an issue (eg it's a 64-bit executable and you're on 32-bit Windows) then you may get a better error message at the command line.
There are so many reasons why the executable does not run. Here are some ways to check what is going wrong:
Is it your .exe? Do you known the "normal" behavior?
When you download it manually, it the result the same?
Do you download the .exe manually or via your application?
Do you see any problem in your Windows Event Viewer?
Is it the same result if you try to download the .exe via different browsers (IE, FF, ...)?
More details are welcome!
The nuget.exe file is not a console GUI application but rather a console package. Once you've downloaded it, you'll want to place it in a folder outside your Downloads folder. For example, C:\NuGet\nuget.exe - then set it as a PATH variable so that it's executable from anywhere.

Resources