Bash – How to find the program I’m hiding in bash

The alias you have defined will only take effect once the alias command is actually called. Thus if you were to do this:

$ source myscript
$ e "Hello"

It should work. However, this is clearly not ideal since you want e to be available whenever you start bash. Luckily, bash provides a number of ways to automatically run commands when the shell is started. For the full details of how bash starts up, see the manual page. For our purposes, it is enough to know that ~/.bashrc (that is, a file named ".bashrc" in your home directory) is run as your shell starts up. One way to make your alias available at startup would be to add this line at the end of ~/.bashrc:

source myscript

However, if you were to do this for every alias you wanted, your /usr/bin folder would likely become a mess. And, if you are on a multi-user system, filling /usr/bin/ with scripts like this may cause other users problems as well. Thus, it is better to place your aliases right inside .bashrc and forgo the separate script all together. Since you are using Ubuntu, inside your .bashrc file you probably have something that looks like this:

if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases 
fi

This code looks for a file call .bash_aliases in your home directory and runs anything it finds in that file as well. If you have this, or if you add this code to your .bashrc, you could also put your alias in ~/.bash_aliases. This provides an easy way to keep all your aliases in one place and keep your .bashrc file uncluttered.

You actually don't need any symlinks, just edit your ~/.bashrc and add the following statement:

PATH=$PATH:$HOME/PocketMine

This avoids polluting your filesystem with unnecessary clutter like symlinks. If you are a csh/tcsh user rather than a bash user, then edit ~/.cshrc and add

set path = ( $path ~/PocketMine )

Personally I'd go one step further in organization. I'd create a ~/bin directory, and put your start script in there, perhaps with a more distinctive name like pmstart (it's not significant that it's a shell script, is it? Maybe someday you want to re-implement it in Python or something. .sh suffices on executables are usually a bad idea because you're exposing and hard-coding an implementation detail (the implementation language) that end-users don't care about, and in the process committing yourself to that implementation detail unnecessarily).

It's likely your $PATH already includes $HOME/bin, but if not you can add it similarly.

Finally, there's are historical conventions/best practices as to what things go into sbin directories and what things go into bin directories. sbin is usually reserved for tools for administrators, while bin is for general end-user utilities.