Is it safe to place symlinks in /bin directory ?

Solution 1:

It isn't recommended to mess with /bin and with /usr/bin even though this will work it is somewhat unsafe. Also, you don't need to place your symlinks there.

I've had the same problem like you mentioned. It's cumbersome to navigate to your scripts and call them like ./myscript each and every time. Here is what I did.

Define your own bin-directory

You can create your own bin-directory and put your scripts there. Create it with

mkdir ~/bin

Now you will need to tamper with the PATH environment variable. This is a sensitive area. If you mess up the PATH variable you won't be able to execute commands with relative paths anymore. If that happens ls might not work any more /bin/ls will still do.

What I'm going to show right now will only affect the current running terminal session. So if anything goes wrong you simply log out with Ctrl+D and everything is like it was before.

echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
export PATH=$PATH:~/bin
echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/home/madmike/bin

The echo-command shows what's in $PATH before and after. export allows you to change the environment variable. Your additional bin-directory is appended to the end of the variable. This means your commands have the least priority should there be more than one command with the same name. This is good, since you don't want to override essential system commands.

To make the changes permanent, edit your ~/.bashrc file.

nano ~/.bashrc

add export PATH=$PATH:~/bin to the end of that file.

Now every new terminal-session will have the $PATH variable expanded with your directory.

Solution 2:

Before answering your question, let me explain "how it works" a little bit.

In your system you have Environment Variables. One of them PATH variable, that store set of directories where executable programs and scripts are located. In Linux, by default, PATH store a few directories. One of them /bin. That's why you can execute any program, which is located in /bin. You can check your PATH variable executing this:

echo $PATH

In PATH variable order of directories is important. The highest priority path names are specified first.

Now answering your questions:

Yes it is safe to create symlink in /bin. Of course if you do not rewrite other executables. But you should prefer to use /usr/local/bin. It is also must be in your PATH.
Yes it is. Depending on order in PATH. For example if you put symlinks of different files but with the same name both to /bin and /usr/bin, and /usr/bin included in PATH earlier than /bin, then it will use symlink from /usr/bin.

You can read about Filesystem Hierarchy here

About Ubuntu Environment Variables here

Solution 3:

Is it safe to place symlinks in /bin directory directly. I am asking this because while placing the symlinks, it asked me for administrator password.

There's a security risk. I really don't think it's wise to put your own symlinks in the /bin directory because not only your commands become global but also symbolic links can easily be broke. bash PATH environment variable is a more robust solution.
Will it create any difference if I place commands' symlinks in /bin as compared to /usr/bin directory ?

No. Although according to the Filesystem Hierarchy Standard (FHS) there's a difference between /bin and /usr/bin.

/bin Essential command binaries that need to be available in single user mode; for all users, e.g., cat, ls, cp.
/usr/bin Non-essential command binaries (not needed in single user mode); for all users.

But the difference is not that important today. Actually there's a tendency in some distributions (esp. Fedora) to fade out /bin directory.

Solution 4:

NO!!! Do not touch system directories. Every script or program you wrote you should normally place in /usr/local/bin and /usr/local/sbin directories. And adding directories to PATH is not good idea, because it has security risks.

Also, the difference between those directories that 's' s for superuser programs.