up vote 1 down vote favorite
share [g+] share [fb]

I'd like to know if moving an executable to a directory different from where it is installed will make it not be able to work? I remembered it is the case under Windows XP when running the executable by clicking its icon. Under Linux terminal, it seems that with its path specified correctly, the executable can still work? Thanks for clarification! Regards！

link|improve this question
57% accept rate
When you moved it, what happened? – S.Lott Aug 31 '09 at 18:37
In Windows, like some runtime error. In Linux, nothing happened yet. I am specially interested in the Linux case: how to make this move safe indeed? – Tim Aug 31 '09 at 19:09
feedback

migrated from stackoverflow.com Aug 31 '09 at 18:40

This question came from our site for professional and enthusiast programmers.

5 Answers

up vote 4 down vote accepted

As long as the executable can find it's dependencies (other dlls on Windows for example) then it will work. If it can't for any reason (i.e. it assumes that they are in the same directory) then it won't.

Unfortunately the error messages you get out of Windows aren't always the most helpful so you might have problems locating all the required files.

link|improve this answer
While the executable may work, in Windows at least, since uninstall information is written to the registry, these paths will be incorrect and trying to uninstall the application will result in an error and Windows just deleting the entry from the list. It's usually not a good idea to move the directory. – Will Eddins Aug 31 '09 at 18:58
@Guard - good point. – ChrisF Aug 31 '09 at 20:15
feedback
up vote 2 down vote

This depends 100% on the application.

An application by itself just needs to find it's dependencies, or the list of DLLs it requires to run. It'll look in the current directory for these most of the time, so this usually isn't an issue.

The largest issue is in the registry. If the application has written where it was installed to the registry, it may look for certain files in the old directory at runtime.

If you installed the application, this is also stored in the registry, and uninstalling from Add/Remove programs will no longer work.

If the application does not use the registry though, it can be moved without consequence. Many portable apps which run off flash drives take this approach, and as a result can be moved or deleted as needed.

link|improve this answer
feedback
up vote 0 down vote

usually. If there are shared libraries they may need to be moved too, or a path set so it can find them, depending on your operating system.

link|improve this answer
depending on the OS, the type of the libraries, the type of application, etc... there are a lot of variables – Max Schmeling Aug 31 '09 at 18:38
For Linux, shared libraries are either added to the global /etc/ld.so.conf (and the /etc/ld.so.cache is then updated by running the ldconfig command) or they are managed by setting an LD_LIBRARY_PATH or other LD_* environment settings. Normally you write a two or three line wrapper to set the LD_* value(s) and then execute your target. You should NOT just put LD_* settings in your general shell environment! Similar considerations apply to any GNU libc system, of course and some of them apply to other version of UNIX. – Jim Dennis Sep 1 '09 at 1:57
feedback
up vote 0 down vote

Theres no technical reason that you can't move an executable to any directory you want to and run it. The executable itself shouldn't know or care what its filename is or what directory its in. However, the executable must be able to find any other files it wants to to open, such as configuration files, data files, shared libraries, etc. Often times the executable will be written such that it expects to find these things in the same directory it is run from or in a sub directory, for example, the exeuctable might expect that if it is run in:

/foo/baz/bin/executable

That its config files are in

/foo/baz/etc/configfile

As long as you make sure the executable can find any other files it needs to open, you should be able to move it around as needed. Under Linux, the 'strace' command can be useful for this, you can run the exe under strace and see what files its trying to open and them grab them and move them. Also, for shared libraries 'ldd' is useful as it tells you what shared libraries the executable will try to open and which ones it isn't finding.

link|improve this answer
Thanks! In your example, if I move /foo/baz as a whole, will that be all right? I wonder why such moving of a whole package directory are often viable in Linux. If the depended files are in "the same directory it is run from or in a sub directory" of the same package, are they always specified in the executable as relative path? If the depended files are in some general directory like /usr/local, /usr etc, are they always specified in the absolute path? – Tim Aug 31 '09 at 19:16
Yes, in this example moving /foo/baz as a whole will work. Your statement about relative vs absolute paths is often true, but I bet if we looked hard enough we could find some program somewhere that did something completely weird. Often, the only way to be certain is to do the move and then using ldd,strace, broken behaviour, verify that everything is working properly. – bdk Aug 31 '09 at 19:45
feedback
up vote 0 down vote

Under Linux (and UNIX in general) most executables can be moved around freely. They usually find their dependencies automatically ... sometimes using ~/.* ("dot files") ... conventionally named things like ~/.rc (where 'rc' originally stood for "run command" but can be thought of as "resource/configuration" settings). Sometimes (increasingly) UNIX/Linux packages will create a ~/. directory (such as ~/.gnome/, ~/.firefox/ and so on).

Commonly an application will check for a ~/.* file, then look for an /etc/ configuration file. It may search in other places (such as /opt/etc/ or /usr/local/etc).

It's also fairly common for such programs to honor an environment setting ... so you export (Bourne-family shells) or setenv (csh/tcsh) an appropriate setting setting for those. Of course it's also common for them to take a command line switch to point at any configuration files or resources.

Generally it's best to refer to a program's documentation to find out about the files and environment settings. Usually a program will allow a command line switch to over-ride any environment setting, over-riding any ~/.* setting, which over-rides any /etc/* setting which might over-ride any compiled in setting. However, that's merely a loosely followed convention. Check the docs!

In general UNIX/Linux programs are far less fragile than MS Windows or older MacOS programs in managing their resource locations. There's usually no opaque "registry" or "resource forks" to hide these things from you.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown

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