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
Related
I have a batch file that builds 2 install projects. They each have SQL Server 2012 as a prerequisite but with different command lines (one is silent, one not for example). Anyway, I would like the projects to be built automatically without having to run one, manually change the prerequisite command line, and then run the other. As it is, there only seems to be one copy of the prerequisite settings - any ideas as to how to accomplish this? Thanks!
I can see two options. Neither are perfect, but I think I prefer the first.
Create two copies of the .prq, one with each setting. The quirk here is they either have to have different names (possibly good, possibly bad), or they have to be in different paths that you control, for example, with the -prqpath parameter to iscmdbld. While the different names makes it easier for you to verify which prerequisite each build has, it may be more confusing for someone installing the prerequisite.
Install the prerequisite as a feature prerequisite, allowing you to use [PropertyReference] notation in the prerequisite's command line. Then set the referenced properties up differently in the builds that consume them, perhaps with the -z parameter to iscmdbld.
Note that if the prerequisite you are modifying has a download URL for an updated prerequisite, your changes will be lost when it downloads InstallShield's version, so in a situation like this you are encouraged to modify it to point to one that you host.
I saw that there is a lua plugin for eclipse and there is a docpage on the awesome main page api_doc and all the .lua files in /usr/share/awesome/lib.
So I thought it must be possible to create a Library or Execution Environment so that one has tabcompletion and docview.
So I tried making my own Execution Environment:
wrote the standard .rockspec file
downloaded the documentation made an ofline version of it and put it in docs/ folder
ziped the files and folders in /usr/share/awesome/lib
ziped all up
tried it out ... and it failed.
When I try to view a documentaion for a .lua file I get "Note: This element has no attached documentation."
Questions: Am I totaly wrong in my doing (because I have the feeling I am)? Is there any way to edit the rc.lua with tabcompletion and docview?
Koneki will probably take a while to setup, but it's definitly worth it. Going for the".doclua"(by using version 1.2) would certainly make it, but I doubt that using a script to generate the information you need, would work out on the long run.
Most likely, you'll probably pass a bit of time to define what kind of object you're dealing with every time you come across one. The right to do, would be to actually take the time to see if the object/module/inner type inherit from an another object, so can actually have more completion feature as you keep using autocomplete to go from one object to another by pressing "dot"+ctrl_space.
In an ideal world, one person could probably make it right and share to other, so they can enjoy a full featured autocomplete editor.
Found solution for eclipse.
First off the idea of setting up an Execution environment was the wrong one.
So the whole thing about downloading the doc although.
For more information on that visit eclipse Wiki for LUA Development Tool.
The right thing to do is to add a source folder which contains the /usr/share/awesome/lib directory.
The bad news is that my comment from above was totally right, which means one has to configure each .lib file in /usr/share/awesome/lib to meet the requirements of the Documentation Language described here.
Than editing the rc.lua (which one can add to the project in eclipse) works with tabcompletion and doc view.
Since the Documentation Language used in the lib files is similar to the one used by "LUA Development Tool" one has not to change many things. Maybe there are even scripts for that.
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.
I've made a small script in my machine, and an alias in .bashrc that calls it. It's a bash script with 3 lines, but it can grow.
Now, some people in my team found it useful, and want to use it.
Instead of saying "copy this alias, do this, do that, install that lib" I was thinking about creating a simple package to be a little more professional. Fact is, I've never done something like this before. And the problem to me is not creating a package, is trying to decide what usually do you put in a package.
Suppose I want to take my script, and create myapplication. I want to create a .deb file that my team would install and:
Have a /usr/bin/myapplication or /usr/sbin/myapplication (what's the difference between them?), so they would just call myapplication at their terminal and it would work;
Have a man page; (Where are usually located man pages in a debian system?);
Have a possibility to read a .myapplicationrc in home folder with some configurations;
Have an entry for shortcuts in a gnome installation (is it possible to have an universal shortcut "format" that's is available to KDE and Gnome as well?);
Install dependencies.
I'm new to all that stuff. I usually code simple scripts and create an alias in my bashrc. I've never done a package before. Which guides do you know of that can help me accomplish what I thinking of above?
Here is a place to start, though I welcome a more succinct answer.
I couldn't find a complete guide. I think the best thing to do is download a package that does exactly what I'm thinking of and do some reading, like taskwarrior.
I am trying to write a bash script to do a task, I have done pretty well so far, and have it working to an extent, but I want to set it up so it's distributable to other people, and will be opening it up as open source, so I want to start doing things the "conventional" way. Unfortunately I'm not all that sure what the conventional way is.
Ideally I want a link to an in depth online resource that discusses this and surrounding topics in depth, but I'm having difficulty finding keywords that will locate this on google.
At the start of my script I set a bunch of global variables that store the names of the dirs that it will be accessing, this means that I can modify the dir's quickly, but this is programming shortcuts, not user shortcuts, I can't tell the users that they have to fiddle with this stuff. Also, I need for individual users' settings not to get wiped out on every upgrade.
Questions:
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate? tweek the reference in the source of the dev version?
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be? the user will need to access some of this data, but it's mostly for internal use. I personally work in cygwin, and I like to keep this data on separate drive, so the path is wierd, I suspect many users could find this. for a default however I'm thinking ~/gpsdata/ -- would this be normal, or should I hard code a system that ask the user at first run where to put it, and stores this in the settings folder? whatever happens I'm going ot have to store the directory reference in a file in the settings folder.
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?? though there will always be an option to add a file or folder to the command line to use that as well (it processed files all locations listed, including the "inbox")
Where should the script its self go? it's already smart enough that it can create all of it's ancillary/settings files (once I figure out the "correct" directory) if run with "./foo --setup" I could shove it in /usr/bin/ or /bin or ~/.foo/bin (and add that to the path) what's normal?
I need to store login details for a web service that it will connect to (using curl -u if it matters) plan on including a setting whereby it asks for a username and password every execution, but it currently stores it plane text in a file in ~/.foo/ -- I know, this is not good. The webservice (osm.org) does support oauth, but I have no idea how to get curl to use it -- getting curl to speak to the service in the first place was a hack. Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Sorry for the list of questions, I believe they are closely related enough for a single post. This is all stuff that stabbing at, but would like clarification/confirmation over.
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate?
Have a default of ~/.foo, and an option (for example --config-directory) that you can use to override the default while developing.
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be?
If your script is running under a normal user account, this will have to be somewhere in the user's home directory; elsewhere, you'll have no write permissions. Perhaps ~/.foo/tracklog or something? Again, add a command line option, and also an option in the configuration file, to override this.
I'm not a fan of your ~/gpsdata default; I don't want my home directory cluttered with all sorts of directories that programs created without my consent. You see this happen on Windows a lot, and it's really annoying. (Saved games in My Documents? Get out of here!)
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?
As stated above, I'd prefer ~/.foo/inbox. Also with command-line option and configuration file option to change this.
But do you really need an inbox? If the user needs to run the script manually over some files, it might be better just to accept those file names on the command line. They could just be processed wherever, without having to move them to a "magic" location.
Where should the script its self go?
This is usually up to the packaging system of the particular OS you're running on. When installing from source, /usr/local/bin is a sensible default that won't interfere with package managers.
Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Yes, there is. But it's better not to, because it creates a false sense of security. Without a master password or something, secure storage is not possible! Pidgin, for example, explicitly stores passwords in plain text, so that users won't make any false assumptions about their passwords being stored "securely". So it's best just to store them in plain text, complain if the file is world-readable, and add a clear note to the manual to warn the user what's going on.
Bottom line: don't try to reinvent the wheel. There have been thousands of scripts and programs that faced the same issues; most of them ended up adopting the same conventions, and for good reasons. Look at what they do, and mimic them instead of reinventing the wheel.
You can start with the Filesystem Hierarchy Standard. I'm not sure how well followed it is, but it does provide some guidance. In general, I try to use the following:
$HOME/.foo/ is used for user-specific settings - it is hidden
$PREFIX/etc/foo/ is for system-wide configuration
$PREFIX/foo/bin/ is for system-wide binaries
sym-links from $PREFIX/foo/bin are added to $PREFIX/bin/ for ease of use
$PREFIX/foo/var/ is where variable data would live - this is where your input spools and log files would live
$PREFIX should default to /opt/foo even though almost everyone seems to plop stuff in /usr/local by default (thanks GNU!). If someone wants to install the package in their home directory, then substitute $HOME for $PREFIX. At least that is my take on how this should all work.