I'm getting an error message when I first open my Mac terminal -

-bash: Applications: command not found

Oddly (or maybe not so oddly), when I open another tab, I sometimes get a different error -

-bash: README.md: command not found

I just noticed that this morning... there are two things that I did last night that I feel may have led to this, but I'm not sure if I am correct, nor do I know how to appropriately fix this issue. My OS is El Capitan 10.11.13.

First off, last night, I used Homebrew to install PostGIS 2.2 - my Postgres version is 9.5.1.

Second, I made a Github pull request for one of my projects (I'm not sure how a pull request could upset my bash profile, but Github's standard readme format is README.md, so I thought I'd better mention this here).

My bash profile seems clean to me -

[[ -s "$HOME/.profile" ]] && source "$HOME/.profile" # Load the default .profile

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function

export PATH=${PATH}:/usr/local/mysql/bin

Can anyone shed some light on what happened and how I can go about fixing this? I'm fairly new to using the terminal, so I'm not quite sure how to interpret this.

  • My guess is missing quotes in one of your start-up files, eg a file name with .../Applications Directory/... in its path. If this isn't quoted, then bash will see the command name as ...\Applications with the first parameter Directory/.... Search for Applications in all your start-up paths, in both /etc and your home directory. – AFH Mar 10 '16 at 19:58
  • What's in those other scripts you source, and any other bash startup scripts that may be executing? (~/.profile, ~/.rvm/scripts/rvm, ~/.bashrc) – Spiff Mar 10 '16 at 21:44
  • Thanks all - I did get an answer, though - see below. – skwidbreth Mar 10 '16 at 22:13

Well, I did discover the solution to this problem.

My bash_profile included an asterisk below the last line, which I neglected to include when I asked the question - my apologies, I didn't even really notice it there:

[[ -s "$HOME/.profile" ]] && source "$HOME/.profile" # Load the default .profile

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function


As explained to me by mklement0 on Stack Overflow:

What turned out to be the OP's problem:

A stray * on a single line in their profile expanded to an alphabetically sorted list of the names of the files and folders in the then-current directory (a process called pathname expansion or globbing).

Not only is a * as its own command (or the start of a command) not useful, it could result in unwanted execution of a command (see below). Bash then tried to execute the result of this expansion as a command to execute, with the 1st word (whitespace-separated token) interpreted as the command name.

This failed, because that first word happened not be a command name. However, if the first word happened to be a valid command name such as file, that command would execute. (Unless the current dir. happens to be in the $PATH, it doesn't matter whether the first matching filename is an executable file or not - all that matters is whether the name matches an existing command name). On startup, the user's home dir. was the working dir.; by contrast, opening another tab later uses the then-current working dir., whatever it happens to be.

This explains the differing symptoms, as globbing in different directories will typically result in different name lists, the respective first word of which Bash will try to execute.


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.