I have various files of extensions .cpp stored on the server. When user clicks on the compile button, I should run gcc command passing the absolute path of the file to gcc compiler and then show the user the output of the file.
How can i do that???
Kernel.system may the command that you are looking for: it calls a system process. For example:
if (system("gcc ..."))
#output_to_show = %x['./compiled']
end
Assuming that your server is in Linux/UNIX, it would be good to separate the compile&execute process from the website server in order to reduce the security risks (by creating a new user just for this purpose). Or can you trust the content of the cpp-Files?
Related
Im doing a little research into installers, and right now at my company we are having some issues deploying from jenkins using click once. We have a test certificate(these programs are all internal) and for some reason are having some issues with the certifcate being incompatiable with certain msbuilds/.net frameworks. So im looking into alternatives.
But in that i want to keep the same architecture. How it works right now is someone clicks on a button in our task bar, clicks on the application they want, and then click once installs the updates(or installs) without further user input and starts the application. Ive heard a lot of good things about NSIS.
So far ive only seen generic application installers like you expect when you download anything from the internet. Could I do something like i described above using NSIS?
A very basic no interaction installer might look like this:
Name foo
OutFile foo_setup.exe
AutoCloseWindow true
RequestExecutionLevel user
InstallDir "$LocalAppData\Programs\MyApp"
Page InstFiles
Section
SetOutPath "$InstDir"
WriteUninstaller "$InstDir\uninst.exe"
; TODO: Add registry entry for Add/Remove Programs
File "MyApp.exe"
File "Data.xml" ; Support files etc
Exec '"$InstDir\MyApp.exe" -firstrun "c:\some path\file.ext"'
SectionEnd
Section Uninstall
Delete "$InstDir\MyApp.exe"
Delete "$InstDir\Data.xml"
Delete "$InstDir\uninst.exe"
RMDir "$InstDir"
SectionEnd
If you want to install for all users in %ProgramFiles% you can run into issues with Exec because the app can end up running as the wrong user if a non-administrator used some other account in the UAC dialog.
Could you tell me please. I wrote an application that uses 'Settings.ini' to save settings. The application is installed using InnoSetup. If there are several user accounts and the application is installed in one of them, so, if I try to run the application from another account I get error "Unable to write to....". That is, if run from another account, the application has no rights to write to the settings file. I don't know what happens in Windows XP, but that's the way application behaves in Windows 7.
So could you tell me please, is there something I should define in my application to make it work for multiple users or it should be changed during the installation, somewhere in InnoSetup parameters?
Thank you.
You should - install the very program into Program Files or some other common folder - folder that any user have rights to read and run, but not to write or delete. USually installers would allow to override the folder, but the rule remains: every user should have non-destructive rights (read and execute) and none - destructive (delete, overwrite)
That means your installer should request Admin rights and UAC Elevation - ask InnoSetup forum or documentation how to do it. That may deal with including manifests resources into installer. It is normal when a regular user runs the installer and installer then asks for another username and password with admin rights.
The settings and other user-unique data should be saved into special per-user data folders. Usually that is AppLocal folder under user profile. However it is task for your application rather than the installer. Installer may create global settings templates, that the application would just copy into user-local settings on the 1st run under given user, or would override by user-local settings if cascading settings storage is implemented.
http://msdn.microsoft.com/en-us/library/windows/apps/hh465094.aspx
http://blogs.msdn.com/b/patricka/archive/2010/03/18/where-should-i-store-my-data-and-configuration-files-if-i-target-multiple-os-versions.aspx
Run command prompt, issue set command - and u would see all needed paths as environment variables wit hnames like AppPath, LocalAppPath and UserProfile
http://greatis.com/delphicb/tips/lib/systemifo-envstrings.html
http://www.delphidabbler.com/articles?article=6
I am working on a monitoring app and I have to pass in at startup some initial configuration which consists of a couple of lists of IP addresses. What's the OTP way to pass this data to the application - through the .app file or is there any other general accepted way?
Use an Erlang configuration file:
A configuration file contains values for configuration parameters for
the applications in the system. The erl command line argument -config
Name tells the system to use data in the system configuration file
Name.config.
Configuration parameter values in the configuration file will override
the values in the application resource files (see app(4)). The values
in the configuration file can be overridden by command line flags (see
erl(1)).
The value of a configuration parameter is retrieved by calling
application:get_env/1,2.
If you need to override them at runtime, you can use application:set_env/3, but with care.
you can handle configuration in several ways.
here a link to another stackoverflow topic
IMHO i suggest .app file, or you can use a configuration file (here another link to stackoverflow topic)
I would create a name gen_server process that has a list of ip addresses as it's state. In the init of the server a predefined list would be read from a file using file:consult and used as the initial state of the server. To get the list of ip addresses from this named gen_server, a handle_call(get_ip, _From, State) needs to be implemented.
This way you prevent shared global state, which gives you great Erlang karma, and have a better starting point for added functionality like runtime ip address changes.
Use a file in which you have your data as erlang terms. However you need to protect the file. Reading from the file at start up use: file:consult/1. If modification of the file will occur by the user or system administrator, use the following functions to protect or refuse access to the file:
-include_lib("kernel/include/file.hrl").
protect_file(File)->
{_,File_info} = file:read_file_info(File),
file:write_file_info(File,File_info#file_info{access = read,mode = 33060}).
unprotect_file(File)->
{_,File_info} = file:read_file_info(File),
file:write_file_info(File,File_info#file_info{access = read_write,mode = 33206}).
Use function protect_file/1 to make the file read-only. If you need to make the file writable then modify using unprotect_file/1. A file with erlang terms is easier because you do not need parsing.You could also write you configurations as JSON objects or XML data into a file. In summary, using a file for all you configs will be better managed by your application and those who interact with it. An example is the ejabberd.cfg file, the config file for ejabberd server. Its easiest with a file with erlang terms because you can comment here and there for the system administrator to see other available options about a certain configuration.
I need to update my application from a central server.
The application checks always if it is a correct version, against the server installation.
So when it is not, I need it to update itself.
So how can I copy the EXE if it is running? What solution do I have?
I rename the current running exe to MyTempExe.exe, copy the new exe to the correct location (request elevated privileges if necessary) and then run a separate app to restart the main app. On start up I check for MyTempExe.exe delete it if it's there.
The reason I use a separate app for the restart is I don't have a set time frame for the app to close down and need to wait for it to finish whatever it's doing, on shutdown it writes information to disk about its current state that the updated app will use to resume where the old one left off.
I don't know if it's the best solution but it's the one I use.
As you can see by all the answers there is no set way to do this, so I thought I would add the way we have successfully done this.
We never run an application directly from the network.
We run the application from the local machine and have it copy from the network on startup.
We do this using an application launcher. It downloads an XML file that contains CRC and Version Resource Values for the application files. The XML File is created during the deployment process, in a FinalBuilder Script.
The application then compares the XML File to local content, and copies down needed files. Finally we then launch the application in question. This has worked well for deploying an application that serves around 300 local users. Recently we switch from a file copy to an HTTP download as we found problems with remote user disconnecting drives.
We still still build installations (With Innosetup) to get the basic required files deployed.
Package your app with an installer such as Inno. Download and execute the installer. Have the installer search for and kill your app, or instruct the user to close it. The setup will replace your .exe, and if the app can't be killed or the user is non-cooperative, it'll issue a re-start notice.
Download new EXE to TEMP
Create Batch from EXE, content:
taskkill /PID %process id of running EXE%
copy %new EXE% %running EXE%
%EXE%
all values in %...% are placeholders
execute batch from the running EXE
delete batch
I use TMS TWebUpdate myself, for software updates. The advantage is that there a bunch of extra actions you can put into the script, if you need anything other than plain EXE updates.
I have two components at work the application executable itself and a web-service (SOAP) which provides version details and file downloads.
The application calls a method on the SOAP service to ask for the number of files in the project (project is identified by using the application.exename usually).
The soap service gets its info from an INI file, which has entries like:
[ProjectName]
NumberOfFiles=2
File1=myapp.exe;1.0.0.1
File2=mydll.dll;1.0.0.2
You just update this file at the same time as uploading your new files.
The process of updating the application this:
Get number of files available on the web service
For each file, the application asks for the name and version number from the SOAP server.
The application compares this information to its own version info and decides if the file needs updating, building a local list of files that need updating.
For each file that needs updating the application downloads the file to filename.ext.new
Finally, the application renames all filename.ext to filename.ext.old and renames filename.ext.new to filename.ext and then restarts itself. (No real need for an external app to restart your own program).
Note 1, that you may have to ask for elevation to replace files, depending on where you install your files.
Note 2: be kind to your users, think carefully before you force updates on users.
Note 3: You cannot delete a running exe, but you can rename it and then restart the new version.
Edit===
For some reference data files which cannot contain version information resources, you can have entires like File99=MyDataFile;1.1.2011 the 3 elements to the version number indicates to the client that it should check against the file date/stamp.
You could have a separate update executable whose task is to check the server version, download an updated executable if necessary, and then run the local executable.
Or you could have one executable running in two different modes: 1. on startup, check for an update, if there is one, download the executable to a download directory, run it and quit.
2. The new executable would check if it's running from the installation directory, if not, it would copy itself there, overwriting the old version, start the copy from there, and quit.
My way is the other way round: If a new version is online, promt the user to update. If he want's to (or is forced to...) I end the app and start a new exe (updater). this updater loads the update and replaces the old exe (not running). then it starts the new exe. ready. (You can of course replace other files too.) BUT: Using an Installer like InnoSetup gives you more possibilities and doesn't mix up with the regular uninstaller, so it is really better...
You can do this without running another application. Push the updates to the client from the server while running, storing in a temporary directory on the client. When you want to upgrade move all your running files to another temporary directory, move the new files into the original application directory, and just restart the application using the standard executable name on shutdown.
I upgrade client applications running on unattended machines automatically this way.
When my program successfully installs via Inno Setup, how do I run a URL in the background? I want to just load a tracking pixel (or a postback) which says that my program was installed.
I'm aware than in the [Run] section, I can run a .url file with the flag "runhidden", but as far as I know that won't do what I need it to. Am I wrong about that, or are there better option?
Thank you.
There is no TCP/IP related Support Functions, defined by default.
You could build this functionality into a DLL and call it from you Install Script.
This is done installation's where Activation is required to make the program work.
However, I would just launch a browser window using the [Run] section that contains "Getting Started" information. You can then track hits to that page.