How would I go about copying the JAR file to the startup directory?

I hav开发者_开发百科e the following methods at my disposal:

• A method to get the running JAR file's path. (The path of the file to copy).
• A method to get the current operating system. (Mac, Windows, Linux, or Unknown).

How would I go about writing a method to copy the JAR file to the startup directory based on the type of computer?

The concept of a "startup directory" that you can drop executables into to run at startup time does not make sense for Linux / UNIX.

In a typical Linux system, tasks performed on system startup are controlled by the init process based on shell scripts that are typically installed in /etc/init.d. The chkconfig program manages a bunch of links in "run level" directories that tell init what to run for each system run level.

The init.d scripts are not just any old script.

• They have to obey a specific "protocol"; i.e. support certain comman options.
• They typically have special comments that tell the chkconfig program when the script should be run; i.e. at what run levels, and in what order.

I believe that modern UNIX systems work roughly the same way, though I known that some older versions did this differently.

_{Update in 20012: It gets worse. Recent Linux distros are replacing init.d scripts with upstart scripts. Sigh.}

The above deals with system startup. There is no general concept of a "startup directory" for users either.

I guess, a window manager could implement a "startup directory", but a typical Linux user is free to choose and configure the window manager, or use no window manager at all.

The normal way to configure things to happen when the user logs in is via shell initialization scripts; e.g. ~/.bashrc, ~/.bash_login and so on. It is a BAD IDEA for an installer to modify those files because it would be next to impossible to get it right in all circumstances ... given the weird and wonderful things it is possible to do in a shell initialization script.

The bottom line though is that if you are writing installers to install your software for a number of platforms, you have to understand those platforms. You need hands on experience using them and (to some level) administering them, and specific knowledge of the "right way" to do software installation. Clearly you don't have that knowledge yet for Linux / UNIX.

Writing installers without adequate knowledge and adequate testing is really, really dangerous. An installer has to be run at a privilege level that means that it can do serious damage to the target system if something goes wrong.

Use Apache Commons IO's FileUtils to copy the file (if you have the path and the name) to anywhere as long as you have permissions to write in destination.

Somehow this question sounds like asking for a wrong way to do it. Why don't you start the jar from where it is - java -jar /path/to/the/jar.jar or java -cp /path/the/jar.jar mainpackage.MainClass

On Linux, the startup-dir - the dir, where you normally start , if you open a shell - is your $HOME, alias /home/$USER, or just the current directory . or $(pwd) or $PWD from there.

cp JARFILE $PWD 

Would therefore copy the jar to the current dir, if nobody changed the starting dir. However, if you place a starter on the desktop, that might choose $HOME/Desktop as the startup-dir.

On Linux, there is no official startup-dir; nobody uses this expression.

We're talking about autostart?

If you want to run a program on the server, /etc/init.d might be the right place to put your program, or better a starting script for your program, which would go to /usr/local/... or /opt/ or /var, depending on Linux flavour and user preferences.

If your program needs X (uses awt/swing/swt) it will need to wait for X to come up, then /etc/X11/Xsession.d would be the place to put the startscript.

Depending on resources it needs to run, there would be further considerations.

If it uses networking resources, and actions should be taken, depending on network start or shutdown, or on powermanagement, there are again different directories, to look for.

According with Stephen C., if you don't have any experience with Linux, you should give us much more information. What does your program do? Can we see it? Is it OpenSource? Which computer resources does it use? Client or server? GUI or console? Run by whom?