Mac终端错误-bash:找不到命令-El Capitan 10.11.13

问题描述

我第一次打开Mac终端时收到错误消息-

-bash: Applications: command not found

奇怪的是(或者可能不是很奇怪)，当我打开另一个标签时，有时会出现其他错误-

-bash: README.md: command not found

或

-bash: [: missing `]'

我刚刚注意到今天早晨...我昨晚做了两件事，我认为可能导致了这一点，但是我不确定我是否正确，也不知道如何适当地解决此问题问题.我的操作系统是El Capitan 10.11.13.

首先，昨晚，我使用Homebrew安装了PostGIS 2.2-我的Postgres版本是9.5.1.

第二，我对我的一个项目发出了Github请求(我不确定请求是否会破坏我的bash配置文件，但是Github的标准自述格式为README.md，所以我想我最好提一下这里).

我的bash个人资料对我来说似乎很干净-

[[ -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
*    #EDITED TO INCLUDE THIS ASTERISK, WHICH I NEGLECTED BEFORE

任何人都可以阐明发生的事情以及如何解决此问题吗?我对使用终端还很陌生，所以我不太确定如何解释它.

解决方案

如何解决Bash启动问题:

要基于 Jonathan Leffler的有用评论:

• 在现有的终端窗口中，运行script log.txt bash -lxv
  • 这将创建一个新的登录(-l)shell(这是OSX上默认创建的Terminal.app shell的类型)并记录其所有启动活动.
  • 除了捕获常规输出外，
    • -v在读取时显示未展开的源代码行.
    • -x显示已执行的扩展的，单独的命令，其前缀为+.
• 执行exit终止该外壳程序，这会将刚刚打印的所有内容保存到log.txt.
• 研究文件log.txt以查看发生了什么情况.

---

原来是OP的问题:

• 在配置文件中一行上的流浪*扩展为按字母顺序排序的当时目录中文件和文件夹名称的列表(此过程称为路径名扩展或遍历).

>
• *不仅作为自己的命令(或命令的开始)不是有用的，还会导致不必要的命令执行(请参见下面).

• Bash然后尝试将扩展结果作为要执行的命令执行，将第一个单词(用空格分隔的标记)解释为命令 name .

  • 这失败了，因为第一个单词不是命令名称.
  • 但是，如果第一个单词碰巧是有效的命令名称，例如file，则该命令将执行.
    (除非当前目录恰好位于$PATH中，第一个匹配的文件名是否是可执行文件都没有关系-唯一重要的是名称是否与现有命令名匹配).

• 在启动时，是用户的主目录.是工作目录.相比之下，稍后打开另一个选项卡将使用当前当前的工作目录.

  • 这解释了不同的症状，因为在不同目录中进行遍历通常会导致出现不同的名称列表，Bash将尝试执行其相应的第一个单词.

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

or

-bash: [: missing `]'

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
*    #EDITED TO INCLUDE THIS ASTERISK, WHICH I NEGLECTED BEFORE

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.

解决方案

How to troubleshoot Bash startup problems:

To build on Jonathan Leffler's helpful comment:

• From an existing terminal window, run script log.txt bash -lxv
  • This will create a new login (-l) shell (which is the type of shell Terminal.app on OSX creates by default) and log all its startup activities.
  • In addition to capturing regular output,
    • -v shows unexpanded source lines as they're being read.
    • -x shows the expanded, individual commands that are executed, prefixed with +.
• Execute exit to terminate that shell, which will save everything that was just printed to log.txt.
• Study file log.txt to see what's going on.

---

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.

这篇关于Mac终端错误-bash:找不到命令-El Capitan 10.11.13的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！