I am on a project where they use launch files. Until now there was one developer, but it is the intention that we are going to work with more developers.
At the moment I see in the launch file:
<stringAttribute key="org.eclipse.jdt.launching.WORKING_DIRECTORY" value="/home/john/dev/projects/..."/>
But that is a hardwired user. Is there a way to substitute the home directory of the current user for '/home/john'?
Many values in a launch configuration can contain 'variables' to set the value.
For the working directory you could use ${system_property:user.home} to get the user.home system property:
<stringAttribute key="org.eclipse.jdt.launching.WORKING_DIRECTORY"
value="${system_property:user.home}/...."/>
The Run Configuration for the launch has a 'Variables' button next to the working directory setting on the 'Arguments' tab which will show you the main variables you can use.
Related
I'm hosting an AppImage file on github releases
https://github.com/Gilad-Kutiel-App/jumpfm/releases.
The file does not have an execution permission when downloaded and it is needed to set it manually.
Is there anything I can do about it ?
Thank you,
Gilad
Before you can run an AppImage (or really any executable for that matter), you need to make it executable. This is a Linux security feature. There are three main ways to make an AppImage executable:
1. With the GUI
Open your file manager and browse to the location of the AppImage
Right-click on the AppImage and click the ‘Properties’ entry
Switch to the Permissions tab and
Click the ‘Allow executing file as program’ checkbox if you are using a Nautilus-based file manager (Files, Nemo, Caja), or click the ‘Is executable’ checkbox if you are using Dolphin, or change the ‘Execute’ drop down list to ‘Anyone’ if you are using PCManFM
Close the dialog
Double-click on the AppImage file to run
2. On the command line
chmod a+x Some.Appimage
3. Automatically with the optional appimaged daemon
If you would like to have all AppImages be executable automatically, you can install the optional appimaged daemon. It will automatically add downloaded AppImages to the menu and make them executable for you. It can be downloaded from https://github.com/AppImage/AppImageKit/releases or installed from your distribution.
On your download page, you can link to the image and/or to http://discourse.appimage.org/t/how-to-make-an-appimage-executable/80
Note: Please DO NOT put an AppImage into another archive like a .zip or .tar.gz. While it may be tempting to avoid users having to set permission, this breaks desktop integration with the optional `appimaged daemon, among other things. Besides, the beauty of the AppImage format is that you never need to unpack anything
I have taken over a click once project from a prior developer. How do I find out where his click once update folder was? The properties of the deployed apps only show where the appdata folder is. I need to know the original update location on the click once server so I can redeploy there, but the location that is stored in the project properties is wrong (as are all of the application configuration values) so I must have an old set of source code.
It's a bit of a shot in the dark, but if you have access to a machine that already has the application installed on it and if the application was configured to check for updates before running, you may be able to see the updates location within the app's CDF-MS file installed on that PC. The CDF-MS file is a binary file but you should be able to use STRINGS.exe or visually inspect it to find the beforeApplicationStartup or deploymentProvider value inside the file.
The file is likely located in C:\Users\USERNAME\AppData\Local\Apps\2.0\RANDOM.STR\RANDOM.STR\manifests
In my code I fail at
if (!File.Exists(_configurationFileName)) {...}
In the immediate window I made a call to Directory.GetCurrentDirectory() and it pointed me to the "work" folder rather than the "code" folder which I would have expected.
Directory.GetCurrentDirectory()
"C:\\SfDevCluster\\Data\\_App\\_Node_0\\My.Application.Type_App2\\work"
So my configuration file which is sitting right next to the executable is of course not being found.
Now I wonder what the solution is.
Since I also want to keep running the console application I don't want to implement any "if service fabric hosting, then change current directory, ..." workaround.
Any recommendations? What about my .exe.config files (if I had any, how would they be found)?
What's the reason for Service Fabric settings the current directory to "work"? Is this some kind of security mechanism?
This is how i just did it change the service manifest to point at the code
<EntryPoint>
<ExeHost>
<Program>configui.exe</Program>
<WorkingFolder>CodePackage</WorkingFolder>
</ExeHost>
</EntryPoint>
You could do some simple reflection and get the folder the executing assembly is in, then reference that file in that location. I did this successfully for an ancillary file I needed that is deployed to the same folder as my executable.
string exePath = System.Reflection.Assembly.GetExecutingAssembly().Location;
string filePath = Path.Combine(Path.GetDirectoryName(exePath), "myfilename.txt");
You can select build action as 'content' and select 'copy if newer' in the properties so that it gets copied to the output folder.
Setting "Application Debug Mode" to "Keep Application" resolved a similar issue I was having where my files were not getting copied to the final deploy area on my local service fabric.
It had been set to "Refresh Application" which is in preview as I type this. But that mode wasn't copying my wwwroot folder over, so my view engine (Nancy in this case) was not finding my views.
Right click your service fabric project > properties > Application > Application Debug Mode > Keep Application
I'm testing out Install4J 5.1.5 and am running into a little issue. My original jar file I would like to distribute has full permissions-- anyone can open it (with something like 7zip)-- and modify/delete any entries in that jar. However this same jar-- when installed by install4j-- the permissions become essentially read-only. I can't modify/delete anything in the jar after installation-- gives me permissions issue.
The reason why I want to modify/delete is that there are a few properties files in the jar that get defined by the user during installation so I want to modify / delete whats already in there with the user's new files...
The only thing I can think of is that I set the default unix file and directory modes to 777. But this doesn't seem to work. Any ideas?
The installer has a helper process that runs with elevated permissions. This helper process is started by the "Request privileges" action that is by default added to the "Startup" node of the installer.
All actions whose "Action elevation type" property is set to "Elevate to maximum available privileges" are executed in the helper process.
If you want to modify the file in your application (i.e. not in the installer), you can use a "Add Windows file rights" action to make the file writable for everybody.
While looking for a light-weight Scala development environment, I came upon an Scala edit mode for jEdit. I don't know how to put it to use, though. How does one put a new edit mode in jEdit?
All of this can be found inside jEdit's help, Using jEdit -> Writing Edit Modes -> Installing Edit Modes. But, if you are like me, and tried StackOverflow first, here's the short of it.
Place the mode file (in this case, scala.xml) inside the "modes" directory in jEdit home directory -- this can be found through the Utilities menu -- if you want it for all users, or the "modes" directory in user's jEdit's settings diretory -- which can also be found through the Utilities menu -- if the new mode is to be used by only one user.
After that, edit a file "catalog" inside that same directory. It contains a list of supported modes. If you are working on the settings directory, there won't be any examples to use as a reference, but the catalog inside the home directory has plenty.
A settings directory catalog would look like this, for the referenced mode:
<?xml version="1.0"?>
<!DOCTYPE MODES SYSTEM "catalog.dtd">
<MODES>
<!-- Add lines like the following, one for each edit mode you add: -->
<!-- <MODE NAME="foo" FILE="foo.xml" FILE_NAME_GLOB="*.foo" /> -->
<MODE NAME="scala" FILE="scala.xml"
FILE_NAME_GLOB="*.scala" />
</MODES>
May be this JEdit Setup with Scala can help you ?
It refers to a JEdit fully configured to run Scala projects.
http://liftweb.net/images/9/91/Screenshot-jedit.png
You can copy the scala.xml file to $JEDIT_HOME/modes