I have created a Bash script that simply does ls -l.

In Mavericks and older versions of OSX I simply made a symlink to the script and put it in the /usr/bin folder (ln -s ll.sh /usr/bin/ll) and I could then execute the script using ll from any folder.

Since upgrading to El Capitan I am unable to load this script. I have disabled SIP so that I am able to create the symlink and the script is definitely executable. The location (/usr/bin) is definitely in the $PATH and I have even tried adding a path to the script into the $PATH too.

Nothing seems to work, all I am getting is -bash: ll: command not found.

I have restarted the terminal after each update to the $PATH and I have tried source ~/.bash_profile but neither are making any difference.

Edit: I also tried adding the current directory of the scripts to the $PATH and that was also giving the same error. In the end I have aliased all my scripts so that they will run.

  • when you run your ll.sh does it work ?
    – enzo
    Commented Oct 16, 2015 at 14:23
  • 2
    If all the the ll.sh -script_ is doing is ls -l then you should use an alias instead. Set alias ll='ls -l' in the ~/.profile or ~/.bash_profile, whichever you're using. See 6.6 Aliases in the BASH Reference Manual. Commented Oct 16, 2015 at 14:29
  • I used the ls -l as an example, I have quite a few scripts that do different things. I could make an alias for them all but I wondered if the previous implementation was still possible. If I run the .sh script it runs fine. Commented Oct 16, 2015 at 14:34
  • 1
    A couple of things... There really is no need to use an extension on the shell scripts, e.g. ll.sh simply needs to be ll. I have a separate directory I put all of my scripts in and add that directory pathname to the $PATH. I have 150 scripts I've written in that directory and not one has an extension yet they're all executable. Some even have symlinks (not Finder Alaises, and not to be confused with bash aliases) to shorter names to type in the Terminal for convenience. This way all of my scripts are more centrally located and do not get mixed in with system executables. Commented Oct 16, 2015 at 15:04
  • Can you please please add the full script to the question? And the output of ls -l /usr/bin/ll ?
    – nohillside
    Commented Oct 16, 2015 at 15:59

2 Answers 2


I'm not sure what's wrong with your setup, but a different (perhaps better) way to do this same thing is via Bash's alias command. At the command prompt, type in:

alias ll="ls -l"

Then you can just type ll and get a full listing. If you wish to make this permanent, you can put it in the .bashrc file in your home directory, which you can create if it doesn't already exist.

  • It's also worth noting that you can alias the command to a file location ll=~/scripts/ll.sh, which is what I have ended up doing. Thanks for the help! Commented Oct 19, 2015 at 9:29

Just read the comments and see that you're looking for a general solution, rather than that specific example. I'll leave my previous answer in case it helps someone, but here's a more general solution.

My first piece of advice: leave /usr/bin alone. There's no reason to mess with it and there are many reasons not to mess with it. Instead, add a directory somewhere else, put you scripts there, and add it to you $PATH variable. If you want this just for your user, you could create a scripts or bin directory in your home directory, or if you want it globally available you could put it under /usr/local, e.g. /usr/local/scripts or /usr/local/bin. Then, in the .bashrc file in your home directory, add the following:

export PATH=$PATH:~/scripts:/usr/local/scripts

If you would rather have your commands override a system command (should they have the same name) then you could do the following, instead:

export PATH=~/scripts:/usr/local/scripts:$PATH

If you want this set for all users, then there is a global /etc/bashrc file that you can add the above to.

In order to edit the global bashrc or modify /usr/local you need root/admin privileges.

  • 3
    Note that /usr/local/bin is already in the default PATH, so if you put things there you don't have to worry about customizing the PATH. Commented Oct 17, 2015 at 18:58
  • Don't you need quotes around PATH absolute path? Commented Nov 29, 2015 at 20:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .