This question already has an answer here:
how to fix "bash: flutter: command not found" error?
(1 answer)
Closed 2 years ago.
I have read through a lot of posts regarding command not found error messages in the terminal but I can't find any specific to surge.
I am running into an error when using the surge command in my terminal. I ran npm install --global surge in my terminal and everything looks okay, but when I run the command surge it returns command not found.
The other npm packages on my computer work fine. I tested create-react-app and no errors. I am somewhat new to this, any advice would be appreciated!!
Thanks and cheers!!
Just use npx surge instead of surge
:)
Are you sure surge executable is installed?
what shell are you in?
If in bash, try re-hash-ing:
hash [-lr] [-p filename] [-dt] [name]
Each time hash is invoked, the full pathname of the command name is determined by searching the directories in $PATH and remembered.
Any previously-remembered pathname is discarded. If the -p option is supplied, no path search is performed, and filename is used as
the full filename of the command. The -r option causes the shell to forget all remembered locations. The -d option causes the shell
to forget the remembered location of each name. If the -t option is supplied, the full pathname to which each name corresponds is
printed. If multiple name arguments are supplied with -t, the name is printed before the hashed full pathname. The -l option causes
output to be displayed in a format that may be reused as input. If no arguments are given, or if only -l is supplied, information
about remembered commands is printed. The return status is true unless a name is not found or an invalid option is supplied.
There is a chance that the surge binary is missing from your terminal's current PATH. To check if that is the case, locate where is the binary installed by default (in my machine is found under /usr/local/bin directory) and check if that directory is present in your PATH, by running:
echo $PATH
In case it is not, you can add it by running:
PATH=$PATH:/path/to/surge/location
Then check if it works now:
surge
If that's the case, to make this change persitent across reboots, you can echo the current PATH you have defined:
echo $PATH
And then export the result of that last command to your ~/.bashrc file, by adding this line:
export PATH=/previous/command/output/here
Related
I'm using the most recent VScode on Ubuntu 22.10 and experiencing the following issues while opening ZSH and BASH shells in the integrated terminal. The standard Ubuntu terminal works without errors.
After starting a ZSH integrated terminal:
compdump:138: command not found: mv
/home/user/.oh-my-zsh/oh-my-zsh.sh:56: command not found: mkdir
/home/user/.oh-my-zsh/tools/check_for_upgrade.sh:29: command not found: git
/home/user/.oh-my-zsh/oh-my-zsh.sh:115: command not found: rm
getent:6: command not found: grep
_p9k_init_cacheable:59: command not found: uname
_p9k_init_cacheable:61: command not found: uname
BASH
Command 'uname' is available in the following places
* /bin/uname
* /usr/bin/uname
The command could not be located because '/bin:/usr/bin' is not included in the PATH environment variable.
uname: command not found
Just several hours before, it worked just fine. Then I tried to set up Remote SSH to another Linux machine (Fedora 36, with the same sort of errors I was also unable to resolve by googling).
Using the #modified keyword in Settings, I ensured that no unexpected changes had been made. The PATH is the same as in the fully operational standard terminal.
Wondering what could be the issue.
UPDATES.
PATH variable:
/usr/local/cuda-11.7/bin:/home/user/.conda/envs/env/bin:$PATH
The problem.
Unlike the complete PATH expansion in the standard terminal, PATH was expanded partially (omitting /usr/bin, etc.) in the integrated terminal.
Based on this error,
The command could not be located because '/bin:/usr/bin' is not included in the PATH environment variable.
I suggest you run,
export PATH="/usr/bin:$PATH"
To add /bin:/usr/bin to your PATH
Having :$PATH in your PATH means that the sheell will add the variable $PATH to the end of your PATH
The cause of the issue the following configuration from the User settings:
terminal.integrated.env.linux": {
"PYTHONPATH": "/media/user:/media/user/common:$PYTHONPATH",
"PATH": "/media/user:/media/user/common:$PATH"
}
While the PYTHONPATH variable is expanded properly in the integrated terminal, the PATH is expanded partially to something shown in the UPDATES section of the question. To build on top of the answer by #Orion447, looking for any potential place where PATH could get corrupted is the approach that likely solves the problem.
I am setting up a project initialization script and a git pre-commit hook for work on a project. We have the scripts I want to run for linting not in the root directory but in a sub-directory and I would like to keep it that way.
What I want to be able to do is to set the full relative path to the binary executables for eslint and phpcs to bash variables then be able to run them. I also want to be able to execute the composer.phar binary from the bash variables.
So here is what I did.
# Set tool paths
PHPCS_PATH=`./wp-content/themes/our-theme/vendor/bin/phpcs`
PHPCBF_PATH=`./wp-content/themes/our-theme/vendor/bin/phpcbf`
ESLINT_PATH=`./wp-content/themes/our-theme/node_modules/.bin/eslint`
SASSLINT_PATH=`./wp-content/themes/our-theme/node_modules/.bin/sass-lint`
COMPOSER_PATH=`./wp-content/themes/our-theme/composer.phar`
I was trying to test these paths locally from the project root directory and I keep getting errors.
I copy and paste one of those lines into my terminal, hit enter, then do one of the following:
${ESLINT_PATH} and command ${ESLINT_PATH} and "${ESLINT_PATH}" and $ESLINT_PATH all yield me...
zsh: command too long: eslint [options] file.js [file.js] [dir]\n\nBasic configuration...
eval "${ESLINT_PATH}" and eval $ESLINT_PATH and eval "$ESLINT_PATH" all yield me...
zsh: no matches found: [options]
zsh: command not found: Basic
zsh: command not found: --no-eslintrc
zsh: command not found: -c,
zsh: no matches found: [String]
Am I losing my mind? How in the world do I make the path executable? If I take the contents of the path and run it, it works just fine.
Example: ./wp-content/themes/swmaster/node_modules/.bin/eslint actually tells me to specify a path.
What am I doing wrong here?
Looks like your issue is in these assignments:
# Set tool paths
PHPCS_PATH=`./wp-content/themes/our-theme/vendor/bin/phpcs`
PHPCBF_PATH=`./wp-content/themes/our-theme/vendor/bin/phpcbf`
ESLINT_PATH=`./wp-content/themes/our-theme/node_modules/.bin/eslint`
SASSLINT_PATH=`./wp-content/themes/our-theme/node_modules/.bin/sass-lint`
COMPOSER_PATH=`./wp-content/themes/our-theme/composer.phar`
Those back-ticks are command substitutions. An easier to read way of writing this is would be:
PHPCS_PATH=$(./wp-content/themes/our-theme/vendor/bin/phpcs)
...
I don't think that is what you really want. A command substitution actually executes what is inside and is substituted by whatever goes to stdout. I think you were actually trying to do string assignments. This can be accomplished by simply removing the back-ticks because there are no spaces in the paths. But it is a good habit to get into to just double quote them anyway. Try this:
# Set tool paths
PHPCS_PATH="./wp-content/themes/our-theme/vendor/bin/phpcs"
PHPCBF_PATH="./wp-content/themes/our-theme/vendor/bin/phpcbf"
ESLINT_PATH="./wp-content/themes/our-theme/node_modules/.bin/eslint"
SASSLINT_PATH="./wp-content/themes/our-theme/node_modules/.bin/sass-lint"
COMPOSER_PATH="./wp-content/themes/our-theme/composer.phar"
Another method to solve your issue would be to add these directories to your PATH variable. For example, if you set your PATH to include the bin directory for phpcs and phpcbf, you would be able to execute those programs without specifying a full (or relative in this situation) path:
export PATH=$PATH:./wp-content/themes/our-theme/vendor/bin
# or export PATH=$PATH:/full/path/to/wp-content/themes/our-theme/vendor/bin
# Now you can just run the line below without a path...
phpcs
This morning I found what I was looking for in this gist: https://gist.github.com/rashtay/328da46a99a9d7c746636df1cf769675#file-pre-commit-eslint
My solution is now:
# Set tool paths
PHPCS="$(git rev-parse --show-toplevel)/wp-content/themes/our-theme/vendor/bin/phpcs"
PHPCBF="$(git rev-parse --show-toplevel)/wp-content/themes/our-theme/vendor/bin/phpcbf"
ESLINT="$(git rev-parse --show-toplevel)/wp-content/themes/our-theme/node_modules/.bin/eslint"
SASSLINT="$(git rev-parse --show-toplevel)/wp-content/themes/our-theme/node_modules/.bin/sass-lint"
This works from any directory in the repo because it ties to the repo base path. It is dynamic in that way.
A majority of terminal commands don't work, for example .
ls
sudo
vi
with the error -bash: ls: command not found my path is echo $PATH
“/Users/username/usr/local/bin I get the feeling that “ should not be there but not sure how edit it.
What should the path be and how do I get the path to stay the same?
You need to add more paths to your $PATH variable. Try running whereis ls and check where is the binary of the command.
You can add more paths like this: export PATH=$PATH:NEW_PATH
I had a similar experience recently where a lot of my terminal commands were not being found despite being clearly saved in my bash_profile. After lengthy process of elimination I realised that the issue was caused when I tried to export a new path. The error that I had made was putting a space in the command. So I had to change
export SOMETHING = /path/to/something.apk to
export SOMETHING=/path/to/something.apk
So I would recommend you check all your path declarations to ensure you don't have any white spaces. Also don't forget to source your bash_profile or what ever type of command line shell you use.
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.
Thanks to everyone's help here, I was able to resolve this issue. When I posted my question, I left a tiny but important detail out of my bash profile - a lone asterisk on the last line.
[[ -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 #ADDS MYSQL TO PATH EVERY TIME TERMINAL OPENS
*
I didn't even notice this thing before, let alone understand that it was doing anything. I commented it out and now everything runs perfectly. I'm not sure if this asterisk is a standard part of the bash profile or not, but if it has been there all along, it didn't cause me any trouble until this morning, after I had installed PostGIS and made a Github pull request. I'm not sure why those actions would have triggered this problem, but I'm trying to be as descriptive as possible in case anyone else runs into this.
So, if I man cd, I get the manpage for bash builtins.
If I cd -?, I get the following:
cd -?
-bash: cd: -?: invalid option
cd: usage: cd [-L|[-P [-e]] [-#]] [dir]
I know what the first two options are. Then I searched for both options.
For the -e option, I found this answer on the Unix StackExchange.
For the -# option, I couldn’t find any explanation.
My system info:
OS X 10.9 (Mavericks)
bash 4.3.18 (installed with the Homebrew package manager for OS X)
However, if I run which cd, I get /usr/bin/cd. Homebrew doesn’t touch anything outside of /usr/local, so I can only assume this is the system’s cd.
But I can’t find the documentation for that option! It’s driving me crazy.
Does anyone know what -# does?
It's a new option (as of bash-4.3). The changelog contains the following description:
'cd' has a new `-#' option to browse a file's extended attributes on
systems that support O_XATTR.
(changelog)
Type help <name> or man bash to get more info on bash commands. (In the bash man page you can search for cd by typing / followed by a search string and enter. n to go to the next hit, shift+n to go backwards).
The bash man page contains the following:
On systems that support it, the -# option presents the extended
attributes associated with a file as a directory.
Check the man page for bash for an explanation. The relevant portion says:
If dir begins with a slash (/), then CDPATH is not used. The -P option causes cd to use the physical directory structure by resolving symbolic links while traversing dir and before processing instances of .. in dir (see also the -P option to the set builtin command); the -L option forces symbolic links to be followed by resolving the link after processing instances of .. in dir. If .. appears in dir, it is processed by removing the immediately previous pathname component from dir, back to a slash or the beginning of dir. If the -e option is supplied with -P, and the current working directory cannot be successfully determined after a successful directory change, cd will return an unsuccessful status. On systems that support it, the -# option presents the extended attributes associated with a file as a directory. An argument of - is converted to $OLDPWD before the directory change is attempted. If a non-empty directory name from CDPATH is used, or if - is the first argument, and the directory change is successful, the absolute pathname of the new working directory is written to the standard output.