I am trying to edit my config file, which I am told is located at $EXIST_HOME/conf.xml. However, when I type $EXIST_HOME into my terminal nothing happens, and I have no idea where to look for the file in my file system. I am using OSX, and installed eXist using the standalone GUI, and was not asked where to install files at setup.
How can I get to the config file?
$EXIST_HOME is just used to represent wherever you installed eXist to. On many Linux/Unix based systems (including Mac OS X) it is recommended to set this environment variable in your profile to the location where you installed eXist. If you do not, when you try to start eXist it will try and self-determine this from the location of its binaries.
If you installed eXist from the .dmg file which is provided for Mac OS X users, then you can drag and drop eXist to wherever you wish, however typically this would be /Applications/eXist-db.
If you installed eXist from the .jar installer by running java -jar eXist-db-setup-2.2.jar or double-clicking the Jar file (if your computer is configured to execute Jar files), then the second screen of the installer prompts you for the location to install eXist to. The default location set for Mac OS X is /Applications/eXist-db.
So if you didn't change the defaults, your $EXIST_HOME would be /Applications/eXist-db.
On OS X, as adamretter correctly states, the default installation directory when using the Exist-DB installation disk image (.dmg) is /Applications/eXist-db. However, when you navigate to the /Applications/eXist-db folder and click on the exist-db icon, as if to open the directory for further browsing, all that happens is that the Exist-DB server starts. Less experienced Mac users might not realise that you have to right-click with the mouse on the Exist-DB icon in the Applications folder and choose 'Show Package Contents' from the menu in order to view the directories that sit beneath it.
The config.xml file can be found at:
/Applications/eXist-db.app/Contents/Resources/etc/config.xml
P.S. Don't forget to make a backup copy before you start editing :)
Related
I'm using Docker Desktop vrs 2.1.1.0 (edge channel) on Mac Os Mojave. I need to include a file from /usr/local folder, as shared file in Docker's preferences, but the /usr folder is not displayed while browsing the folders. The option to write the folder/file name manually is also not available. See the print screens.
Does anyone have a clue how to add those folders in preferences?
File sharing paths are not manually editable
Folders like /usr or /Volumes don't appear in folder browsing
Update
I need to share this actual folder: /usr/local/share/dotnet/sdk/NuGetFallbackFolde and not entirely the /usr/local as I wrote above. But as I'm not able to select at least the /usr folder, this is why I've mentioned only the /usr/local folder.
Update
I've downgraded progressively up to Docker Community Edition 2.0.0.3 2019-02-15. That seems to be the last version with the old user interface. With this version the folder browser dialog from file sharing displays all the folders and also manual editing of the file paths works.
On versions Docker Desktop Community 2.1.0.1 and Docker Desktop Community 2.1.0.2, which have the new UI, it doesn't work.
I have faced the same problem and could sort it out using the latest docker version.
You can edit ~/Library/Group\ Containers/group.com.docker/settings.json.
Then add whatever path you need, in my case was a synthetic link (created through synthetic.conf), this way by manual editing the file the UI does not auto resolve the link so it works well.
{
"filesharingDirectories" : [
"\/Users",
"\/Volumes",
"\/datadrive",
"\/private",
"\/tmp"
],
In the File Sharing tab of Docker's Preferences, click the Add Directory button (+) and browse to the root directory of your Mac drive. Now press Command+Shift+Dot to show hidden directories. This will make the usr directory visible.
You will now be able to browse to the /usr/local/share/dotnet/sdk/NuGetFallbackFolder directory.
I think you have to add application to the list of trusted apps. Take a look here:
http://www.owsiak.org/macos-mojave-and-accessing-timemachine-data/
Unless you add Full Disk access, applications are not able to browse certain areas of your volume.
Update
Unfortunately, it looks like giving access to whole drive is not a solution in this case.
It looks like Docker Desktop is not quite happy with sharing /usr/local directory.
Please help me interwebs.
I'm having trouble getting my xamarin app to work. I've done a reinstall of Mac OS X and installed Xamarin using the installer, which adds mono and all the rest of it.
Now when I open up terminal and type which mono i get
/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono
...which is what I expect.
But when I navigate to that place (again in terminal) there's nothing there.
From my root folder I go "cd System/Library/Frameworks " and then hit ls and I get a looooong list of installed frameworks but no Mono.framework.
If I go to Apple > About this Mac > System Report > Frameworks Mono IS listed. I can execute Mono commands on the command line. If I look in paths.d the specified path for mono is /Library/Frameworks/Mono.framework/Versions/Current/Commands/mono but I can't find that location so how is it even a thing?
My linux skills are not great, can anyone please help me understand what's going on here?
I think you are looking in the 'wrong' Library folder. There are a few different Library folders. There is one under the Disk Drive (root) directory, one under the User directory, one under the System directory. I think they are all hidden by default. So you need to set your folder/view options explicitly to show the Library folder since it might be hidden by default. The directory you are looking for is directly under you Disk Drive (root).
Using Advanced Installer, I have created and run a simple installer that contains a single .exe.
This .exe started as an executable jar (w/ splashscreen) and was built into a Windows .exe using Launch4j.
Once the application is installed (in C:\Program Files (x86)...), I can't execute it from the installation directory. However, if I copy the .exe to anywhere else, Desktop, or any other directories created by other installers, the .exe will start perfectly.
This appears to be a folder or application permissions issue. Comparing the permissions between this folder and the one created by Advanced Installer, the permissions and settings are identical.
The ONLY difference I see, between the installed .exe and the same .exe copied to another folder, is that the "Edit Permissions" button has an admin shield on it (one originally installed by AI).
Is there a setting in Advanced Installer that will allow my .exe to run once installed, or is this just trickery employed by AI to get you to pay for a more robust version? I am unable to make any changes in the OS that enable this file to run in the directory created by AI.
If the executable fails to run from Program Files but does works from another folder it most probably happens that your EXE needs write access to that folder. If you launch it with the option "Run as administrator" it should work. This is not caused by a limitation from Advanced Installer.
Starting with Vista onward you can embed a manifest file into an executable file, that specifies for the OS the execution level, so you can set the level to "RequireAdministrator", thus your will EXE will always behave as you launch it with the option "Run as administrator" when launched from a shortcut or double-clicked.
The cause of this error was that the target directory included an exclamation mark. "!".
I had switched to using InnoInstaller and it was working in an initial version, until I later switched the target dir to include the exclamation mark, and it was broken in the same way. (Removing it fixed.)
Have no idea why this was causing the problem, just an fyi.
Using Advanced Installer. When I build and run my install project, after the install there is a folder called MyCompany (equivalent to [Manufacturer]) located within the ApplicationData folder (which resolves to C:\Users\Joey\AppData\Roaming\ on my system).
Within that particular folder is another folder called MyProgram 1.0.0 (equivalent to [ProductName] [ProductVersion].
And within that folder is another folder called install. And within that folder is a file called setup.msi with a size of 1.17MB
I have no understanding of why this file and these folders are being created. Further, after I uninstall my app, they get left behind on the system, which means my app is creating garbage.
Can someone please explain why this is happening? And also...if I can't cause this to not be present in the file system while my app is installed, how can I avoid leaving it behind on the file system after I uninstall?
Thanks.
When you are building an EXE setup file, that is the default extraction folder for the EXE, where you can find all the resources during the installation. You can change it from Media page, "Extraction folder".
It is not deleted after uninstall due a bug in Advanced Installer, you can find more details and a workaround on the forums.
How can I build a novice-usable (clickable download) installer for a Mac OS X command-line tool, and where should the binary be installed so that a novice user with no knowledge of shell paths can just open the Terminal app and type "foo" to run the freshly installed foo tool?
Can the installer also install documentation so that the user can type "man foo"?
Are there any other options that should be considered to make the use of a pure command-line (stdin, stdout) tool accessible to a novice Mac user?
What's the minimum version of OS X you're targeting? 10.6 (and IIRC 10.5) include /usr/local/bin in the default PATH, but 10.4 did not. As long as you don't need to support 10.4, you should just put the executable in /usr/local/bin and the man page in /usr/local/share/man/man1 (or whatever the appropriate chapter number is).
For building the installer itself, you can use Apple's PackageMaker utility (part of Xcode). Create a prototype local folder with bin and share/man/man1 subfolders and populate them with your files. Create a package project in PackageMaker, and choose your organization name and minimum target OS. Drag the prototype folder into the project's Contents sidebar. Set the Destination to /usr/local. Switch to the Contents tab and edit the ownership and permissions the files should be installed with (the owner/group should probably all be root/admin, with rwxrwxr-x perms on the folders and executable, rw-rw-r-- on the man page). If any irrelevant files (e.g. .DS_Store) snuck in, exclude them. Look around for any other settings you want to change, then save the project and build the installer. Then test it, to make sure it does what you expect.