PDA

View Full Version : Executable & libraries in one folder, but force it's output into different folder



wolfgentleman
August 9th, 2014, 10:39 AM
I have a set of binaries, 2 regular and 3+ libraries. Some libraries are in sub-folders. I want to launch the main binary in such a way that it places any files it creates into a folder above it. Here is a generic layout before and after the run.

Before:


BaseDir








exec






lib1.so






libDir








library1a.so






library1b.so




textfile.txt




OtherDir






After (how it is now):


BaseDir








exec






lib1.so






libDir








library1a.so






library1b.so




textfile.txt






someDir








generatedFile.txt




otherGeneratedFile.txt




OtherDir






After (how I want it):


BaseDir








exec






lib1.so






libDir








library1a.so






library1b.so




textfile.txt




OtherDir








someDir








generatedFile.txt




otherGeneratedFile.txt




So, how can I launch it in such a way that it writes/reads generated files/folders to 'OtherDir', but still use the libraries and run the other executable (which is in a sub-directory of 'BaseDir') without linking the entire contents of 'BaseDir' into 'OtherDir'. I just so everyone knows: this is a closed source and commercial program that, with the permission of the developers, I am making a deb package for. The files it generates are databases and uploaded content, of which would get destroyed on an upgrade - I did it without backing up the folder and poof...

ofnuts
August 9th, 2014, 01:46 PM
The setup is totally non-Unixish. Even on Windows now it's a capital sin to mix user data and executable code in the same directories.... if only because as you saw this often puts your data in jeopardy.

You don't tell us why it writes files in specific directories. Is it because it is the current directory when it starts? Or because it finds it using the location of the executable itself? If the latter there are likely ways to trick it using links in the proper directories. Typically you would set up a directory for data and put in it links to the executable files installed elsewhere. This way you can put th executable files in a public place, and keep the data separately (and each user with his own set of data). Of course you would start the application using the "user" links.

wolfgentleman
August 9th, 2014, 07:27 PM
The setup is totally non-Unixish. Even on Windows now it's a capital sin to mix user data and executable code in the same directories.... if only because as you saw this often puts your data in jeopardy.
If only it was punishable :p


You don't tell us why it writes files in specific directories. Is it because it is the current directory when it starts? Or because it finds it using the location of the executable itself? If the latter there are likely ways to trick it using links in the proper directories.
I didn't say because I don't know... Let me cd to the external directory and maybe run it using the relative path.
UPDATE: Running it with a relative path made it balk because it did not find the libs.
UPDATE 2: Tried linking the libraries, but it still complained.
UPDATE 3: I had an idea, but it just seems so sloppy... I could run it, kill it, move the generated files, and symlink them back...


Typically you would set up a directory for data and put in it links to the executable files installed elsewhere. This way you can put the executable files in a public place, and keep the data separately (and each user with his own set of data). Of course you would start the application using the "user" links.
Unfortunately, they didn't do it that way. As stupid as it is... And BTW those files are system wide, as it is a service that provides a server.

ofnuts
August 10th, 2014, 10:10 PM
If only it was punishable :p

It is punished. Misbehaving software like this gets bad press. Sooner or later is means some sale going to the competition (which could come from some developer fed up with their stuff and deciding to make his own).


Unfortunately, they didn't do it that way. As stupid as it is...

If they are really interested in getting a .deb, then they could tell you how they locate the files and then you could devise some way to keep them happy. Otherwise, they aren't interested in having a .deb, in which case see my remark above.

dwhitney67
August 11th, 2014, 09:15 PM
Just write a script to take care of the undesirable nuances of the executable program. For example:



#!/bin/bash

LD_LIBRARY_PATH=$PWD:$PWD/libDir ./exec

if [ $? -eq 0 ]; then
mv someDir otherDir
mv otherGeneratedFile.txt otherDir
fi