I've compiled linked and created a program in C++ now I have


I want to be able to put it into the bin directory and use it like system wide commands e.g.

ssh, echo, bash, cd...

How can I achieve that?

  • 2
    Normally you'd call it just foobar, not foobar.out. (e.g. gcc -Wall -O3 -march=native foobar.c -o foobar). a.out is the default name, but don't take that as an example. – Peter Cordes Sep 4 '17 at 7:51

There are two ways of allowing you to run the binary without specifying its path (not including creating aliases or shell functions to execute it with an absolute path for you):

  1. Copy it to a directory that is in your $PATH.
  2. Add the directory where it is to your $PATH.

To copy the file to a directory in your path, for example /usr/local/bin (where locally managed software should go), you must have superuser privileges, which usually means using sudo:

$ sudo cp -i mybinary /usr/local/bin

Care must be taken not to overwrite any existing files in the target directory (this is why I added -i here).

To add a directory to your $PATH, add a line in your ~/.bashrc file (if you're using bash):


... if the binary is in $HOME/bin.

This has the advantage that you don't need to have superuser privileges or change/add anything in the base system on your machine. You just need to move the binary into the bin directory of your home directory.

Note, changes to .bashrc takes effect when the file is sourced next time, which happens if you open a new terminal or log out and in again, or run source ~/.bashrc manually.

| improve this answer | |
  • One additional point is that directories in the PATH are searched in order: with the new PATH as given, if your program has the same name as one in previous directories, the system will still find & run that one. You can either change PATH so that $HOME/bin is earlier, or use an alias to your new program. – jamesqf Sep 3 '17 at 17:40
  • @jamesqf I changed the order. Personal binaries are almost always wanted with priority over base system binaries. – Kusalananda Sep 3 '17 at 17:43
  • Best is to keep it in its own directory and symlink it to one of the PATH directories – Fez Vrasta Sep 3 '17 at 20:34
  • @Kusalananda: Or "source your_shell's_rc_file", since not everyone chooses to use bash. – jamesqf Sep 4 '17 at 4:06
  • install is nice; it makes the script root-owned. (So in theory, someone that cracks your account couldn't mess it up. At least not until they get root privs next time you manually sudo or something...) – Peter Cordes Sep 4 '17 at 7:49

You should read more about the PATH variable. I strongly suspect that you should use (or change) it appropriately.

I want to be able to put it into the bin directory

I guess you mean /bin/ or /usr/bin/. I am not sure it is wise to add your own programs there. Perhaps it would be better to put a symlink inside them (e.g. using something like ln -sv $(realpath foobar.out) /usr/bin/), if you absolutely want your program to appear there (which IMHO is probably a mistake since you are messing up with your distribution's package manager).

Probably installing your program in /usr/local/bin/ is much wiser (to leave both /bin/ and /usr/bin/ intact, as provided and managed by your Linux distribution). See LSB and read more about the File Hierarchy Standard.

... like system wide commands e.g .... cd

This is a strong misconception of your part (in the original variant of your question, you rightly removed cd later). cd is not and cannot be an executable, it is (and has to be) a builtin command of your shell.

You may want to read the freely downloadable Advanced Linux Programming to understand why cd cannot be an executable (the current working directory is part of the state of each process, and every process has its own one and could change it using chdir(2)...)

| improve this answer | |
install /path/to/oobar.out /usr/local/bin/
| improve this answer | |

Copy your executable to /usr/bin/, you should then be able to execute it like echo or any other executable in /usr/bin/

cp -a <filename> /usr/bin/
chmod a+x /usr/bin/filename
| improve this answer | |
  • 2
    wow just like that! Linux is truly awesome thanks! – NullOverFlow Sep 2 '17 at 14:10
  • 4
    In practice that is a bad advice. My answer explains why. – Basile Starynkevitch Sep 2 '17 at 14:23

I would add to the accepted answer by @Kusalananda Another advantage to placing your home brewed scripts and programs in $HOME/bin is when you upgrade your system, you won't lose them. It's a better way to manage your personal toolbox, and makes it more portable.

| improve this answer | |
  • /usr/local/bin is a good choice too, depending on whether it's a script that only you would use or not. I keep (parts of) my /usr/local on new installs. – Peter Cordes Sep 4 '17 at 7:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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