When I use a drush command to do something on a remote machine, I get the following message:
bash: drush: command not found
What's the problem?
-
The way I see your question, it is still about bash, not Drupal itself. Nor about drush, really, because if command isn't executed, it does not matter if it's drush, tree, wget or what. And I write it without seeing any answers, my opinion is based only on the question, just as you asked.– MołotCommented Dec 2, 2014 at 13:53
-
@Mołot: Once you know the answer (and only then) it might seem to be about bash, because you realize that the source of the problem is with bash, but before you know the answer, it looks like the message means "Bash is saying that Drush is saying that the command is not found". Bash appears initially to only be carrying a message from Drush. Of course that's not what is really happening, but you don't know that until you know the answer. The question therefore is a question that a Drupal user may have, about (as far as they know) Drush. The answer brings Bash to the forefront.– iconoclastCommented Dec 2, 2014 at 23:46
-
I haven't even seen there is any answer when I posted my comment above. It is plain in your question that you are asking about bash unable to find command. You quote the error line where bash reports that it can't find drush. You, not any answerer. My first comment was in review queue and we don't even see answers there. We don't even see if there are any.– MołotCommented Dec 2, 2014 at 23:48
-
Not only does the syntax of colons seem to imply Bash is saying that Drush is saying..., but as far as the user is concerned, a Drush command was issued, so it's most natural to interpret the command that is being referred to as the Drush command, rather than Drush itself.– iconoclastCommented Dec 2, 2014 at 23:50
-
1"Answer" = "solution". "Answer != "reply". You knew the solution before you read any replies. That's not going to be true for everyone. Questions must be categorized by the content of the question not the content of the answer (or "solution" if you prefer).– iconoclastCommented Dec 2, 2014 at 23:52
|
Show 5 more comments
1 Answer
This message is from the remote machine complaining that it didn't understand where to find the drush executable, not Drush complaining that it can't find the (sub)command you may be trying to give it, even though the punctuation suggests the latter. (If bash: means Bash is passing you a message, then drush: should mean the same thing--if there's any consistency. But actually it is intended to mean drush: is the subject of the message, not the source of the message passed through bash: to you. It would be clearer if the second : were removed.)
Drush logs into your remote machine over ssh, but it's not a normal interactive login, so it doesn't source the .bash_profile. It does, however, source the .bashrc file.
Add the drush path (not including drush itself, just including the directory containing drush) to the PATH variable in your remote .bashrc and all should be well. For instance, that may look like this:
PATH=$PATH:/usr/local/zend/bin
answered Oct 8, 2012 at 2:45
-
8Also look out for the following in your ~/.bashrc:
[ -z "$PS1" ] && return. Some platforms use this to bail out if running in non-interactive mode. Ubuntu, for example, puts this in your initial .bashrc. If you set your PATH, you need to make sure that you set it before any conditional such as this one that may force an early exit. Commented Oct 8, 2012 at 5:58 -
3Thanks for the answer and comment. I had to edit the path in
.bashrcbefore the line# If not running interactively, don't do anything case $- in *i*) ;; *) return;; esacon Ubuntu 14.04 Commented Jul 24, 2014 at 19:56 -
This thread may help if the above answer doesn't. On MacOS Catalina, I had to add a
zshenvfile (without a leading dot) with my desired export paths inside /etc (not my home directory).– DoomdCommented Sep 10, 2020 at 0:12