First of all, you don't want to do gradle="..."
. That simply creates a variable called gradle
and is irrelevant (unless that variable is somehow used by gradle
but you haven't said so). What you want to do is add the directory containing the gradle
executable to the list of directories your system searches through when trying to find programs to run. This is what the PATH
variable does.
It is also important not to overwrite the existing contents of PATH
. So, to add foo
to the PATH
, you do:
PATH:"$PATH":foo
And not
PATH="foo"
The latter will remove everything from PATH
and replace it with foo
alone.
So, combining all this, you want to add the following lines to your ~/.profile
(or ~/.bash_profile
if that exists, but not to your ~/.bashrc
):
PATH:"$PATH:$HOME/sanctus/Documents/Development/gradle-2.2/bin"
Why ~/.profile
or ~/.bash_profile
and not ~/.bashrc
? First of all, because that's what profile is for. More importantly, ~/.bashrc
is read each time you start a new shell. So, for example, each time you open a new terminal. Setting environmental variables that only need to be set once in that file, makes them be reset each time you open a terminal and that's just needless overhead.
Additionally, settings in ~/.bashrc
only affect programs launched from the commandline. If you launch something using the GUI ( a menu entry or a .desktop
file, for example) those variables will not be available there.
In many systems, including Ubuntu, ~/.profile
is read when you log in graphically. Variables set in that file will therefore be available to GUI programs as well. Also, setting these variables in ~/.profile
is preferred since that file is only read once: at login.
Additionally, this will work even if you change your shell to something other than bash, since ~/.profile
is read by many of the most popular shells.
Important : If a ~/.bash_profile
exists, that will be read instead of ~/.profile
. So, if you do have such a file, use that one instead. My recommendation is, if you have a ~/.bash_profile
, to simply delete it and add anything that was there to your standard ~/.profile
.
The answer is to register the desired binaries with the binfmt-support service.
Studying the difference between what is on my 16.04 installations and my 14.04 installation, I found that the previous Ubuntu version had a larger list when running the command update-binfmts --display
.
The list includes a jarwrapper.
Installing the jarwrapper resolved the issue:
$ sudo apt install jarwrapper
The binfmt-support is a service that c an be configured to detect what is needed for running various type of files, including calling Wine to run Windows exe files.
Details for using the binfmt-support service can be found by studying the update-binfmts man pages.
Curious as to why the default support was dropped. But I'm glad to be able to manually restore this support to my computers.
Note
By the way, the program type isn't determined by the extension. It's determined by the application binary header. So the application can be named anything, without an extension.
Best Answer
Okay,so finally I did it.Let me explain the steps.
My file didn't have root access./etc/rc.local was trying to run it and was failing.As rc.local runs the file in root context.
Therefore I switched to crontab where I can specify the file to be run with respect to which user
Once inside the crobtab file i used
It worked.