Install newer version of application in $HOME without root access and linking to installed app
Clash Royale CLAN TAG#URR8PPP
I have this linux box without root access with a quite old emacs, so I downloaded the latest version and built as follows:
- download to
$HOME/SRC
- configure and build in
$HOME/BLD
with--prefix=$HOME
make
andmake install
So this creates a bin
folder in my home directory which is what I expected.
Now when I type emacs directly from terminal, it still opens the old one (as expected). So, I have to do ~/bin/emacs
. I added this alias emacs=$HOME/bin/emacs
to my .bash_profile
which works. But I could have also added ~/bin
to $PATH
. However, not quite sure which one is recommended. And would the 2 versions of emacs work without any conflict e.g. both sharing and overwriting ~/.emacs
each time a different version is opened.
Which is the best way to install new applications without root access where an older version is already present, and if the steps I followed are right.
linux software-installation make source
add a comment |
I have this linux box without root access with a quite old emacs, so I downloaded the latest version and built as follows:
- download to
$HOME/SRC
- configure and build in
$HOME/BLD
with--prefix=$HOME
make
andmake install
So this creates a bin
folder in my home directory which is what I expected.
Now when I type emacs directly from terminal, it still opens the old one (as expected). So, I have to do ~/bin/emacs
. I added this alias emacs=$HOME/bin/emacs
to my .bash_profile
which works. But I could have also added ~/bin
to $PATH
. However, not quite sure which one is recommended. And would the 2 versions of emacs work without any conflict e.g. both sharing and overwriting ~/.emacs
each time a different version is opened.
Which is the best way to install new applications without root access where an older version is already present, and if the steps I followed are right.
linux software-installation make source
emacs is quite large. You should discuss either upgrading the existing emacs that's installed, or supporting multiple versions of emacs with your sysadmin.
– bsd
Mar 3 '12 at 16:30
possible duplicate of How to run my own program without specifying its path
– Gilles
Mar 3 '12 at 23:44
add a comment |
I have this linux box without root access with a quite old emacs, so I downloaded the latest version and built as follows:
- download to
$HOME/SRC
- configure and build in
$HOME/BLD
with--prefix=$HOME
make
andmake install
So this creates a bin
folder in my home directory which is what I expected.
Now when I type emacs directly from terminal, it still opens the old one (as expected). So, I have to do ~/bin/emacs
. I added this alias emacs=$HOME/bin/emacs
to my .bash_profile
which works. But I could have also added ~/bin
to $PATH
. However, not quite sure which one is recommended. And would the 2 versions of emacs work without any conflict e.g. both sharing and overwriting ~/.emacs
each time a different version is opened.
Which is the best way to install new applications without root access where an older version is already present, and if the steps I followed are right.
linux software-installation make source
I have this linux box without root access with a quite old emacs, so I downloaded the latest version and built as follows:
- download to
$HOME/SRC
- configure and build in
$HOME/BLD
with--prefix=$HOME
make
andmake install
So this creates a bin
folder in my home directory which is what I expected.
Now when I type emacs directly from terminal, it still opens the old one (as expected). So, I have to do ~/bin/emacs
. I added this alias emacs=$HOME/bin/emacs
to my .bash_profile
which works. But I could have also added ~/bin
to $PATH
. However, not quite sure which one is recommended. And would the 2 versions of emacs work without any conflict e.g. both sharing and overwriting ~/.emacs
each time a different version is opened.
Which is the best way to install new applications without root access where an older version is already present, and if the steps I followed are right.
linux software-installation make source
linux software-installation make source
edited Jan 6 at 21:33
Rui F Ribeiro
39.6k1479132
39.6k1479132
asked Mar 3 '12 at 12:54
visvis
420158
420158
emacs is quite large. You should discuss either upgrading the existing emacs that's installed, or supporting multiple versions of emacs with your sysadmin.
– bsd
Mar 3 '12 at 16:30
possible duplicate of How to run my own program without specifying its path
– Gilles
Mar 3 '12 at 23:44
add a comment |
emacs is quite large. You should discuss either upgrading the existing emacs that's installed, or supporting multiple versions of emacs with your sysadmin.
– bsd
Mar 3 '12 at 16:30
possible duplicate of How to run my own program without specifying its path
– Gilles
Mar 3 '12 at 23:44
emacs is quite large. You should discuss either upgrading the existing emacs that's installed, or supporting multiple versions of emacs with your sysadmin.
– bsd
Mar 3 '12 at 16:30
emacs is quite large. You should discuss either upgrading the existing emacs that's installed, or supporting multiple versions of emacs with your sysadmin.
– bsd
Mar 3 '12 at 16:30
possible duplicate of How to run my own program without specifying its path
– Gilles
Mar 3 '12 at 23:44
possible duplicate of How to run my own program without specifying its path
– Gilles
Mar 3 '12 at 23:44
add a comment |
1 Answer
1
active
oldest
votes
Adjust your PATH
. It simplifies execution, works as expected, and once you install more applications with your $HOME
as prefix, they'll all work as expected. I'd do something like this in my RC file:
PATH=$HOME/bin:$PATH
LD_RUN_PATH=$HOME/lib:$LD_RUN_PATH
export PATH LD_RUN_PATH
Setting LD_RUN_PATH
should allow locally-install DSOs to work too.
What you've done to install emacs so far is pretty much the way it's done in multi-user environments.
Clarification: paths in Unix (and other software that use them, from DOS to TeX) work like lists of places, searched left to right. On Unix, we use colons (:
) to separate the entries. If you have a PATH
like /usr/local/bin:/bin:/usr/bin
, and you're looking for a program called foo
, these paths will be searched for, in order:
/usr/local/bin/foo
/bin/foo
/usr/bin/foo
The first of these found is used. So, depending on where exactly you insert a directory, you can make your installed binaries ‘override’ others. Conceptually, the order of PATH
is traditionally specific-to-generic or local-to-global. (of course, we often add weird paths to support self-contained third-party applications and this can break this analogy)
just to confirm, if I add$HOME/bin
to my PATH, all programs installed there will take precedence over those (existing older versions) installed as root in/usr/bin
and other locations in PATH? Basically does it matter to append or prepend$HOME/bin
to PATH? e.g.PATH=$PATH:$HOME/bin
instead of the above. And one more question, what if I want to install a newer version of the same program in$HOME/bin
? I am guessing it would append the version number to the new files?
– vis
Mar 3 '12 at 14:04
3
@vis: the directories in$PATH
are tested from left to right, soPATH=$HOME/bin:$PATH
makes versions in$HOME/bin
override the others, withPATH=$PATH:$HOME/bin
, your version will only be used if no other is present. Re the new versions: usually, no version number is appended automatically. It's probably a good idea to rename the executables/directories and put symlinks in (so~/bin/emacs
is a symlink to~/bin/emacs-26.3.1
which is the executable thatmake install
calledemacs
).
– Ulrich Schwarz
Mar 3 '12 at 14:56
2
Some info for completeness: /usr/bin is for binaries included with the distro / package manager. Place your own binaries in /opt or /usr/local/bin. That way a system upgrade won't risk wiping your manual binaries.
– invert
Mar 3 '12 at 18:49
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f33326%2finstall-newer-version-of-application-in-home-without-root-access-and-linking-to%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Adjust your PATH
. It simplifies execution, works as expected, and once you install more applications with your $HOME
as prefix, they'll all work as expected. I'd do something like this in my RC file:
PATH=$HOME/bin:$PATH
LD_RUN_PATH=$HOME/lib:$LD_RUN_PATH
export PATH LD_RUN_PATH
Setting LD_RUN_PATH
should allow locally-install DSOs to work too.
What you've done to install emacs so far is pretty much the way it's done in multi-user environments.
Clarification: paths in Unix (and other software that use them, from DOS to TeX) work like lists of places, searched left to right. On Unix, we use colons (:
) to separate the entries. If you have a PATH
like /usr/local/bin:/bin:/usr/bin
, and you're looking for a program called foo
, these paths will be searched for, in order:
/usr/local/bin/foo
/bin/foo
/usr/bin/foo
The first of these found is used. So, depending on where exactly you insert a directory, you can make your installed binaries ‘override’ others. Conceptually, the order of PATH
is traditionally specific-to-generic or local-to-global. (of course, we often add weird paths to support self-contained third-party applications and this can break this analogy)
just to confirm, if I add$HOME/bin
to my PATH, all programs installed there will take precedence over those (existing older versions) installed as root in/usr/bin
and other locations in PATH? Basically does it matter to append or prepend$HOME/bin
to PATH? e.g.PATH=$PATH:$HOME/bin
instead of the above. And one more question, what if I want to install a newer version of the same program in$HOME/bin
? I am guessing it would append the version number to the new files?
– vis
Mar 3 '12 at 14:04
3
@vis: the directories in$PATH
are tested from left to right, soPATH=$HOME/bin:$PATH
makes versions in$HOME/bin
override the others, withPATH=$PATH:$HOME/bin
, your version will only be used if no other is present. Re the new versions: usually, no version number is appended automatically. It's probably a good idea to rename the executables/directories and put symlinks in (so~/bin/emacs
is a symlink to~/bin/emacs-26.3.1
which is the executable thatmake install
calledemacs
).
– Ulrich Schwarz
Mar 3 '12 at 14:56
2
Some info for completeness: /usr/bin is for binaries included with the distro / package manager. Place your own binaries in /opt or /usr/local/bin. That way a system upgrade won't risk wiping your manual binaries.
– invert
Mar 3 '12 at 18:49
add a comment |
Adjust your PATH
. It simplifies execution, works as expected, and once you install more applications with your $HOME
as prefix, they'll all work as expected. I'd do something like this in my RC file:
PATH=$HOME/bin:$PATH
LD_RUN_PATH=$HOME/lib:$LD_RUN_PATH
export PATH LD_RUN_PATH
Setting LD_RUN_PATH
should allow locally-install DSOs to work too.
What you've done to install emacs so far is pretty much the way it's done in multi-user environments.
Clarification: paths in Unix (and other software that use them, from DOS to TeX) work like lists of places, searched left to right. On Unix, we use colons (:
) to separate the entries. If you have a PATH
like /usr/local/bin:/bin:/usr/bin
, and you're looking for a program called foo
, these paths will be searched for, in order:
/usr/local/bin/foo
/bin/foo
/usr/bin/foo
The first of these found is used. So, depending on where exactly you insert a directory, you can make your installed binaries ‘override’ others. Conceptually, the order of PATH
is traditionally specific-to-generic or local-to-global. (of course, we often add weird paths to support self-contained third-party applications and this can break this analogy)
just to confirm, if I add$HOME/bin
to my PATH, all programs installed there will take precedence over those (existing older versions) installed as root in/usr/bin
and other locations in PATH? Basically does it matter to append or prepend$HOME/bin
to PATH? e.g.PATH=$PATH:$HOME/bin
instead of the above. And one more question, what if I want to install a newer version of the same program in$HOME/bin
? I am guessing it would append the version number to the new files?
– vis
Mar 3 '12 at 14:04
3
@vis: the directories in$PATH
are tested from left to right, soPATH=$HOME/bin:$PATH
makes versions in$HOME/bin
override the others, withPATH=$PATH:$HOME/bin
, your version will only be used if no other is present. Re the new versions: usually, no version number is appended automatically. It's probably a good idea to rename the executables/directories and put symlinks in (so~/bin/emacs
is a symlink to~/bin/emacs-26.3.1
which is the executable thatmake install
calledemacs
).
– Ulrich Schwarz
Mar 3 '12 at 14:56
2
Some info for completeness: /usr/bin is for binaries included with the distro / package manager. Place your own binaries in /opt or /usr/local/bin. That way a system upgrade won't risk wiping your manual binaries.
– invert
Mar 3 '12 at 18:49
add a comment |
Adjust your PATH
. It simplifies execution, works as expected, and once you install more applications with your $HOME
as prefix, they'll all work as expected. I'd do something like this in my RC file:
PATH=$HOME/bin:$PATH
LD_RUN_PATH=$HOME/lib:$LD_RUN_PATH
export PATH LD_RUN_PATH
Setting LD_RUN_PATH
should allow locally-install DSOs to work too.
What you've done to install emacs so far is pretty much the way it's done in multi-user environments.
Clarification: paths in Unix (and other software that use them, from DOS to TeX) work like lists of places, searched left to right. On Unix, we use colons (:
) to separate the entries. If you have a PATH
like /usr/local/bin:/bin:/usr/bin
, and you're looking for a program called foo
, these paths will be searched for, in order:
/usr/local/bin/foo
/bin/foo
/usr/bin/foo
The first of these found is used. So, depending on where exactly you insert a directory, you can make your installed binaries ‘override’ others. Conceptually, the order of PATH
is traditionally specific-to-generic or local-to-global. (of course, we often add weird paths to support self-contained third-party applications and this can break this analogy)
Adjust your PATH
. It simplifies execution, works as expected, and once you install more applications with your $HOME
as prefix, they'll all work as expected. I'd do something like this in my RC file:
PATH=$HOME/bin:$PATH
LD_RUN_PATH=$HOME/lib:$LD_RUN_PATH
export PATH LD_RUN_PATH
Setting LD_RUN_PATH
should allow locally-install DSOs to work too.
What you've done to install emacs so far is pretty much the way it's done in multi-user environments.
Clarification: paths in Unix (and other software that use them, from DOS to TeX) work like lists of places, searched left to right. On Unix, we use colons (:
) to separate the entries. If you have a PATH
like /usr/local/bin:/bin:/usr/bin
, and you're looking for a program called foo
, these paths will be searched for, in order:
/usr/local/bin/foo
/bin/foo
/usr/bin/foo
The first of these found is used. So, depending on where exactly you insert a directory, you can make your installed binaries ‘override’ others. Conceptually, the order of PATH
is traditionally specific-to-generic or local-to-global. (of course, we often add weird paths to support self-contained third-party applications and this can break this analogy)
edited Mar 3 '12 at 16:09
answered Mar 3 '12 at 13:16
AlexiosAlexios
14.3k14966
14.3k14966
just to confirm, if I add$HOME/bin
to my PATH, all programs installed there will take precedence over those (existing older versions) installed as root in/usr/bin
and other locations in PATH? Basically does it matter to append or prepend$HOME/bin
to PATH? e.g.PATH=$PATH:$HOME/bin
instead of the above. And one more question, what if I want to install a newer version of the same program in$HOME/bin
? I am guessing it would append the version number to the new files?
– vis
Mar 3 '12 at 14:04
3
@vis: the directories in$PATH
are tested from left to right, soPATH=$HOME/bin:$PATH
makes versions in$HOME/bin
override the others, withPATH=$PATH:$HOME/bin
, your version will only be used if no other is present. Re the new versions: usually, no version number is appended automatically. It's probably a good idea to rename the executables/directories and put symlinks in (so~/bin/emacs
is a symlink to~/bin/emacs-26.3.1
which is the executable thatmake install
calledemacs
).
– Ulrich Schwarz
Mar 3 '12 at 14:56
2
Some info for completeness: /usr/bin is for binaries included with the distro / package manager. Place your own binaries in /opt or /usr/local/bin. That way a system upgrade won't risk wiping your manual binaries.
– invert
Mar 3 '12 at 18:49
add a comment |
just to confirm, if I add$HOME/bin
to my PATH, all programs installed there will take precedence over those (existing older versions) installed as root in/usr/bin
and other locations in PATH? Basically does it matter to append or prepend$HOME/bin
to PATH? e.g.PATH=$PATH:$HOME/bin
instead of the above. And one more question, what if I want to install a newer version of the same program in$HOME/bin
? I am guessing it would append the version number to the new files?
– vis
Mar 3 '12 at 14:04
3
@vis: the directories in$PATH
are tested from left to right, soPATH=$HOME/bin:$PATH
makes versions in$HOME/bin
override the others, withPATH=$PATH:$HOME/bin
, your version will only be used if no other is present. Re the new versions: usually, no version number is appended automatically. It's probably a good idea to rename the executables/directories and put symlinks in (so~/bin/emacs
is a symlink to~/bin/emacs-26.3.1
which is the executable thatmake install
calledemacs
).
– Ulrich Schwarz
Mar 3 '12 at 14:56
2
Some info for completeness: /usr/bin is for binaries included with the distro / package manager. Place your own binaries in /opt or /usr/local/bin. That way a system upgrade won't risk wiping your manual binaries.
– invert
Mar 3 '12 at 18:49
just to confirm, if I add
$HOME/bin
to my PATH, all programs installed there will take precedence over those (existing older versions) installed as root in /usr/bin
and other locations in PATH? Basically does it matter to append or prepend $HOME/bin
to PATH? e.g. PATH=$PATH:$HOME/bin
instead of the above. And one more question, what if I want to install a newer version of the same program in $HOME/bin
? I am guessing it would append the version number to the new files?– vis
Mar 3 '12 at 14:04
just to confirm, if I add
$HOME/bin
to my PATH, all programs installed there will take precedence over those (existing older versions) installed as root in /usr/bin
and other locations in PATH? Basically does it matter to append or prepend $HOME/bin
to PATH? e.g. PATH=$PATH:$HOME/bin
instead of the above. And one more question, what if I want to install a newer version of the same program in $HOME/bin
? I am guessing it would append the version number to the new files?– vis
Mar 3 '12 at 14:04
3
3
@vis: the directories in
$PATH
are tested from left to right, so PATH=$HOME/bin:$PATH
makes versions in $HOME/bin
override the others, with PATH=$PATH:$HOME/bin
, your version will only be used if no other is present. Re the new versions: usually, no version number is appended automatically. It's probably a good idea to rename the executables/directories and put symlinks in (so ~/bin/emacs
is a symlink to ~/bin/emacs-26.3.1
which is the executable that make install
called emacs
).– Ulrich Schwarz
Mar 3 '12 at 14:56
@vis: the directories in
$PATH
are tested from left to right, so PATH=$HOME/bin:$PATH
makes versions in $HOME/bin
override the others, with PATH=$PATH:$HOME/bin
, your version will only be used if no other is present. Re the new versions: usually, no version number is appended automatically. It's probably a good idea to rename the executables/directories and put symlinks in (so ~/bin/emacs
is a symlink to ~/bin/emacs-26.3.1
which is the executable that make install
called emacs
).– Ulrich Schwarz
Mar 3 '12 at 14:56
2
2
Some info for completeness: /usr/bin is for binaries included with the distro / package manager. Place your own binaries in /opt or /usr/local/bin. That way a system upgrade won't risk wiping your manual binaries.
– invert
Mar 3 '12 at 18:49
Some info for completeness: /usr/bin is for binaries included with the distro / package manager. Place your own binaries in /opt or /usr/local/bin. That way a system upgrade won't risk wiping your manual binaries.
– invert
Mar 3 '12 at 18:49
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f33326%2finstall-newer-version-of-application-in-home-without-root-access-and-linking-to%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
emacs is quite large. You should discuss either upgrading the existing emacs that's installed, or supporting multiple versions of emacs with your sysadmin.
– bsd
Mar 3 '12 at 16:30
possible duplicate of How to run my own program without specifying its path
– Gilles
Mar 3 '12 at 23:44