Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So, I've an executable in my debian server and this executable located in /home/human/ExecuteIt, still i cant figure it out how to run my executable in another location. In my case it is /home/human/ExecuteIt/FolderWithConfiaguration/Configuration1/.

Normally for just 1 configuration folder i can just copy/paste an executable to the /home/human/ExecuteIt/FolderWithConfiaguration/Configuration1/ and then using sudo chmod +x ./executable run it successfully, but my executable has several configuration's folders that contains different configuration.

It would be great if i could have my executable separate and execute it with different configuration without copy/pasting. Is there a way to execute my executable in different location?

share|improve this question
here is nothing about env variables – Hu Man Mar 18 '13 at 13:02
Okay. I'll delete that comment, I see you are asking a somewhat different question. However, I think you should try and clarify it: does the issue have to do with the fact the executable is sourcing configuration on a relative path? – goldilocks Mar 18 '13 at 13:05
thanks, yes the executable is sourcing configuration on a relative path, but it is doesn't matters where configuration is in, if i could use something to run the executable in the path where configurations is in – Hu Man Mar 18 '13 at 13:15

If your executable is sourcing it's configuration from a relative path, that path is relative to the pwd (present working directory). So:

> cd /there/locA
> pwd
> /there/stuff/executable

The executable will look relative to locB. Now:

> cd /there/locB
> pwd
> /there/stuff/executable

The executable will look relative to locB.

If you mean you mean you want to run the executable while the pwd is locB, but magically source the configuration from locB, the answer is that the only way to do that would be somehow tell the executable that, eg, by adding a command-line parameter with which to invoke it, or using a custom environment variable. Simply copying the executable to locA and then trying to invoke that one specifically from locB expecting it to use locA as the pwd won't work -- the pwd is still locB.

I notice setting $PWD for a single command:

> PWD=/there/locA bash -c 'echo $PWD'

doesn't work. So perhaps you cannot spoof the pwd.

share|improve this answer
ok, let me try it out :) – Hu Man Mar 18 '13 at 13:51
could you explain how an above command lines could perform execution an exe from dirA inside dirB (configuration folder)? – Hu Man Mar 18 '13 at 14:50
What I'm saying is, where exe is stored in the filesystem (whether dirA, dirB, or somewhere else) doesn't matter. If you execute it in dirA and it sources configuration using a relative path, then it is being executed in dirA. Moving the exe somewhere else will not matter. In other words: you CANNOT get the shell to pretend you are in some other directory. Your pwd is your pwd. Period. If you want the option to specify a different configuration, then you need to create that option. If you did not write the exe, then check if it has such an option (good software usually does). – goldilocks Mar 18 '13 at 15:00
how could it be like this? As i know it is possible to run an exe with another user, so you wanna say that it is impossible to do so with another folder? – Hu Man Mar 18 '13 at 15:16
"If your executable is sourcing it's configuration from a relative path, that path is relative to the pwd (present working directory)." I don't think you can assume that in a general case. It'll likely be correct in many cases, but not necessarily all. – Michael Kjörling Apr 18 '13 at 6:27

I'm not sure I understand your question, so I'll restate what I understand in my own words. You have a program that looks for its configuration files in the same directory that the program is located in. For example, if you run /home/human/ExecuteIt/FolderWithConfiaguration/Configuration1/executable, it looks for configuration files in /home/human/ExecuteIt/FolderWithConfiaguration/Configuration1. You want to be able to run the program with different configurations, for example /home/human/ExecuteIt/FolderWithConfiaguration/Configuration2. And you don't want to make multiple copies of the program.

You can make symbolic links to the executable in multiple directories, and make symbolic links to all the common files as well. For example, suppose the program requires three files: the executable executable, a data file data, and a configuration file config. You have two different configurations, which you put in /home/human/ExecuteIt/FolderWithConfiaguration/Configuration1/config and /home/human/ExecuteIt/FolderWithConfiaguration/Configuration2/config. You have one copy of the executable and the data file, both in /home/human/ExecuteIt/FolderWithConfiaguration/Configuration1/. And you make a symbolic link to /home/human/ExecuteIt/FolderWithConfiaguration/Configuration1/executable in the directory /home/human/ExecuteIt/FolderWithConfiaguration/Configuration2/, as well as a symbolic link to /home/human/ExecuteIt/FolderWithConfiaguration/Configuration1/data.

cd /home/human/ExecuteIt/FolderWithConfiaguration/Configuration2
ln -s ../Configuration1/executable ../Configuration1/data

The symbolic links tell the system to look for the real file in a different place. They don't contain any data themselves, so if you update the executable or the data in Configuration1, this applies to all configuration; and there is only one copy of the files, so the additional configurations only require the disk space for the configuration file.

Most programs that behave this way will take the location of the executable into account when looking for data and configuration files. If yours follows the symbolic link, this method won't work. Instead, you can make a hard link. Hard links are multiple paths for the same files; all the hard links to a file are equivalent.

cd /home/human/ExecuteIt/FolderWithConfiaguration/Configuration2
ln ../Configuration1/executable ../Configuration1/data

This makes it more difficult to update the files as you need to update the file designated by all the paths. Also, all the hard links to the same file have to be on the same filesystem.

share|improve this answer
I'm not sure that second-to-last sentence makes much sense. All hard links point to the same data (file content), only under different names. Update one, and all the others reflect the change immediately. That's the beauty of hard links: you can place the same content equivalently under multiple file names, without having more than one copy of the file, as long as they are all on the same file system. – Michael Kjörling Apr 18 '13 at 6:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.